Beta Test / Technical

[bcn]

just for fun from the NMEA web site:

NMEA 0183 Pricing:
NMEA has established a tiered pricing system for NMEA 0183 Version 4.11 Release November 2018.
This is based on industry group.
Marine Industry Manufacturer $1000 (NMEA Member), $2000 (non member)
Industrial Manufacturer $2,500
Consumer Electronics Manufacturer $5,000.
Future updates to the NMEA 0183 Standard (after version 4.11) are 50% off the prices above based on purchase history.
Contact info@nmea.org or call 410-975-9425 for purchasing NMEA 0183.

Sponsors wanted...

[Tehani]

Originally Posted by transmitterdan

On further research it appears that the RMC field descriptors within the O source code are not accurate for the current NMEA standard. The RMC field for course is indeed supposed to be course over ground but in the sources it is called "TrackMadeGoodDegreesTrue".

In the NMEA0183 3.01 doc appears "Course Over Ground" in field 8 of the RMC sentence.
I would not touch the content, I would just change the name of the variable in O and I would put an "alias" or define it with the old name.

[rgleason]

Originally Posted by Tehani

In the NMEA0183 3.01 doc appears "Course Over Ground" in field 8 of the RMC sentence.
I would not touch the content, I would just change the name of the variable in O and I would put an "alias" or define it with the old name.

In our wiki for Nmea0183 what does

• "8. Track Made Good, degrees true"

become?

• "8. Course Over Ground (COG) [Nmea0183 v3.01] - used to be Track Made Good, degrees true"?

[nohal]

Rick...
Do not do anything. There is no change in the code, there does not need to be any change anywhere else. The reference documentation available to us, people who are not in the NMEA cartel and not bound by the NDA associated with it, is clear: NMEA Revealed

Pavel

[bdbcat]

All.


I am no linguist, but I cannot see the semantic difference between:


"course over ground" and "TrackMadeGoodDegreesTrue".

Anyone have insight?


Dave

[transmitterdan]

Dave,

Track made good is meaningless to me. A track could mean the lane to the next waypoint but it doesn’t matter. The RMC sentence should send COG as it has always done. No change needed.

Only the RMB sentence is in error as far as I can tell. The standard wants the velocity in RMB to be the vector speed toward the next waypoint not COG.

[transmitterdan]

Sorry, I mean It should not be SOG. Been a long day...

[Tehani]

Originally Posted by transmitterdan

I will do some research to see if there is a historical reason. I see no reason to send SOG in a field meaning "closing speed". It is ok that RMB is only sent when running a route. That's the only time closing speed has a meaning.

I think we should consider something more about the VMG treatment because that data can be displayed in the dashboard:
In my tests, no VMG information has appeared in any case, whether or not OCPN is in WPT navigation mode.
When O is not in navigation mode, it is entirely possible that an external browser is performing that function. In this case, the VMG information does not appear in the dashboard and is nevertheless present in the RMB entry to O.
It would be advisable to decide on a policy in this regard. My opinion is that it would be good to activate the navigation box also when RMB sentences are detected at the entrance, and to reconfigure the VMG of the dashboard as Wind VMG, presenting the information of the entry VPW sentence, or calculating it internally.
I have not yet studied the data structure of O, I understand that it is possible that it is necessary to make an effort to unify the data of the internal navigator with those that come by the RMB sentence. It is also possible that this is not a priority at this time...

[transmitterdan]

The RMB sentence we are discussing is transmitted out by O not received. O does not change the meaning of an incoming RMB sentence. Unless there is an infinite loop created externally O will never see the RMB sentence it transmits. And an infinite loop like that is to be avoided at all times anyway.

[Tehani]

Originally Posted by transmitterdan

The RMB sentence we are discussing is transmitted out by O not received. O does not change the meaning of an incoming RMB sentence. Unless there is an infinite loop created externally O will never see the RMB sentence it transmits. And an infinite loop like that is to be avoided at all times anyway.

When O is in navigation mode, the VMG field of the dashboard also does not display anything. What information should appear there?

I understand you, to avoid a data loop, O should control what data arrives on each channel and filter so as not to forward on the same channel.

The data loops are the eternal problem in many installations.

[rgleason]

Track made good, degrees, true

• Track= some course
• made good = over ground
• degrees, true.

Which is COG
-------
Dev Manual improvement
In the Dev Manual I added
pi116 (1.16)= OpenCPN 4.99 (5.00 or ov50)
Does anyone have a list of what has been added? (Similar to pi115 above?)
--------

Messaging
Tehani you might want to read Jon Gough's writeup for Ocpn_Draw ODAPI and Messaging (Which probably should be reviewed again sometime and improved by an Opencpn programmer)
---------


PS: I don't know if TransmitterDan's point should be explained more completely, as an example, somewhere in the wiki, perhaps under autopilot messaging? I think this topic might be best described with a flow diagram. Any suggestions?

The RMB sentence we are discussing is transmitted out by O not received. O does not change the meaning of an incoming RMB sentence. Unless there is an infinite loop created externally O will never see the RMB sentence it transmits. And an infinite loop like that is to be avoided at all times anyway.

[rgleason]

Is the best approach for moving to ov50 Plugins to make a new ov50 branch

• git checkout -b ov50

and then make your changes to that branch only?


Also when the plugin is working and you are ready to make a PR, it would be helpful to know if it is possible to make a PR that requests a new branch in the other persons repository. If not, how is this handled?


Also when would the appropriate time be for the ov50 branch be merged into master?

• During the PR?
• Sometime later when everyone has moved forward to using Opencpn 5.00 and the the Version 4 plugins are basically frozen?

Some guidance would be helpful.

[rgleason]

TDan I don't get this. Where do you find this reference? Everything I see says Track made Good, degrees true, or COG. Maybe we are not talking about the same thing? See several posts here


I asked you here:

What is your source?

Later: Found NMEA data
" 084.4 Track angle in degrees True"

Subtle but big difference, but the standards committee can't just change this year to year!

...and never got a response.


TDan wrote:

Only the RMB sentence is in error as far as I can tell. The standard wants the velocity in RMB to be the vector speed toward the next waypoint not COG. [Did you mean SOG?]

Earlier TDan wrote here:
Second post

On further research it appears that the RMC field descriptors within the O source code are not accurate for the current NMEA standard. [This is confusing to me.]

The RMC field for course is indeed supposed to be course over ground but in the sources it is called "TrackMadeGoodDegreesTrue". [So you agree here.]

TDan first statement:

So I had a little free time to look at the RMB velocity question. For sure O uses SOG in the RMB velocity field. [OK]

I also note that O sends COG in the RMC field intended for Track Made Good Degrees. [Yes, true I believe. here]

I suspect that there is no good reason for either of these. It's a simple matter to correct. I will create a PR and see what the main development team thinks [

I think Pavel would say no need to do anything
Best

Smile

[Tehani]

Originally Posted by rgleason

Pavel would say no need to do anything
Best

Smile

:silbido:

I think your conclusions are correct.
RMC in a sentence created only by the GPS (Or position system) based on the data received only by the receiver. There is no waypoint or route information. COG and SOG should appear here.
RMB in a navigation sentence that combines GPS information with the coordinates of the Waypoint. The data it contains are the result of these calculations on the line that joins the position of the ship and the Waypoint. VMG is the right thing to do. VMG = SOG * cos (COG - BRG). It does not make sense to put the SOG in its place.

[stevead]

Porting TwoCan plugin to Linux to support SocketCAN interface.


wxWidgets version is 3.0.4


g++ version is (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516



Following error when compiling:

[ 42%] Building CXX object CMakeFiles/twocan_pi.dir/src/twocanplugin.cpp.o
In file included from /home/pi/twocan/twocanplugin/inc/twocanplugin.h:40:0,
from /home/pi/twocan/twocanplugin/src/twocanplugin.cpp:33:
/home/pi/twocan/twocanplugin/inc/ocpn_plugin.h:438:43: error: ‘wxGLContext’ has not been declared
virtual bool RenderGLOverlay(wxGLContext *pcontext, PlugIn_ViewPort *vp);

Some searches have suggested either missing #include <wx/glcanvas.h> which indeed is present in ospn_plugin.h or compiling against wxWidgets 3.1.x, however I recall when originally developing my Windows version being advised to compile against 3.0.x.


Thoughts ?