When SIgnalK has a lost GPS message, it is not reflected in UI or generated Autopilot Sentences

[TwoCanPlugIn]

When SignalK is receiving position data from a NMEA 0183 GPS it reflects field 6 (GPS Quality Mode Indicator) in the delta message.

Eg.
{"updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"timestamp":"2024-04-09T22:45:34.000Z","values":[{"path":"navigation.position","value":{"longitude":144.5,"latitude":-38.18333333333333}},{"path":"navigation.gnss.methodQuality","value":"no GPS"},{"path":"navigation.gnss.satellites","value":10},{"path":"navigation.gnss.antennaAltitude","value":1113},{"path":"navigation.gnss.horizontalDilution","value":0.98},{"path":"navigation.gnss.differentialAge","value":25},{"path":"navigation.gnss.differentialReference","value":10}],"$source":"NMEA183-UDP.GP"}],"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb"}

if OpenCPN has an Active Route it generates the following erroneous sentences

$ECRMB,A,0.000,L,001,002,3803.798,S,14444.997,E,13.847,58.596,0.000,V,A*62
$ECRMC,054105,A,3811.000,S,14430.000,E,0.000,0.000,100424,,,,A*5F
$ECAPB,A,A,0.000,L,N,V,V,58.596,T,002,58.596,T,58.596,T*06
$ECXTE,A,A,0.000,L,N*4F

Refer to #3452 for how the RMB, APB and XTE sentences should reflect the GNSS status

These are the SignalK deltas for each of the valid NMEA 0183 GPS Quality Mode Indicator values (0-8)
{"path":"navigation.gnss.methodQuality","value":"no GPS"}
{"path":"navigation.gnss.methodQuality","value":"GNSS Fix"}
{"path":"navigation.gnss.methodQuality","value":"DGNSS fix"}
{"path":"navigation.gnss.methodQuality","value":"Precise GNSS"}
{"path":"navigation.gnss.methodQuality","value":"RTK fixed integer"}
{"path":"navigation.gnss.methodQuality","value":"RTK float"}
{"path":"navigation.gnss.methodQuality","value":"Estimated (DR) mode"},{"path":"navigation.gnss.methodQuality","value":"Manual input"}{"path":"navigation.gnss.methodQuality","value":"Simulator mode"},

If the NMEA GGA sentence contains an invalid value for GPS Quality Mode Indicator (<0, >8), SignalK DOES NOT return navigation.gnss.methodQuality namespace (I don't know if that should be considered a bug in SignalK ?)

If the NMEA GGA sentence contains a null value for GPS Quality Mode Indicator , SignalK returns.
{"path":"navigation.gnss.methodQuality","value":"no GPS"}

pseudo code

GPS Status = Invalid
if root["navigation"]["gnss"].HasMember("methodQuality"))
if root["navigation"]["gnss"].[methodQuality"].AsString = GNSS or DGNSS
GPS Status is Valid

I don't know about Precise DNSS, or RTK, I've never seen these, so unsure how you should handle, presumably they are valid fixes.

Side note, the Satellite Icon does not reflect GPS status when receiving SignalK

[Hakansv]

The "no GPS" status is not reliable what I've seen.
Testing on a Simrad GS-25 by covering the device.
Eventually he returned 3 satellites and OCPN detected that as "No position" and GPS compass window is not green and boat symbol grey.
The Simrad device still reported "GPS fix" and so "navigation.gnss.methodQuality" After yet some rather long time the device shifted to "No GPS". So I'd consider this navigation.gnss.methodQuality is not a reliable key to use.

[TwoCanPlugIn]

Hi Hakan,

You have far more experience with SignalK than I, as far as I can tell, there is no other key to use, there is only navigation.gnss,methodQuality

From my observations.

1. For NMEA 0183 it only parses GGA sentences . GGA sentences do have a GPS Quality Indicator field. On the other hand, GLL sentences are not parsed and only have a Status and Positioning System Mode Indicator field.
2. For NMEA 2000 , PGN 129029 has a Method field, that kind of corresponds to the GPS Quality Indicator field of a GGA sentence.
   So it seems as though network.gnss.methodQuality is the only key that reflects the GPS status for both NMEA 0183 & 2000 ?

When your Simrad GS-25 has lost a fix, in addition to the "no GNSS" value, in PGN 129029, were lat and long set to ULLONG_MAX, meaning data unavailable?

And I guess no one has tested O to make sure it exhibits the correct behaviour when receiving NMEA 2000 and generating and outputting NMEA 0183 APB, RMB and XTE sentences.

[Hakansv]

My tests was not about the system handling the GNSS info, PGN or PGN->Signalk or N0183.
It was more about the reliance of the quality flag from the GNSS device, e.g. "GPS Fix" or "No GPS". OCPN don't use that and there where other discussions about that.
The conclusion was it's not a good flag unless just starting up the device. During run time and any circumstances making the satellite reception bad. Then it takes to long time until the device report "No GPS".
We better trust the quality check done in OCPN for a long time. No position or to few satellites ( <=3). That report from the GNSS device is more trustful and available from different messages, whether it's N0183, N2000 or SignalK.
OCPN's "No position" flag results in a red GPS compass icon and grey ship symbol.
We now also use it to set the (CE)RMB to AP quality flag to "N". We can also use it to set a corresponding flag in the general AP PGN to AP if we implement that?

Your discussion about continuing to transfer a active route data to a AP when the position flag is low I think is valid. We may inactivate a route if there's no own ship position? But I can't embrace all possible implications for the moment. .....?

[bdbcat]

This issue relates to specific design behavior of available signalK servers.
AFICT, OCPN does the correct thing relative to the GNSS status info available in the sK messages.
One more request for comment before closing.

[TwoCanPlugIn]

My testing involved sending SignalK Server various GGA sentences, with different values for field 6, the GPS Quality indicator.

When a GGA sentence with a GPS Quaity Indicator vakue of 0 (No Fix) was sent to SignalK, it was parsed correctly resulting in the following delta:
{"path":"navigation.gnss.methodQuality","value":"no GPS"},

However OpenCPN generated incorrect APB, RMB and XTE sentences upon reception of that delta.

I'm nowhere near my boat and without my SignalK server, so someone else should test this to verify my observations with a real GPS. The one omission on my part is that during my testing I may not have generated correct GGA sentences for a lost fix, I don't recall setting the lat & long values to null even though I set the GPS Quality Indicator field to 0.

I can't confirm what values a NMEA 0183 GPS sends when it has lost a fix. I know from previous observations they are null until it has obtained a fix, but I don't know what happens when a fix is lost. Are lat & long null values and the GPS Quality indicator field also set to 0 (No fix).

I'm also not sure what SignalK generates for navigation.position when NMEA 0183 GGA sentences contain null values for lat & long ?

[bdbcat]

Without need to discuss what sK server does or does not do with GGA, we can say that if sK says "quality" = "no GPS" then O should not try to transmit Autopilot commands.
That is a clear bug.
Holding this Bug open.

[bdbcat]

Corrected response to "quality" = "no GPS".
For autopilot output, I chose to discontinue autopilot update whenever GNSS is judged invalid or unusable.
One assumes that any reasonable autopilot will raise an alarm if update sentences are stopped for some watchdog period. To me, this seems safer than assuming the A/P will honor validity flags in the APB/RMB messages.

@hakan:
Might be good to test with your "soup-pot" GNSS signal interrupter.

[Hakansv]

I'm in the boat and can't reach the pot. :)
But:
The "pot" test is not good since the number of reported satellites are low far before the "no GPS" parameter is set by the device. So then we have already set bGPSValid=false.
And with the new - if (!bGPSValid) return false; - we have already stopped to update Autopilot messages. And, yes, then will the AP time out due to no received updates. Agree.

Now we have both "braces and belt": Not sufficient number of satellites and "no GPS", good. If a device can report not enough satellites but still "GPS fix" the vice verse may happen as well. We are safe.

[bdbcat]

I think we are done here.
Further thoughts?

[TwoCanPlugIn]

I could use the same "test harness" as before to get SignalK to transmit the appropriate deltas.

At what stage does a low number of satellites affect OpenCPN ?

If the user happens (or inadvertently) filters out all but GGA & RMC, neither of which indicate the number of satellites, what will OpenCPN do when the SignalK deltas indicate a GPS Fix, but no satellites?

[bdbcat]

With satellite count = zero, OCPN 59 will honor "navigation.gnss.method" delta, and show a valid fix with green ball instead of multi signal bars.
That is to say, "navigation.gnss.methodQuality" report is the controlling factor for sK data stream validity.

[TwoCanPlugIn]

This has yet to make it to the nightly build ?

I'm seeing no difference yet.

One other aside.

If O does not receive any deltas from SignalK, the autopilot sentences stop. Admittedly a decent autopilot will time out and behave properly (sound an alarm, disengage), but I would have assumed that O would continue to send autopilot sentences every second albeit with the status fields set to 'V' (Invalid) and the Mode Indicator field et to 'N' (Data not valid) until the navigation is halted.

[Hakansv]

Your suggestion to trust an AP to read mode indication or GNSS quality data may be valid for modern APs.
For the old fashion AP still present in many boats, like mine, they don't list these data as extracted from the listed sentences. So my view is we should keep it as is: No data is sent to AP when no stable position fix. Then also old AP will alarm and switch off "Nav lock" or what it's called on different makes.

[bdbcat]

"This has yet to make it to the nightly build ?"
To what part are you referring?
The build is up-to-date with current discussion. What is missing?

[TwoCanPlugIn]

It doesn't seem to work.

This is sent to SignalK via NMEA 0183 over UDP

00:16:15.81 $GPGGA,001615,3811.00,S,14430.00,E,1,10,0.98,1113.0,M,-21.3,M,25,10*7C
00:16:15.82 $GPGLL,3811.00,S,14430.00,E,001615.00,A,A*7E
00:16:15.82 $GPRMC,001615.80,A,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,A*2A
00:16:15.83 $IIMWV,190.0,R,11.4,N,A*01
00:16:15.84 $SDDPT,3.0,-0.3,100.0*79
00:16:15.84 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:15.84 $HDHDG,170.0,7.5,E,0.0,W*53
00:16:16.85 $GPGGA,001616,3811.00,S,14430.00,E,1,10,0.98,1113.0,M,-21.3,M,25,10*7F
00:16:16.85 $GPGLL,3811.00,S,14430.00,E,001616.00,A,A*7D
00:16:16.86 $GPRMC,001616.85,A,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,A*2C
00:16:16.86 $IIMWV,190.0,R,11.4,N,A*01
00:16:16.87 $SDDPT,3.0,-0.3,100.0*79
00:16:16.88 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:16.88 $HDHDG,170.0,7.5,E,0.0,W*53
00:16:17.89 $GPGGA,001617,3811.00,S,14430.00,E,0,10,0.98,1113.0,M,-21.3,M,25,10*7F
00:16:17.90 $GPGLL,3811.00,S,14430.00,E,001617.00,V,N*64
00:16:17.90 $GPRMC,001617.89,V,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,N*39
00:16:17.90 $IIMWV,190.0,R,11.4,N,A*01
00:16:17.90 $SDDPT,3.0,-0.3,100.0*79
00:16:17.91 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:17.91 $HDHDG,170.0,7.5,E,0.0,W*53
00:16:18.91 $GPGGA,001618,3811.00,S,14430.00,E,0,10,0.98,1113.0,M,-21.3,M,25,10*70
00:16:18.93 $GPGLL,3811.00,S,14430.00,E,001618.00,V,N*6B
00:16:18.93 $GPRMC,001618.91,V,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,N*3F
00:16:18.94 $IIMWV,190.0,R,11.4,N,A*01
00:16:18.94 $SDDPT,3.0,-0.3,100.0*79
00:16:18.95 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:18.96 $HDHDG,170.0,7.5,E,0.0,W*53
00:16:19.97 $GPGGA,001619,3811.00,S,14430.00,E,0,10,0.98,1113.0,M,-21.3,M,25,10*71
00:16:19.98 $GPGLL,3811.00,S,14430.00,E,001619.00,V,N*6A
00:16:19.98 $GPRMC,001619.97,V,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,N*38
00:16:19.99 $IIMWV,190.0,R,11.4,N,A*01
00:16:20.00 $SDDPT,3.0,-0.3,100.0*79
00:16:20.00 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:20.01 $HDHDG,170.0,7.5,E,0.0,W*53
00:16:21.02 $GPGGA,001621,3811.00,S,14430.00,E,0,10,0.98,1113.0,M,-21.3,M,25,10*7A
00:16:21.02 $GPGLL,3811.00,S,14430.00,E,001621.00,V,N*61
00:16:21.03 $GPRMC,001621.02,V,3811.00,S,14430.00,E,6.5,180.5,010524,8.5,E,N*3F
00:16:21.03 $IIMWV,190.0,R,11.4,N,A*01
00:16:21.04 $SDDPT,3.0,-0.3,100.0*79
00:16:21.04 $SDVHW,,T,,M,5.7,N,10.4,K*75
00:16:21.04 $HDHDG,170.0,7.5,E,0.0,W*53

At 00:16:17 I "lost the GPS fix"

This is the output from SignalK (filtering on navigation.position & navigation.gnss.gpsMethodQuality)

00:16:18.17 {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-04-30T00:16:16.000Z","values":[{"path":"navigation.gnss.methodQuality","value":"GNSS Fix"}]}]}
00:16:18.95 {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"RMC","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-01T00:16:17.000Z","values":[{"path":"navigation.position","value":{"longitude":144.5,"latitude":-38.18333333333333}}]}]}
00:16:19.07 {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-04-30T00:16:17.000Z","values":[{"path":"navigation.gnss.methodQuality","value":"no GPS"}]}]}
00:16:20.07 {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"RMC","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-01T00:16:18.000Z","values":[{"path":"navigation.position","value":{"longitude":144.5,"latitude":-38.18333333333333}}]}]}
00:16:20.18 {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-04-30T00:16:18.000Z","values":[{"path":"navigation.gnss.methodQuality","value":"no GPS"}]}]}

At 00:16:19 SignalK reports the subsequent No GPS.

Here is the OpenCPN NMEA 0183 serial output with an Active Route. (Note that OpenCPN still shows 3 green bars for the GPS status)

The Autopilot output does not reflect the lost GPS signal

00:16:17.46 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:17.47 $ECRMC,221617,A,3811.000,S,14430.000,E,6.500,180.500,300424,0.000,E,A*11
00:16:17.47 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:17.48 $ECXTE,A,A,0.000,L,N*4F
00:16:18.49 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:18.50 $ECRMC,221618,A,3811.000,S,14430.000,E,6.500,180.500,300424,0.000,E,A*1E
00:16:18.50 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:18.50 $ECXTE,A,A,0.000,L,N*4F
00:16:19.51 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:19.51 $ECRMC,221619,A,3811.000,S,14430.000,E,6.500,180.500,300424,0.000,E,A*1F
00:16:19.52 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:19.52 $ECXTE,A,A,0.000,L,N*4F
00:16:20.55 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:20.55 $ECRMC,221620,A,3811.000,S,14430.000,E,6.500,180.500,300424,0.000,E,A*15
00:16:20.56 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:20.56 $ECXTE,A,A,0.000,L,N*4F
00:16:21.56 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:21.57 $ECRMC,221621,A,3811.000,S,14430.000,E,6.500,180.500,300424,8.500,E,A*19
00:16:21.57 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:21.57 $ECXTE,A,A,0.000,L,N*4F
00:16:22.60 $ECRMB,A,0.000,L,001,002,3803.886,S,14437.414,E,9.199,39.347,-5.062,V,A*70
00:16:22.60 $ECRMC,221622,A,3811.000,S,14430.000,E,6.500,180.500,300424,8.500,E,A*1A
00:16:22.60 $ECAPB,A,A,0.000,L,N,V,V,39.347,T,002,39.347,T,39.347,T*0B
00:16:22.61 $ECXTE,A,A,0.000,L,N*4F

Perhaps my "lab testing" is not indicative of the real world, or watching three scripts logging traffic is doing my head in. Or maybe there are too many moving parts. Also I'm not entirely sure that when the GPS has no fix whether the latitude & longitude fields should be null in the respective NMEA sentences nor how SignalK should behave. Maybe Hakan should perform the cooking pot test.

Re @Hakansv

or the old fashion AP still present in many boats, like mine, they don't list these data as extracted from the listed sentences.

Totally agree, Maybe have a "Legacy Mode" checkbox. Just kidding...

[bdbcat]

@TwoCanPlugIn
It looks to me as though your test setup is valid, should work.
Perhaps you could do some source debugging to figure out why the "no GPS" is not recognized.
All the action happens at:

void CommDecoder::updateItem(const rapidjson::Value &item,
wxString &sfixtime, NavData& temp_data)

The way we set the "GPS Invalid" flag is this:

1. We keep a static variable recording the last received state of "methodQuality"
2. When parsing position update, if the last "methodQuality" was "no GPS", we set the position latitude as NAN.
3. The NAN value of latitude will cause the position watchdog to timeout, thus setting "GPS Invalid".
4. "GPS Invalid" state will stop output.

I tested this logic with a contrived setup, no real GPS. And it worked.

Should be possible to catch some of this by setting some strategic breakpoints.
Good luck. Happy to help as you get into it.

[Hakansv]

"This is sent to SignalK via NMEA 0183 over UDP"
With these N0183 we have satellites from GGA and also position.
Most probably SK does send "navigation.gnss.satellites" based on the GGA?
I'm not at home so haven't tested on a SK but if we receive "no GPS" the "GNSS_quality_map" is set to "0" and no AP output. But if we some second(s) later receive "navigation.gnss.satellites" vale = 10 and have a position the AP EC-sentences are sent until "no GPS" is again received. And so on.

So... how could a valid system both report 10 satellites, a position and "no GPS"? Troubled test data?

GPGGA,001617,3811.00,S,14430.00,E,0,10,0.98,1113.0,M,-21.3,M,25,10*7F

[bdbcat]

Without further comment or test results, closing this issue now.
Steve, any further thoughts on your test setup?

[TwoCanPlugIn]

In between some fibreglass repairs and looking at Timo's NGT-1 fix.....

Updated the NMEA0183 test script to simulate a lost GPS fix (null values for lat & long, satellites = 0 and the other flags to indicate a lost fix.

SignalK appears to respond accordingly.

OpenCPN stops sending autopilot sentences (ECRMB, EXAPB, ECXTE), which I guess keeps users of older autopilots happy (and probably by definition, possibly current autopilots), but it doesn't change the validity fields for these sentences. I personally would have expected that the generated RMB, APB and XTE sentences would correctly reflect that lost fix flags but if that is the design criteria, so be it and feel free to close.

Note that the OpenCPN Satellite does turn red to indicate a lost fix. I also noted that the generated XTE sentence omits the FAA Mode Indicator field, but I think we've had that discussion before.

Here are the three dumps.
NMEA 0183 input sent to SignalK.

18:40:57.76 $GPGGA,184057,3810.02,S,14432.52,E,1,10,0.98,1113.0,M,-21.3,M,25,10*76
18:40:57.76 $GPGLL,3810.02,S,14432.52,E ,184057.00,A,A*54
18:40:57.76 $GPRMC,184057.76,A,3810.02,S,14432.52,E,100.00,045.00,190524,8.5,E,A*2F
18:40:57.76 $WIMWV,190.0,R,11.4,N,A*1F
18:40:57.76 $SDDPT,3.0,-0.3,100.0*79
18:40:57.76 $SDVHW,,T,,M,100.0,N,054.0,K*42
Lost GPS Fix
18:40:58.76 $GPGGA,184058,,,,,0,0,0.98,1113.0,M,-21.3,M,25,10*60
18:40:58.76 $GPGLL,,,, ,184058.00,V,N*6A
18:40:58.76 $GPRMC,184058.76,V,,,,,100.00,045.00,190524,8.5,E,N*11
18:40:58.76 $WIMWV,190.0,R,11.4,N,A*1F
18:40:58.76 $SDDPT,3.0,-0.3,100.0*79
18:40:58.76 $SDVHW,,T,,M,100.0,N,054.0,K*42
18:40:59.77 $GPGGA,184059,,,,,0,0,0.98,1113.0,M,-21.3,M,25,10*61
18:40:59.77 $GPGLL,,,, ,184059.00,V,N*6B
18:40:59.77 $GPRMC,184059.77,V,,,,,100.00,045.00,190524,8.5,E,N*11
18:40:59.77 $WIMWV,190.0,R,11.4,N,A*1F
18:40:59.77 $SDDPT,3.0,-0.3,100.0*79
18:40:59.77 $SDVHW,,T,,M,100.0,N,054.0,K*42

The subsequent SignalK responses. (appears to correctly reflect the lost GPS signal)

18:40:57.83   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"RMC","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:57.000Z","values":[{"path":"navigation.position","value":{"longitude":144.542,"latitude":-38.167}}]}]}
18:40:57.94   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:57.000Z","values":[{"path":"navigation.gnss.methodQuality","value":"GNSS Fix"}]}]}
18:40:58.07   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:57.000Z","values":[{"path":"navigation.gnss.satellites","value":10}]}]}
18:40:58.95   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"RMC","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:58.000Z","values":[{"path":"navigation.position","value":{"longitude":null,"latitude":null}}]}]}
18:40:59.06   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:58.000Z","values":[{"path":"navigation.gnss.methodQuality","value":"no GPS"}]}]}
18:40:59.06   {"context":"vessels.urn:mrn:signalk:uuid:1cb1a66a-814c-4478-8b84-701eec9524bb","updates":[{"source":{"sentence":"GGA","talker":"GP","type":"NMEA0183","label":"NMEA183-UDP"},"$source":"NMEA183-UDP.GP","timestamp":"2024-05-19T18:40:58.000Z","values":[{"path":"navigation.gnss.satellites","value":0}]}]}

and the NMEA 0183 autopilot output. (appeasr to be some delay, not sure if it is O or my stuff)

18:41:03.14 $ECRMB,A,0.050,R,,001,3758.397,S,14449.223,E,17.582,48.528,99.811,V,A*74
18:41:03.14 $ECRMC,164102,A,3810.020,S,14432.520,E,100.000,45.000,190524,8.500,E,A*2E
18:41:03.14 $ECAPB,A,A,0.050,R,N,V,V,48.364,T,001,48.528,T,48.528,T*14
18:41:03.14 $ECXTE,A,A,0.050,R,N*54
18:41:04.18 $ECRMB,A,0.050,R,,001,3758.397,S,14449.223,E,17.582,48.528,99.811,V,A*74
18:41:04.18 $ECRMC,164103,A,3810.020,S,14432.520,E,100.000,45.000,190524,8.500,E,A*2F
18:41:04.18 $ECAPB,A,A,0.050,R,N,V,V,48.364,T,001,48.528,T,48.528,T*14
18:41:04.18 $ECXTE,A,A,0.050,R,N*54
18:41:05.21 $ECRMB,A,0.050,R,,001,3758.397,S,14449.223,E,17.582,48.528,99.811,V,A*74
18:41:05.21 $ECRMC,164104,A,3810.020,S,14432.520,E,100.000,45.000,190524,8.500,E,A*28
18:41:05.22 $ECAPB,A,A,0.050,R,N,V,V,48.364,T,001,48.528,T,48.528,T*14
18:41:05.22 $ECXTE,A,A,0.050,R,N*54
18:41:05.99 $ECRMB,A,0.050,R,,001,3758.397,S,14449.223,E,17.582,48.528,99.811,V,A*74
18:41:05.99 $ECRMC,164105,A,3810.020,S,14432.520,E,100.000,45.000,190524,8.500,E,A*29
18:41:05.99 $ECAPB,A,A,0.050,R,N,V,V,48.364,T,001,48.528,T,48.528,T*14
18:41:05.99 $ECXTE,A,A,0.050,R,N*54
18:41:07.02 $ECRMB,A,0.050,R,,001,3758.397,S,14449.223,E,17.582,48.528,99.811,V,A*74
18:41:07.02 $ECRMC,164106,A,3810.020,S,14432.520,E,100.000,45.000,190524,8.500,E,A*2A
18:41:07.02 $ECAPB,A,A,0.050,R,N,V,V,48.364,T,001,48.528,T,48.528,T*14
18:41:07.02 $ECXTE,A,A,0.050,R,N*54

[Hakansv]

I think the delay is the 10 sec GPS timeout also seen in the log file?
In other words: O admit the GNSS receiver to reestablish for 10 seconds before we "cut off"

[bdbcat]

Closing as completed