[time-nuts] Trimble Thunderbolt no longer determines thecorrect date
shalimr9 at gmail.com
Sat Jul 29 21:20:58 EDT 2017
Since my monitor does not mess with the TBolt data as it passes through (by
design and intentionally), the only issue is to keep the LCD display
My personal preference has always been that if I cannot come up with a very
robust method, I give the user the tools to deal with it himself.
Therefore, rather than using a routine like Mark is doing in Lady Heather
(which would seem to be fairly robust), I have added a menu selection where
the user can enter an epoch number and the kit will add the proper number
of weeks to the display accordingly.
The Thunderbolt manual indicates that for weeks before 936, they add 1024
weeks, so for the last few years and until tomorrow, they have been adding
1024 weeks and the date is OK. Then on the 31st, the week will be 936 and
they will not add 1024 so they will be behind 1024 weeks for another 19.6
years. When I wrote the previous email, I wrongly assumed they would be off
by two epochs, that does not seem to be the case after re-reading the
Anyhow, since such operation will only be required every 20 years or so,
that should be good enough, and in the mean time there will not be an issue
if the rollover detection has worked or not, or if it has been corrupted by
bad data. Seems worth it to me :) PC users have a back up time and date
source (the internet), so an error in the date would be quickly identified,
not so with a stand alone monitor. The little WiFi module I use on my
monitor is advertised as having SNTP capability, but being hard coded to
servers in China, I have decided not to take advantage of it.
I admire the decision to increase the bit count from 10 to 13 (what's wrong
with 16?) There is a very significant difference between 10 and 13 bits.
With 10 bits, whomever came up with that idea might not yet be retired when
that shortsightedness becomes apparent. With 13 bits, odds are good that he
will not only have been retired but have also passed away for a while.
That's good thinking!
On Fri, Jul 28, 2017 at 1:26 AM, Tom Van Baak <tvb at leapsecond.com> wrote:
> > I cannot imagine a work around since the problem stems from the GPS
> > only identifying the current date within a particular 1024 weeks epoch
> > unless the government changes the amount of data that is sent over the
> > system. Somebody has to use other method to determine the epoch and add
> > corresponding offset.
> There are work-arounds but none are perfect. Vendors have different
> approaches to determining the 1024 week (~19.6 year) GPS cycle. You can get
> the cycle or the year from the user. You can hardcode some base date and
> then increment the cycle each time a rollover is encountered and save in
> EEPROM. You can run in GPS mode and not worry about UTC or Gregorian dates
> at all. You can try to guess the cycle by hacking on the almanac or leap
> second info or other unspeakable acts. None of these is as robust as just a
> few having more week number bits, which is what the new signal format will
> I'm waiting until the TBolt rollover this weekend to see what actually
> happens to the date fields in packet 0x8F-AB. The work-around may be as
> simple as adding 1024 weeks. You mentioned it might be 2048 instead. I
> guess we'll find out in a couple of days. Additionally, I wonder if running
> GPS mode vs. UTC mode will make a difference. And I wonder if leap seconds
> will create an issue -- since the week number factors into the leap second
> count which is required for UTC; not to mention that a GPS week is not
> quite aligned with a UTC week. I wonder if being in holdover or not will
> make a difference. Or cold-start vs. warm-start, etc.
> So you are wise to hold-off on your updated TBolt LCD monitor f/w until we
> see what actually happens. Sample code to add 1024 weeks is at
> www.leapsecond.com/tools/tbolt1.c if that's all it takes to patch the
> date field in the packet.
> We've had people run TBolt's under GPS signal simulators and they report
> no loss of lock. However, a Trimble memo says a 2 hour holdover may occur,
> so I wonder which is right. I'm not worried either way. Instead I'll be
> logging outputs and TSIP from several TBolt's just to catch what happens,
> if anything.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> and follow the instructions there.
More information about the time-nuts