RMB - Switched location of origin/destination waypoint?

[SamH]

Had all sorts of weird issues when trying to autotrack a route after upgrade to 5.6 and 5.6.2. Autotracking worked fine in 5.2.4.
Raymarine "Route Completes" before advancing to next waypoint, except if activating >1 waypoint ahead etc.

Creating a Vdr-log and comparing on a shared setup.
This is a small route, manually activated next waypoint twice, then back to first waypoint.

First 5.2.4, then below 5.6.2

# Activate route
$ECRMB,A,0.000,R,,001,5906.557,N,00938.412,E,0.001,348.396,-0.015,A,A*61 (5.2.4)
$ECRMB,A,0.000,R,001,,5906.557,N,00938.412,E,0.000,132.417,-0.014,A,A*6 (5.6.2)

# Activate waypoint 002 in route
$ECRMB,A,0.000,R,001,002,5906.435,N,00938.006,E,0.242,239.801,-0.007,V,A*44 (5.2.4)
$ECRMB,A,0.000,L,002,001,5906.435,N,00938.006,E,0.242,239.615,-0.007,V,A*51 (5.6.2)


# Activate waypoint 003 in route
$ECRMB,A,0.038,L,002,003,5906.364,N,00937.652,E,0.435,243.750,0.007,V,A*75 (5.2.4)
$ECRMB,A,0.038,,L003,002,5906.364,N,00937.652,E,0.435,243.673,-0.005,V,A*5A (5.6.2)

# Activate waypoint 002 in route
$ECRMB,A,0.001,R,001,002,5906.435,N,00938.006,E,0.241,239.832,0.009,V,A*65 (5.2.4)
$ECRMB,A,0.000,L,002,001,5906.435,N,00938.006,E,0.242,239.627,-0.008,V,A*5F (5.6.2)

[SamH]

A temp fix is to swap the two fields with the NmeaConverter-plugin, and block ECRMB from output.

Conversion:
$IIRMB,$ECRMB1,$ECRMB2,$ECRMB3,$ECRMB5,$ECRMB4,$EC RMB6,$ECRMB7,$ECRMB8,$ECRMB9,$ECRM?10,$ECRM?11,$EC RM?12,$ECRM?13,$ECRM?14

[Hakan]

SamH..
You're correct and it will be fixed in next O release.
Glad you meanwhile can survive with the temp fix.
Thanks for the report.

[SamH]

Thanks!

[pa391as]

I can confirm that the workaround works. Also can confirm that this bug causes OpenCPN not to be able to control a Raymarine autopilot without the NMEAConverter workaround. With this bug, attempting to Activate a route and enable Track mode on a Raymarine Autopilot results in "No Navigation data" on the pilot.

[rgleason]

@SamH

You wrote:
A temp fix is to swap the two fields with the NmeaConverter-plugin, and block ECRMB from output.

Conversion:

$IIRMB,$ECRMB1,$ECRMB2,$ECRMB3,$ECRMB5,$ECRMB4,$EC RMB6,$ECRMB7,$ECRMB8,$ECRMB9,$ECRM?10,$ECRM?11,$EC RM?12,$ECRM?13,$ECRM?14

Is this the exact conversion to use in nmea converter? I would like to add it to the manual as an example.

Can you attach some meaningful screenshots to be included?

Thanks.

[SamH]

OpenCPN 5.6.2 generates a buggy RMB, sent out as ECRMB, this workaround creates a new RMB, sent out as IIRMB and drops the buggy ECRMB.

Open nmeaConverter_pi->Preferences via the pluginmanager(Install if you dont have it), and Click button "New"




Copy, or retype exactly, the following conversion and paste it in the dialogwindow.

$IIRMB,$ECRMB1,$ECRMB2,$ECRMB3,$ECRMB5,$ECRMB4,$EC RMB6,$ECRMB7,$ECRMB8,$ECRMB9,$ECRM?10,$ECRM?11,$EC RM?12,$ECRM?13,$ECRM?14

Make sure the option "Send after update all variables" is checked.


This will create an new RMB-sentence with the origin/destination waypoints in the correct sequence.
OpenCPN uses EC as its default talkerID, if you for some reason have changed this talkerID update the conversion accordingly. The new sentence has talkerID II.

Now, if you dont drop the buggy RMB from output, openCPN will send them both and your autopilot will get really confused with origin/dest waypoints jumping all over the place.
To drop it, open the connection that sends info to your autopilot, and from the Output filtering section, Select "Drop sentences", click the ... button and select ECRMB from the list.




Now, OK and close the options window. Activate a route, or rightclick and "Navigate to here", while the route is still active you can find the IIRMB in the NMEA debugwindow, make absolutely sure there is no ECRMB beeing sent.

This is only a functional workaround as long as the bug exists in OpenCPN, v5.6.2 as we speak. When a new release with a fix is out, the conversion and filtering must be reversed, or this fix will cause the same issues as the bug does now.

[HeywoodJ]

I haven’t yet needed it because I don’t generally use RMB, bit I wanted to thank SamH for the clear, concise, well documented directions (complete with pictures ) for the workaround. Kudos. The