search

seandepagnier / autopilot_route_pi

autopilot route plugin for opencpn
5 stars 7 forks source link

Generated RMC messages sometimes show 'nan' for SOG, TMG #35

Open marcobergman opened 1 year ago

marcobergman commented 1 year ago

Example: 21:59:36 (virtual) $ECRMC,195936,A,5255.309,N,00422.908,E,nan,nan,030723,2.126,E,*40<0x0D><0x0A>

Pypilot does not like this: failed to decode data socket! nmea pipe[1] Expected object or value line {"gps":{"timestamp":1688414777.3264036,"speed":NaN,"lat":52.92181666666667,"lon":4.381799999999999,"track":NaN,"device":"ECsocket5"}}

Windows OpenCPN 5.8.4; plugin 0.4.9.0 (from the master plugin catalog)

Does not always happen; I'll try to replicate on linux so I can debug the code. Stand by.

marcobergman commented 1 year ago

Ok, figured it out. This situation occurs in a simulated environment when a standalone OpenCPN is not connected to SignalK or another source of sog, cog data (e.g. RMC messages).

The stock OpenCPN route following algorithm allows this situation, filling cog and sog with 0 values. It would save others time troubleshooting if the autopilot_route plugin would also allow this situation.

marcobergman commented 10 months ago

It's a bit worse than I said earlier. Even when I provide a proper RMC message to OpenCPN, the plugin generates a message with nan's in it. What's worse, is that this goes back into OpenCPN again (it seems) and make the boat sit still on the canvas, as if OpenCPN cannot decide what to do with conflicting messages. Obvious workaround would be to NOT check the RMC checkbox, but this was a very time consuming problem to defuse; it would be better NOT to generate RMC messages if any of these values is NaN.

From the NMEA debug window:

<GREEN>17:00:51 (UDP:0.0.0.0:10110)     $GPRMC,160050,A,5255.3304,N,00421.1736,E,6.0,264.767,111123,,,A,C*1B<0x0D><0x0A>
<GREEN>17:00:51 (virtual)       $ECRMC,160051,A,5255.552,N,00423.780,E,nan,nan,111123,2.206,E,*40<0x0D><0x0A>