[time-nuts] Trimble Thunderbolt no longer determines the correct date
Tom Van Baak
tvb at LeapSecond.com
Thu Aug 10 20:59:49 EDT 2017
Strictly speaking, there's no problem with GPS, or Trimble, or the Thunderbolt GPSDO: each did exactly as designed and documented. Anyone working with timing systems (from astronomy to calendars to watch making to operating systems) knows there are many subtle details. Just wait until 2038 for MOAR (the unix Mother of all Rollovers)!
Each GPS receiver manufacturer deals with dates and times and rollovers differently. Still, it sounds like the 3rd party who wrote software for the E911 or paging system forgot to read the manual on the GPS receiver they chose.
> The Trimble Thunderbolts are used in many Radio Paging Systems to
> synchronize their transmitters in simulcast mode.
> Systems that are using the models affected by the 1024 week epoch
> are currently off the air or functioning poorly.
If you are able, can you explain to us what exactly in the transmitters is the problem? All of our TBolts continue to give valid 1 PPS and 10 MHz outputs. What exactly do you mean by "synchronizing transmitters"?
> Trimble's only distributor, Novotech, did not know about it and had no
> inventory of the new replacement E series Thunderbolt GPS Receivers.
> Trimble says they are shipping new units from their overseas factory in
> about 2 weeks -- that's the best they can offer!
Is there no way for E911 people to manually set the clock on their system?
> I read here on the Time Nuts messages that some are considering: "some in-line
> device that re-writes the serial data as it comes out of the Thunderbolt
Right, that was an idea I mentioned. Easy to do but I don't think anyone bothered, because:
1) Mark had already fixed Heather.exe for his users, some NTP people added code to their TBolt drivers, Didier updated his LCD Monitor board -- these are all solutions that keep the same TBolt and just tweak the interpretation of the received TSIP date. Hence no need to update the TBolt or create an inline date-fixer gizmo.
2) Almost all of us use TBolts for their precise time & frequency outputs, not their TSIP packets, so rollovers don't matter.
> Does anyone plan to do this? Or does anyone have any ideas for a short-term solution.
> Any suggestions would be sincerely appreciated.
Presumably the E911 system runs some kind of software or operating system? Surely there's a way to have the guys who wrote the s/w put a fix in? That should be much faster and cheaper than waiting 2 weeks for new h/w, no?
> Next up is the comment that it took two weeks and $27,000 to fix.
Wow! At that price, I bet quite a few time-nuts will have a R-Pi or Arduino or PIC solution ready by the weekend. Me, I'm busy with family and eclipse and so will have to pass on the offer.
You'll want to continuously read serial, unpack TSIP (the DLE stuff), fix the 0x8F-AB message, repack into TSIP and serial output. You may even get away with a single UART since the Rx/Tx pins are both 9600 baud and full duplex. The 0x8F-AB date fix involves converting UTC ymd to #days, adding 1024, converting #days to UTC ymd, where #days is any linear day counting system that works from 1980 to 2100. Both Mark and I posted samples a while ago. It may take some work to make the inline translator code asynchronous enough to avoid data loss or excessive packet latency, though. And it's impossible to do real-time byte-for-byte translation because the DLE escapes in TSIP can slightly alter the byte count.
> While it wouldn't be difficult to build such a device, manufacturing a decent
> quantity in less than 2 weeks to beat Trimble would be a tall order.
Agreed. You know as there's a customer, a weekend project can easily turn into a 2 week project.
More information about the time-nuts