[time-nuts] Trimble Thunderbolt no longer determines thecorrect date
Tom Van Baak
tvb at LeapSecond.com
Fri Jul 28 02:26:24 EDT 2017
> I cannot imagine a work around since the problem stems from the GPS service
> only identifying the current date within a particular 1024 weeks epoch
> unless the government changes the amount of data that is sent over the GPS
> system. Somebody has to use other method to determine the epoch and add the
> 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 provide.
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.
More information about the time-nuts