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.


time-nuts mailing list --
To unsubscribe, go to
and follow the instructions there.

Reply via email to