GPS firmware

[153957]

This issue concerns the GPS firmware rather than the HiSPARC firmware.
We occasionally see timestamps from the year 2019, even though that is still 3 years in the future.

The cause seems to be related to the week number in GPS time, which is an 8-bit value and thus 1024 possible values. Which can account for 1024 / 52 = 19.69 years. Every 19.96 years the week number will rollover and a new year reference will have to be used. This was apparently also a problem during the last rollover. GPS time started in 1980, so around August 1999 the last rollover occurred. Which is also why we see events from 1999. Trimble owns a patent (stolen idea) which should deal with this specifically. So it is probably implemented in the Resolution-T firmware. So possibly the reason we sometimes see April 2019 is because no GPS signal is received and the week number is 0 and the GPS thinks it is smart and starts from the next rollover...

More info:

• http://www.leapsecond.com/notes/gpswnro.htm
• https://www.spirent.com/Blogs/Positioning/2018/January/GPS-Rollover-Week

[davidfokkema]

Ah, nice to know where those dates came from. But what do you want to fix?

[153957]

Nothing in particular at the moment. It is just something to watch out for. I suppose that the firmware in the electronics is working fine, except that data for April 2019 will be less trustworthy. Because I expect that around that date (when it is actually 2019) and a station has a bad GPS it will result in dates around April 2019, not 1999 or 2039. It would be nicer if it returned 1999/2039 because those dates could be filtered out more easily.

[davidfokkema]

It is important to check the GPS status byte. If that indicates that the time is not to be trusted, it is not to be trusted. I don't know if LabVIEW processes and stores that information.

[153957]

Ah thats interesting, I do not think the LabView DAQ discards events based on that, or event checks that.

In the latest version of the LabView DAQ it does check if the GPS is correctly set to GPS time, it displays a red status LED to indicate if this is not the case. I am not certain what it does with events is reads, I think it does not discard them. The new DAQ also sends the GPS satellite number/signal strength to the storage. However, I think the timestamp attached to these messages is based on the PC time, but (should be) corrected to GPS time via the Hisparc.ini, but in case of such a bad GPS time there will be no valid value in the ini file.

[davidfokkema]

I checked, since I wasn't completely clear on where I found that information. It concerns the GPS Decoding Status which is reported in the Supplemental Timing Packet of the Trimble GPS receiver. I'm not even sure if the firmware receives that packet. It can be received by LabVIEW by reading out the GPS directly over USB, I guess, but then you can't use DSPMon anymore. Either way, if it is set to '1', the receiver doesn't have GPS time. I guess LabVIEW does not check this, the firmware does not check this, and everything is recorded and stored regardless.