Setting correct date on Trimble Thunderbolt receiver
Lady Heather's automatic rollover fixer works by looking at the year in any time message that it sees. If it sees 10 consecutive year values less than 2016, it assumes the receiver has rollover issues and then adds 1024 weeks worth of seconds to the Julian date/time calculated from the receiver time/date message until the resulting year is past 2016.
One problem with this is when a receiver is first powered up... most of them send dates in the 1980s to 1990s until they start tracking satellites. Once Heather detects a rollover condition, the code does not currently undo it if the receiver starts sending good dates.
Heather keeps all times as a double precision Julian date. Using Heather's code can be a problem on Arduinos since their "double" precision numbers are actually 32 bit single precision, so you would need to do some more complicated math.
Heather's rollover compensation value is actually in double precision seconds. You can manually specify a rollover correction to sub-second resolution and tweak the displayed time/date to anything you want... comes in handy for testing calendar/eclipse/sunrise/sunset/etc code.
Speaking of rollovers, the GPS system has a 1024 week rollover next year (April 6th-7th). A lot of older receivers had code that could handle the first system rollover in 1999, but might have issues this time.
Hi Mark,
Heather keeps all times as a double precision Julian date. Using Heather's code can
be a problem on Arduinos since their "double" precision numbers are actually 32 bit
single precision, so you would need to do some more complicated math.
Ah, more complicated math to solve a problem vs. simpler math to avoid a problem in the first place.
Here's a simple "GPS Day Number" example: www.leapsecond.com/tools/gpsdn.c
To add 1024 weeks to a given date use:
gpsdn = date_to_gpsdn(year, month, day);
gpsdn += 1024 * 7;
gpsdn_to_ymd(gpsdn, &year, &month, &day);
That's it. It uses 32 bit integers; no floating point required; works on any OS, or Arduino.
/tvb
Hi
On Mar 28, 2018, at 12:10 AM, Mark Sims holrum@hotmail.com wrote:
Lady Heather's automatic rollover fixer works by looking at the year in any time message that it sees. If it sees 10 consecutive year values less than 2016, it assumes the receiver has rollover issues and then adds 1024 weeks worth of seconds to the Julian date/time calculated from the receiver time/date message until the resulting year is past 2016.
One problem with this is when a receiver is first powered up... most of them send dates in the 1980s to 1990s until they start tracking satellites. Once Heather detects a rollover condition, the code does not currently undo it if the receiver starts sending good dates.
Heather keeps all times as a double precision Julian date. Using Heather's code can be a problem on Arduinos since their "double" precision numbers are actually 32 bit single precision, so you would need to do some more complicated math.
Heather's rollover compensation value is actually in double precision seconds. You can manually specify a rollover correction to sub-second resolution and tweak the displayed time/date to anything you want... comes in handy for testing calendar/eclipse/sunrise/sunset/etc code.
Speaking of rollovers, the GPS system has a 1024 week rollover next year (April 6th-7th). A lot of older receivers had code that could handle the first system rollover in 1999, but might have issues this time.
There are a surprising number of GPS modules that really don’t handle the rollover very well. That includes a significant number of designs that came out after 1999.
Bob
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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
On Wed, Mar 28, 2018, 7:13 AM Tom Van Baak tvb@leapsecond.com wrote:
Hi Mark,
Heather keeps all times as a double precision Julian date. Using
Heather's code can
be a problem on Arduinos since their "double" precision numbers are
actually 32 bit
single precision, so you would need to do some more complicated math.
Ah, more complicated math to solve a problem vs. simpler math to avoid a
problem in the first place.
Here's a simple "GPS Day Number" example: www.leapsecond.com/tools/gpsdn.c
To add 1024 weeks to a given date use:
gpsdn = date_to_gpsdn(year, month, day);
gpsdn += 1024 * 7;
gpsdn_to_ymd(gpsdn, &year, &month, &day);
That's it. It uses 32 bit integers; no floating point required; works on
any OS, or Arduino.
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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