[time-nuts] Trimble Thunderbolt no longer determines thecorrect date
Tom Van Baak
tvb at LeapSecond.com
Sat Jul 29 23:19:04 EDT 2017
I concur with your decision about the manual selection of epoch. That sounds safer and simpler to me also. Pick the default so your LCD monitor works out-of-the-box for all TBolt's starting today. Add a cute sticker that says: press menu on 2037-03-15. I'll sign up to be your first customer when you roll the new firmware.
I suspect you don't have to code that 936 number; all you have to do is add N*1024 to the TBolt-reported GPS WN and let the user pick N. So that's just three lines of code, not counting the pair of day number conversion functions.
Mark uses JD. I use MJD. An Excel date would work. A 32-bit unsigned unix time_t would also work since it only needs to work from 1980 (or 2017) to maybe 2080 or 2100 at the most. If you want some fun, there are many days-between-two-calendar-dates algorithms on the web. In fact, before PC's, web, and mobile apps, there were lots of cool pocket calculator algorithms for doing these day calculations.
----- Original Message -----
From: Didier Juges
To: Tom Van Baak ; Discussion of precise time and frequency measurement
Sent: Saturday, July 29, 2017 6:20 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines thecorrect date
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 correct.
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 manual.
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 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.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
More information about the time-nuts