GPS gviing wrong Date

[LifePart2]

Here is an NMEA sentence I just copied from my GPS (via OpenCPN's debug window)

$GPRMC,174049,A,2504.7520,N,07719.7329,W,000.0,000 .0,270403,,,A*6B<0x0D><0x0A>

It is giving me a date of 27/04/2003 (obviously wrong) and a time of 17:40:49 (correct).

Does that mean my GPS receiver is broken? Or is there something somewhere that could be changing the data?

Anything I can do in OpenCPN to get around that? Or do I just need to buy a new GPS antenna?

[sv_pelagia]

Likely an older GPS dystem suffering from GPS date rollover. Older Furuno, for example.

My excellent Furuno chartplotter/radar (circa 2008) gas this issue. Lat/long etc all correct, just not dates. (Not fixable for my system.)

[AedanC]

There is a firmware fix for some models of GPS but not all.

[LifePart2]

The GPS is a Standard Horizon 'smart' gps. Not sure of the model number.
Never thought of a a firmware update. That would certainly do the job if I can find one.

[sv_pelagia]

https://panbo.com/gps-date-rollover-...der-gps-units/

[hoolie]

It's a known problem with older GPS kit. Probably you'll just have to live with it ... ...

[LifePart2]

ok, no problem. Thanks for enlightening me.

I don't suppose there is a way to edit the date field on the fly? Presumably it is a constant offset.

It's not really a problem, but when I click on a tide chart in O it gives me the tides for 2003, and then I have to manually change the date. This is on my RPI where I am getting the date from the GPS

[LeaseOnLife]

What else are you running on the PI? I had made a crude node-red flow to add 1024 weeks to the GPS date to correct for the wrong date from my old Furuno GP-32 GPS.


If you run signalk on the PI, then you could use their add-on to run node-red within signalk and do that correction in there.


There is also a commercial product doing this and much more, called "Pitufino", developed and marketed by a fellow cruiser. Full disclosure: I have a Pitufino now..

[SailFastTri]

If you’re using GPS date as a reference for system date, it can affect other navigation calculations e.g. tides and currents

[LifePart2]

Originally Posted by LeaseOnLife

What else are you running on the PI? I had made a crude node-red flow to add 1024 weeks to the GPS date to correct for the wrong date from my old Furuno GP-32 GPS.


If you run signalk on the PI, then you could use their add-on to run node-red within signalk and do that correction in there.


There is also a commercial product doing this and much more, called "Pitufino", developed and marketed by a fellow cruiser. Full disclosure: I have a Pitufino now..

The Pi is being run in OpenPlotter receiving data through SignalK, but no other apps are run on it.

That Pitufino does look very interesting but is currently more than I need.

However a simple script to add some weeks to the date sounds perfect. Are you able to share the 'how to' for that?

Thanks
Noel

[LeaseOnLife]

I do have the old node-red flow, but don't have node-red installed to check and help..
When importing this flow, it will likely complain about missing nodes, you would have to install a few more nodes, via the node-red palette Manager.


Glancing thru the script, here is what I think it does:


The flow reads serial data from "/dev/FakeProlificRS232" (a USB to RS232 converter I named that way via udev).

It only uses GGA, GLL and RMC, all other sentences are dropped. RMC is modified with a date +1024 weeks from the original sentence and a new checksum is calculated.

Output is via UDP port 10108.
The attached file is a text file, remove the pdf extension after download. That text file then can be imported into your node-red installation.

[P_Dub]

Download Visual GPS and check if the date received is correct. If so then it is your computer time.

[LifePart2]

Thank you for that node red file. It will take me a little while to figure out how to use it :-)

Yes, it is definitely the RMC sentence that has the wrong date in it.

Standard Horizon tech support said there are no firmware updates available and the normal life expectancy of their smart gps antennae is only 8-10 years anyway!

The trouble is the unit is well glued (previous owner) into my coachroof, so it is not a trivial matter to replace the unit. One expects these things to last longer than that!

Noel

[Be Free]

Noel,
The unit is not broken. It is still doing everything it did when it was new. The problem is that the GPS signal only allows 10 bits for the week number. In the GPS world week number 1024 (2 to the tenth power) was April 4, 2019 (IFRC). After that the counter just started over.

Your GPS uses the week number to calculate (what it thinks) is the current date and time. Unfortunately when it was programmed it did not allow for this which means it is 1024 weeks behind. It's the same programming issue that caused the infamous Y2K bug except that Y2K made dates be off by 100 years instead of around 20 years.

Your GPS manufacturer decided to "cheap out" in two ways. First, they could have programmed later versions of the firmware that would have interpreted the week number normally until it rolled over and then used a different epoch (starting date) to calculate the lower week numbers. That would have been good for 20 years or so from the date off manufacture. That's how a lot of Y2K fixes were done when a full rewrite was not feasible. This would have been relatively cheap and transparent to the end user.

Another solution would have been to build in a mechanism to update the firmware on the device and then provide an updated image that would fix the problem. Unfortunately that would have required making a significant change in the cabling and programming to fix a problem that would happen at most one time during the lifetime of the product.

Since we know the rollover has already happened, the Node Red routine is a simplified version of what they could have implemented in firmware. It will always add 1024 weeks to the date the GPS reports which will correct the miscalculation in the date.


Lacking specific information about the data flows on your PI, generically, the Node Red routine needs to be between the GPS antenna and anything that cares about the date.

The Node Red routine will need to know how the data from the GPS is being transmitted and modified to use this as input (serial, TCP, UDP, carrier pigeon....).

Anything that cares about the date needs to listen on UPD 10108 (the output of the Node Red routine).

If you can fill in details on the wiring and data flow I can be more specific on what needs to change.


Good luck.

[LifePart2]

The data flow is pretty simple:

NMEA from the GPS goes by bare wires to the Standard Horizon Matrix 2000 radio (so that we can turn it on without firing pu the charplotter).

From there it goes by bare wires to the Quark Multiplexer where it gets mixed in with the SeaTalk data (wind, depth etc). If I turn on the AIS that also gets mixed in here. The AIS also has a GPS that works fine, but the Quark does not have the option of filtering by priority, so both GPS sentences go to OpenCPN (and cause some boat bouncing around).

Then by USB to the RPI where it is read by OpenPlotter. and converted into SignalK. The data also goes by wifi from the Quark to my laptop and straight into OpenCPN on Windows 10.

From SignalK it goes internally to OpenCPN port 3000.

On both the RPI and my laptop I also get the occasional position jump to the equator or some other distant position. So I am presuming that there are other malformed sentences coming from somewhere. Can NodeRed also discard sentences with a Lat or Long of exactly zero?

I was thinking of eliminating the basic GPS by sending the AIS sentences to the radio first but that means that i have to turn on the AIS all the time too, which I don't need in daylight in most situations. Also I thing the sheer quantity of data means the RMS sentences get crowded out at times, temporarily giving me no position fix or SOG/COG for a few seconds. At lease I presume that is why I sometimes lose that data.

At times the boat heading on the RPI gets stuck, so the boat is apparently pointing in the wrong direction for many minutes at a time. This does not happen on the laptop, so is again maybe related to the overcrowding of data?

So that is it. A few annoying glitches going on intermittently. Would be nice to get it all straightened out some how.

Any suggestions on how to put it together better would be welcome. I have never used NodeRed so that would be a new learning curve for me.