OpenCPN Magnetic Variation Reversed?

[gchead]

I have a strange problem that I'm hoping the OpenCPN gurus out there can throw some light on:

I am using OpenCPN to send NMEA course bearing to a NASA Clipper GPS Repeater via a NMEA2WIFI Bidirectional Multiplexer from Vela-Navega. It works very well except for one issue. The GPS Repeater is meant to display magnetic bearing which is fine BUT it is showing the reverse magnetic variation. The example shown in the photos below is:

1. Set course to waypoint "Test" at 0°.
2. Variation (here in NZ) is 22.3° East. I have WMM plugin enabled. My GPS is a Garmin 18x LVC.
3. Magnetic BRG to the waypoint shown in OpenCPN is (correctly) 338°. (As verified by a hand bearing compass).
4. The output RMC sentence shows the variation as 022.3,E
5. The GPS Repeater shows bearing as 22° rather than 338° (44° different to what it should be).

I have also tested the output to my Raymarine ST2000+ AutoTiller and it also shows the bearing as 22° rather than 338°.

I have contacted NASA support who say their GPS Repeater simply shows whatever NMEA data it receives and that the problem must be something to do with my OpenCPN settings.

Any suggestions?

[gchead]

PS. I'm running OpenCPN version 4.8.4 on Windows 10 laptop.

[rooiedirk]

RMB Recommended Minimum Navigation Information
$--RMB,A,x.x,a,c--c,c--c,llll.ll,a,yyyyy.yy,a,x.x,x.x,x.x,A*hh
1) Status, V = Navigation receiver warning
2) Cross Track error - nautical miles
3) Direction to Steer, Left or Right
4) TO Waypoint ID
5) FROM Waypoint ID
6) Destination Waypoint Latitude
7) N or S
8) Destination Waypoint Longitude
9) E or W
10) Range to destination in nautical miles
11) Bearing to destination in degrees True
12) Destination closing velocity in knots
13) Arrival Status, A = Arrival Circle Entered
14) Checksum

According my info (see above) should a ..RMB sentence send the true bearing in data field(11). And O does that correctly.

[gchead]

Yes I agree, OCPN is sending the correct True bearing, in this case 0.161:

$ECRMB,A,0.000,L,001,Test,4117.202,S,17447.112,E,0 .107,0.161,-1.#IO,V*34

I'm thinking the problem may be the manner in which the instruments are interpreting the magnetic variation formatting in RMC? The $GPRMC shows it as 022.2,E.

The $ECRMC sentence sends it as 22.300,E. but unfortunately the GPS Repeater does not work at all when OCPN is outputting just $ECRMC. It only works with $GPRMC which is passed thru from my Garmin.

I'm stuck!

[gchead]

I should also mention that according to the Clipper GPS Repeater manual:

"Regardless of the settings on the GPS Receiver, the repeater always
displays distances in Nautical miles, speeds in knots, and all
bearings in magnetic."

http://www.nasamarine.com//wp-conten...S-Repeater.pdf

[rooiedirk]

For better understanding what does what, and how is it interpredit. Try make a route on the GPS and see what is shown.


As it does seem you do understand how nmea sentences work, you could try to use the plugin 'nmea-converter' to fool around with the data in the sentences. (a rather dirty way of fixing)

[gchead]

Thanks Dirk - I'm trying out the 'nmea-converter' now. Quite a handy plugin!

Also I'm seeing "-1.#IO" in the SOG field of ECRMC sentence generated by OpenCPN. Any idea what this means?

eg.

$ECRMC,211754,A,4117.178,S,17400.463,E,-1.#IO,0.000,200618,22.200,E

[did-g]

Originally Posted by gchead

Also I'm seeing "-1.#IO" in the SOG field of ECRMC sentence generated by OpenCPN. Any idea what this means?

Likely a bug. How Windows is printing a NaN ?

[Hakan]

did-g..
Yes your right. I get this in Win10 also in 4.99.0

$ECRMB,A,0.000,L,001,002,5800.031,N,01145.163,E,0.449,17.858,-nan(ind),V*24<0x0D><0x0A>
14:11:58 (UDP:192.168.x.x:10111) $ECRMC,121158,A,5759.604,N,01144.904,E,-nan(ind),-nan(ind),210618,3.615,E*65<0x0D><0x0A>
14:11:58 (UDP:192.168.x.x:10111) $ECAPB,A,A,0.000,L,N,V,V,17.889,T,002,17.858,T,17.858,T*0E<0x0D><0x0A>

[Hakan]

did-g...
This a rather hypothetical debate since no one will start a "Navigate to" while no GPS is active I suppose??
But if we like we may solve it this way:?
Håkan

@@ -608,6 +608,9 @@ bool Routeman::DeactivateRoute( bool b_arrival )
 bool Routeman::UpdateAutopilot()
 {
     //Send all known Autopilot messages upstream
+  double r_Sog(0.0), r_Cog(0.0);
+  if (!wxIsNaN(gSog)) r_Sog = gSog;
+  if (!wxIsNaN(gCog)) r_Cog = gCog;

     //RMB
         {
@@ -644,7 +647,7 @@ bool Routeman::UpdateAutopilot()

             m_NMEA0183.Rmb.RangeToDestinationNauticalMiles = CurrentRngToActivePoint;
             m_NMEA0183.Rmb.BearingToDestinationDegreesTrue = CurrentBrgToActivePoint;
-            m_NMEA0183.Rmb.DestinationClosingVelocityKnots = gSog;
+            m_NMEA0183.Rmb.DestinationClosingVelocityKnots = r_Sog;

             if( m_bArrival ) m_NMEA0183.Rmb.IsArrivalCircleEntered = NTrue;
             else
@@ -671,8 +674,8 @@ bool Routeman::UpdateAutopilot()
             else
                 m_NMEA0183.Rmc.Position.Longitude.Set( gLon, _T("E") );

-            m_NMEA0183.Rmc.SpeedOverGroundKnots = gSog;
-            m_NMEA0183.Rmc.TrackMadeGoodDegreesTrue = gCog;
+            m_NMEA0183.Rmc.SpeedOverGroundKnots = r_Sog;
+            m_NMEA0183.Rmc.TrackMadeGoodDegreesTrue = r_Cog;

[did-g]

Hi,

Originally Posted by Hakan

did-g...
This a rather hypothetical debate since no one will start a "Navigate to" while no GPS is active I suppose??
But if we like we may solve it this way:?

Yes or maybe NMEA sentence writers could double check their inputs?
The code is duplicated in many plugins though, hard to fix all of them.

Didier

[kumado77]

I spent a lot of time connecting opencpn to GPS Clipper repeater.
You have an IO error in some of the fields, what the GPS can't cope with.- nan(ind),
-1.#IO



I used a Ship.modul Multiplexer and i had the same issue


There are many possible reasons for a bad connection:
One most probably is an oberflow in the reading buffer at the Multiplexer. It can not process all the data from the opencpn, so the buffer overflows. Once the reading buffer is fine again, it has lost some data.
My multiplexer offers the opportunity to flowcontrol of the serial with hardware control, but opencpn does not support it. Unless opencpn does not provide that, all NMEA ouput to Multiplexers or other listeners have the problem to receive rubbsih and steer rubbish.
In the end i worked around it with USB to HW - postprocessor to overcome all the issues with corrupted data. And there are nore issues with the NMEA sentences, what i meanwhile found out.

[gchead]

Good news! I have now been able to identify the cause of this issue and create a temporary work-around.

NMEA version 2 and onwards states that the RMC sentence must include an extra field Nbr 12 "FAA mode indicator" but the ECRMC sentence generated by OpenCPN when navigating to a waypoint does NOT include this field.

The NASA Clipper GPS Repeater (which displays all bearings in magnetic) requires NMEA version 2.0 (or later version) and it appears that if the GPS Repeater doesn't see the extra field it just assumes West variation. (Magnetic variation here in NZ is 22 degrees East).

With the help of Dirk's wonderful NMEAConverter plugin I was able to synthesise an XXRMC sentence from the incoming RMC from the GPS and adding an extra comma and "A" after the Magnetic Variation E or W field. By sending my "synthetic" XXRMC from OpenCPN instead of the ECRMC, the GPS Repeater magically shows the correct magnetic bearing of 338 degrees rather than 22 degrees previously when steering to a course of 0 degrees true.

Example:
$ECRMC,211808.00, A,4117.30837, S,17447.10970, E,0.007, ,310818,22.6,E*23
(RMC sentence generated by OpenCPN - no field after the last "E")

$XXRMC,211808.00, A,4117.30837, S,17447.10970, E,0.007, ,310818,22.6,E,A*23
(Synthesised RMC sentence with extra field after the last "E")

Could we please in the next release of OpenCPN, add the extra field in the ECRMC sentence to make it NMEA Version 2.3 compliant?














Success!

[rooiedirk]

Nmea version 2.3 is from march 1998 Would we break something by adding an extra field?

[did-g]

Originally Posted by rooiedirk

Nmea version 2.3 is from march 1998 Would we break something by adding an extra field?

Maybe plugins decoders?
On the other there's a bug report O must ignore extra fields in sentences, seems to be in the norm.