Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 05-04-2014, 11:26   #136
Registered User

Join Date: Sep 2009
Location: Angers - France
Boat: Beneteau First 29 Ptizef
Posts: 743
Re: OpenCPN Beta Version 3.3.1419 Released

Quote:
Originally Posted by cagney View Post
Thanks Ptizef, that conversation was lurking at the back of my mind.

To you who have the problem.... Are you all using the Unity windows manager?

Thomas
Yes I do too
Jean Pierre
__________________

__________________
Ptizef is offline   Reply With Quote
Old 05-04-2014, 15:30   #137
Registered User

Join Date: Apr 2014
Posts: 10
Re: OpenCPN Beta Version 3.3.1419 Released

Hi,

I'm newbie here.
First of all, I'm very impressed how stable it all runs and how huge (in functions) it is. It will be my ChartPlotter (with AIS) of choice in the soon beginning season.

I run it on a Raspberry Pi, wich also gains barometric data by an attached bmp085 Sensor. For that, I used socat to pair two pseudo-serial interfaces, echo a NMEA sentence to one makes it appear in the NMEA Debug Window, listed as accepted. (If I change the checksum to something else, it gets listed as 'dropped' - just to make sure that this is not the problem).

My generic NMEA-Sentences are like this:

$WIMDA,29.921,I,1.013,B,20.1,C,,,,,,,,,,,,,,,*,1d

(And I tried with a ',' less also)
It get listed as accepted, but the barometric pressure display and history don't show a thing.

Do I have an error in the sentence? Any hint what's going wrong will be appreciated...

OpenCPN seems to me some kind of event-driven; it get's a sentence -- it reacts to the sentence. But are there other ways, is it possible to make it collect data on itself on regular basis (on reasonable amount of changes and work)?


With best regards,
Erik
__________________

__________________
erik23_de is offline   Reply With Quote
Old 05-04-2014, 23:17   #138
Registered User

Join Date: May 2012
Posts: 26
Re: OpenCPN Beta Version 3.3.1419 Released

erik23_de i think this is solved in source code, post 40 and 41 in tis thread.
__________________
stedy is offline   Reply With Quote
Old 06-04-2014, 01:12   #139
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 1,968
Re: OpenCPN Beta Version 3.3.1419 Released

Quote:
Originally Posted by erik23_de View Post
.........
My generic NMEA-Sentences are like this:

$WIMDA,29.921,I,1.013,B,20.1,C,,,,,,,,,,,,,,,*,1d
.....Erik
Erik...
This is how Dashboard now evaluates the MDA sentence:
Code:
bool MDA::Parse( const SENTENCE& sentence )
{
//   ASSERT_VALID( this );
...............
**$
**--
**MDA,x.x,I,x.x,B,x.x,C,x.x,C,x.x,x.x,x.x,C,x.x,T,x.x,M,x.x,N,x.x,M*hh<CR><LF>
**    |   |  |  |          Dew point, degrees C
**    |   |  |  |          Absolute humidity, percent
**    |   |  |  |          Relative humidity, percent
**    |   |  |  |        Water temperature, degrees C
**    |   |  |  |          Air temperature, degrees C
**    |   |  |----Barometric pressure, bars
**    |----- Barometric pressure, inches of mercur
*/


   /*
   ** First we check the checksum...
   */

   if ( sentence.IsChecksumBad( sentence.GetNumberOfDataFields() +1) == TRUE || FALSE ) //diferent vendors have different length of data message and not 24 field as in standard.
   {
      SetErrorMessage( _T("Invalid Checksum") );
      return( FALSE );
   }

Pressure       = sentence.Double( 3 );
UnitOfMeasurement = sentence.Field( 4 );

if(UnitOfMeasurement==wxT("B"))
{
   Pressure       = sentence.Double( 3 ); //from bar to Hecto pascal
Without counting all your commas I can see there is a superfluous comma between the "*" and the "checksum" in your sentence.
And reading post 40/41 in this thread gives I may have a updated code and you have to update from last Git if you are able to build from source. Other wise whait for next beta or if someone can serve you a new unix dashboard binary. (I'm on Windows - sorry)
Håkan

Håkan
__________________
Hakan is offline   Reply With Quote
Old 06-04-2014, 12:11   #140
Registered User

Join Date: Apr 2014
Posts: 10
Re: OpenCPN Beta Version 3.3.1419 Released

Thank you for the hints. Removing the , before * did part of the trick. Now I get a message in the NMEA-Debug-Window after my first sentence:

Changing NMEA Datasource for WMDA to Serial:/dev/pts/4 (Priority: 1)

Wich must mean a higher Level of acceptance :-)

Changing the code as recommended in Post 40 & 41 did not do any significant changes... After a make, make install, of course.

Still nothing to see on both versions of the barometer and history.

Sadly, the last versions after 1419 didn't work for me on PI (exiting with a segfault before showing the screen, directly after ALSA-Messages).

Right now, I tried a make clean, make, make install just to be sure that all cahnges really take effect.

Erik
__________________
erik23_de is offline   Reply With Quote
Old 06-04-2014, 14:40   #141
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 1,968
Re: OpenCPN Beta Version 3.3.1419 Released

Quote:
Originally Posted by erik23_de View Post
.....Changing NMEA Datasource for WMDA to Serial:/dev/pts/4 (Priority: 1)
Wich must mean a higher Level of acceptance :-).....
Nop...It means if you have a data stream including MDA coming from another source at a lower priority the one with the higher priority is used instead.

For the Linux issues someone else has to comment.
Håkan
__________________
Hakan is offline   Reply With Quote
Old 06-04-2014, 17:16   #142
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,884
Re: OpenCPN Beta Version 3.3.1419 Released

Erik...

On 3.3.1606....

Using this sentence:

Code:
$WIMDA,29.921,I,1.013,B,20.1,C,,,,,,,,,,,,,,,*1d
I get the attached dashboard image.

Works fine, AFAICT.

Dave
Attached Thumbnails
Click image for larger version

Name:	mda.jpg
Views:	91
Size:	35.5 KB
ID:	78907  
__________________
bdbcat is offline   Reply With Quote
Old 06-04-2014, 17:46   #143
Registered User

Join Date: Apr 2014
Posts: 10
Re: OpenCPN Beta Version 3.3.1419 Released

@bdbcat: Thanks for checking the sentence. Now all needed is a version wich runs on PI (latest does not, at least not on mine).

Quote:
Originally Posted by Hakan View Post
Nop...It means if you have a data stream including MDA coming from another source at a lower priority the one with the higher priority is used instead.
"Higher Acceptance" in the sense, that there is not only a listing in green, but recognized as a valid source and propagated to at least one step above the try before..

Erik
__________________
erik23_de is offline   Reply With Quote
Old 08-04-2014, 14:13   #144
Registered User

Join Date: Apr 2014
Posts: 10
The simple and (somehow) strange solution...

Hi,

after implanting several protocol messages, showing
1.That there is a clock tick every second in dashboard_pi::notify()
2.That no single message was sent to mda.cpp

it finally came to my mind, the <CR><LF> at the end of a sentence, wich is in unix normally a bare <LF> or printf \n, could be the reason. Not really because , normally on unix only <LF>, but hey, give it a try....

so printf \r\n.

And it worked. Puzzling, because with LF only, it is listed in the debug-window as a green, normal accepted sentence, but never gets propagated.

Now it works fine and awaits a more automatized approach.

-----

By the way 1. provides an answer to my second question, how to make OpenCPN to poll some data directly, bypassing quite a lot of serial/net/IO-Protocoll. From here, it would (perhaps) be simple, poll my sensor just hooked on the clock tick in Dashborad_PI/notify. I could just merge my sourceCode in.
But that would be a me and me only-solution.

A better way would be just an entry under .opencpn with a list of programs to call all -- seconds and take and treat the return as an NMEA-Sentence.
Some sort of internal cron...

What you think? Or is this feature already existing? ;-)
Of course, only the guys with strange computers with a lot of IO-Pins have the advantage, but still...

Thanks again for the hints.
Erik
__________________
erik23_de is offline   Reply With Quote
Old 08-04-2014, 16:25   #145
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,020
Re: The simple and (somehow) strange solution...

Erik...
"<CR><LF>" line endings are actually part of the NMEA standard.
To process the data from your device you basically have 2 options that make more sense than implementing it inside dashbord (=without any reasonable chance it will make it upstream):
1) Separate plugin - not a rocket science to implement, just steal the base from some of the existing ones and make it poll your device and insert NMEA sentences to OpenCPN
2) Completely outside of opencpn and in case you don't want to bother with the networking code, output to stdout and use netcat to create a TCP or UDP stream to which to connect OpenCPN.

Pavel

Quote:
Originally Posted by erik23_de View Post
Hi,

after implanting several protocol messages, showing
1.That there is a clock tick every second in dashboard_pi::notify()
2.That no single message was sent to mda.cpp

it finally came to my mind, the <CR><LF> at the end of a sentence, wich is in unix normally a bare <LF> or printf \n, could be the reason. Not really because , normally on unix only <LF>, but hey, give it a try....

so printf \r\n.

And it worked. Puzzling, because with LF only, it is listed in the debug-window as a green, normal accepted sentence, but never gets propagated.

Now it works fine and awaits a more automatized approach.

-----

By the way 1. provides an answer to my second question, how to make OpenCPN to poll some data directly, bypassing quite a lot of serial/net/IO-Protocoll. From here, it would (perhaps) be simple, poll my sensor just hooked on the clock tick in Dashborad_PI/notify. I could just merge my sourceCode in.
But that would be a me and me only-solution.

A better way would be just an entry under .opencpn with a list of programs to call all -- seconds and take and treat the return as an NMEA-Sentence.
Some sort of internal cron...

What you think? Or is this feature already existing? ;-)
Of course, only the guys with strange computers with a lot of IO-Pins have the advantage, but still...

Thanks again for the hints.
Erik
__________________
nohal is offline   Reply With Quote
Old 08-04-2014, 18:48   #146
Registered User

Join Date: Apr 2014
Posts: 10
Wink Re: The simple and (somehow) strange solution...

Quote:
Originally Posted by nohal View Post
Erik...
"<CR><LF>" line endings are actually part of the NMEA standard.
Yes, right, and it's a Dos-Standard also. So I read it as "just end the sentence in a normal way". <LF> only is Unix-Standard, and because of this there are sometimes misunderstandings when changing environment with some text. A pure Linux, or better say, a non-Win Version would have just ignored occurance or non-occurence of the <CR>.

So it's not about ignoring obvious part of the specs, but ignoring a matter of cross-platform-stuff...
(I think I heard a while ago about these matters with using wxWidgets.)

With socat I'm already using a kind of netcat...


If I write a new plugin, as you suggested, how can I poll? If there is no NMEA sentence coming through the normal ports, how to get the plugin triggered at all? Is there already a plugin wich is polling something, or isn't it all just waiting for a sentence adressing them?
(Otherwise, I would not have asked)

Greetings,
Erik
__________________
erik23_de is offline   Reply With Quote
Old 08-04-2014, 19:02   #147
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,020
Re: The simple and (somehow) strange solution...

Quote:
Originally Posted by erik23_de View Post
Yes, right, and it's a Dos-Standard also. So I read it as "just end the sentence in a normal way". <LF> only is Unix-Standard, and because of this there are sometimes misunderstandings when changing environment with some text. A pure Linux, or better say, a non-Win Version would have just ignored occurance or non-occurence of the <CR>.

So it's not about ignoring obvious part of the specs, but ignoring a matter of cross-platform-stuff...
(I think I heard a while ago about these matters with using wxWidgets.)
Whoever wrote the NMEA-0183 standard was probably a Unix hater, that's obvious And it was not meant for PCs, so they specified the line endings explicitly...
Quote:
If I write a new plugin, as you suggested, how can I poll? If there is no NMEA sentence coming through the normal ports, how to get the plugin triggered at all? Is there already a plugin wich is polling something, or isn't it all just waiting for a sentence adressing them?
(Otherwise, I would not have asked)

Greetings,
Erik
You can poll in various ways, the most clean probably being a wxWidgets: wxTimer Class Reference created in the plugin's constructor.

Pavel
__________________
nohal is offline   Reply With Quote
Old 29-04-2014, 20:11   #148
Registered User

Join Date: Aug 2010
Location: Oz
Boat: EX prawn trawler 14m
Posts: 100
Re: OpenCPN Beta Version 3.3.1419 Released

Has anyone reported the mag variation being added to true, instead of subtracting.
I'm using 3.3.1419 as I didn't have time to upgrade before departing.
Ubuntu 13.10 64bit
Attached screen shot to explain.

I'm showing 319M in the route info window
NMEA debug window APB output shown as 338.6M
Dashboard shows 330T

Settings :Show mag bearings and headings
:use mag bearings in APB output
:WMM plugin active
:+10.9 Deg variation at current location

The above numbers don't add up to an exact difference of 2 x variation because I'm not under AP at this stage, if I do I get a big turn to the Starboard.

If I drop the mag from APB and use true in APB output I see debug window equal dashboard reading, and 11 deg difference between them and the figure in the route info window. (I reckon this is correct for this setup)

Redog
Attached Thumbnails
Click image for larger version

Name:	Screenshot from 2014-04-27 12:04:21.jpg
Views:	62
Size:	309.4 KB
ID:	80280  
__________________
redog is offline   Reply With Quote
Old 29-04-2014, 21:03   #149
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,884
Re: OpenCPN Beta Version 3.3.1419 Released

redog....

Looks like your analysis is correct. We should subtract variation, not add.

Wrong:
Code:
double brg1m = ((brg1 + gVar) >= 0.) ? (brg1 + gVar) : (brg1 + gVar + 360.);
Right:
Code:
double brg1m = ((brg1 - gVar) >= 0.) ? (brg1 - gVar) : (brg1 - gVar + 360.);
This error was fixed elsewhere, but missed in $xxAPB code.

Everyone agree?
Thanks
Dave
__________________
bdbcat is offline   Reply With Quote
Old 29-04-2014, 22:05   #150
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,020
Re: OpenCPN Beta Version 3.3.1419 Released

Dave...
Agreed - I fixed it for display in https://github.com/OpenCPN/OpenCPN/c...c0f90e05e1be7a (that's why the difference is visible), but as I never used the autopilot connection, missed that completely.

Pavel
__________________

__________________
nohal is offline   Reply With Quote
Reply

Tags
enc, lease, opencpn

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off




Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 04:27.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.