[time-nuts] Setting correct date on Trimble Thunderbolt receiver

[Tom Van Baak]

> Tom,
>
> In my TB monitor kit, I used your Julian date routines, adapted to the 8051
> (no variable greater than 32 bits since my compiler does not support them
> either) to apply the GPS offset correction. It was very helpful.
>
> Didier KO4BB

Right. There are many ways to address the 1024 week rollover. Mark uses JD and floating point because his program contains lots of astronomical features and JD is useful and popular in that context. I suspect the code you're using is from this demo -- http://leapsecond.com/tools/tbolt1.c -- which is based on MJD and integer only.

The code I mentioned today -- http://leapsecond.com/tools/gpsdn.c -- is similar except its based on GPSDN instead of MJD. I came up with GPSDN because it's easier to work with GPS cycles when the origin of GPS time is GPSDN = 0 instead of something like MJD = 44244, or JD = 2444244.5, or unix_time_t = 315964800, or Excel date 29226.

If you display GPSDN as hex or binary, GPS rollovers are a picture-worthy ripple-carry binary odometers:

1999-08-21 = GPSDN 7167 = 0x1BFF = 0b1101111111111
1999-08-22 = GPSDN 7168 = 0x1C00 = 0b1110000000000

2019-04-06 = GPSDN 14335 = 0x37FF = 0b11011111111111
2019-04-07 = GPSDN 14336 = 0x3800 = 0b11100000000000

2038-11-20 = GPSDN 21503 = 0x53FF = 0b101001111111111
2038-11-21 = GPSDN 21504 = 0x5400 = 0b101010000000000

2058-07-06 = GPSDN 28671 = 0x6FFF = 0b110111111111111
2058-07-07 = GPSDN 28672 = 0x7000 = 0b111000000000000

While I'm at it, and for newcomers to the group, note that GPS rollovers occur about every 19.6 years (1024 weeks) and occur in "GPS time", which is offset from "UTC time" by a particular number of leap seconds. That's why GPS rollovers do not occur at precisely midnight on the dates listed above. Also why it's not possible to list the exact time of future GPS rollovers as UTC date & time. Hint: stay well away from self-driving vehicles during leap seconds and GPS rollovers.

/tvb