SignalK
GPS Date Roll Over problem
GPS can return wrong date (day time will be correct) and signalk setdate and time plugin will set wrong date.
Also being discussed here:
https://forum.openmarine.net/showthread.php?tid=3572&pid=20237#pid20237
If this problem doesn’t exist in GLONASS, Beidou, Galileo might be solution would be never trust gps date and use date from from one of those in SignalK set date time plugin?
Thanks
@mgrouch how do you propose that we never trust gps date and use date from from one of those? A practical example: Digital Yacht Trinav supports GPS, GLONASS and Galileo, but the output is just RMC sentences, with no indication of what system's data is used. NMEA2000 GNSS data has even less data about what satellites are used for the fix than 0183.
A date adjustment mechanism that you can manually configure per connection would be pretty foolproof and support any input.
If a system will have multiple GNSS receivers and some produce bogus data you can configure source preferences to ignore data from those (as long as you get at least some valid data).
If all else fails one can configure a node-RED flow to do whatever filtering or adjusting, intercepting incoming data before it enters the server's processing.
That's all I can think of in the input side. In set-system-time we can add a lower limit to valid dates. I don't think it makes sense for the plugin to do any data adjustements - that should be on the input side.
Does Trinav use different talker IDs for Glonass, GPS, Galileo? I know ublox modules they do. GN/GL/GP Involving node red into solution would be overkill. It would be better to have it in ‘set system time’ plugin and have it configurable. Thanks
Sent from my iPhone
On Aug 7, 2021, at 7:42 AM, Teppo Kurki @.***> wrote:
@mgrouch how do you propose that we never trust gps date and use date from from one of those? A practical example: Digital Yacht Trinav supports GPS, GLONASS and Galileo, but the output is just RMC sentences, with no indication of what system's data is used. NMEA2000 GNSS data has even less data about what satellites are used for the fix than 0183.
A date adjustment mechanism that you can manually configure per connection would be pretty foolproof and support any input.
If a system will have multiple GNSS receivers and some produce bogus data you can configure source preferences to ignore data from those (as long as you get at least some valid data).
If all else fails one can configure a node-RED flow to do whatever filtering or adjusting, intercepting incoming data before it enters the server's processing.
That's all I can think of in the input side. In set-system-time we can add a lower limit to valid dates. I don't think it makes sense for the plugin to do any data adjustements - that should be on the input side.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Trinav is based on ublox, so I assume it does, but haven't tested. Nevertheless N2K has no "talker id" and even if some gnss receivers support multiple satellite systems there is a huge amount of systems that have just a single gps receiver.
I do no agree with having the fix in set-system-time, as that fixed just setting the system time, and leaves the erroneous data in the the Signal K data. The adjustment should happen so that the SK data is correct, using it for setting the system time is just one application of it.
I mentioned Node-RED / custom code as the solution offering ultimate flexibility, not what Joe Boater should be using.
Would an acceptable solution be, at least for supported hardware, to use GPSD which incorporate patches to cope with 2^10 week rollover leading to incorrect date being returned. The stable version 3.23.1 works flawlessly.
Best regards,
