Ideas on GPS week rollover

[ljbade]

The next GPS rollover is in 2019, which isn't that far away and likely in the lifetime of current receivers.

The cause is that GPS WN is broadcast to 10 bits so is mod 1024 of the real WN, which is currently between 1024-2047 since the last rollover in 1999.

Currently we hardcode that we are in 1024-2047, so in WN 2048 the receiver will warp back to 1999. Many of our time functions will also break as they do not check for roll over.

At a minimum the current WN range should be a setting to allow users to update it in the future.

We should also encode the compile date of the firmware to allow us to compute a valid WN for 20 years after shipping.

Finally we could have the Piksi console update these settings from the local computer's clock, so that a Piksi will have a valid date for 20 years after connecting it to the console.

For an example of how u-blox handle this, read https://forum.u-blox.com/index.php?qa=60&qa_1=what-week-rollover-roll-over-and-handled-blox-gnss-receivers

/cc @mookerji @fnoble

[ljbade]

A similar technique is mentioned in http://gauss.gge.unb.ca/gpsworld/gpsworld.november98.pdf

It is also possible to update the value in flash automatically.

They also point out a real time clock is useful for this too.