[time-nuts] Trimble Thunderbolt no longer determines the correct date
brad at braddye.com
Thu Aug 10 21:58:50 EDT 2017
The E911 installation, in the news, is just one of several. Others are hospitals, fire stations, etc. using different dispatch systems.
In a wide-area simulcast-overlap paging system, the transmitters in the same coverage area are carefully set to all transmit at exactly the same time. Each transmitter frequency is set to be slightly different in order to control signal overlap/signal cancellation (read: a few Hertz). This has allowed simulcast paging to achieve better coverage that any other technology that I am aware of — especially in a one-to-many transmission. Some of the fine points of this system engineering are discussed here: http://braddye.com/angus_flex_at_6400.html <http://braddye.com/angus_flex_at_6400.html>
A simple explanation of simulcasting is here: http://braddye.com/simulcasting.html <http://braddye.com/simulcasting.html>
So to me "synchronizing transmitters” means the control system sends the traffic out to all the transmitters (over satellite) and tells them all to hold the messages in a buffer until “the big hand points straight up” or whatever data command the system uses. (excuse the vernacular)
The problems being experienced right now appear to be the interface of the ThunderBolt with the Zetron Model 620 simulcast controller over TSIP. The Zetron box is also called a “wireless data encoder.” https://www.zetron.com/Portals/0/PDFs/products/Spec%20Sheet%20PDFs/04-Paging/005-1232%20Model%20600-620%20Spec.pdf <https://www.zetron.com/Portals/0/PDFs/products/Spec%20Sheet%20PDFs/04-Paging/005-1232%20Model%20600-620%20Spec.pdf> This is beyond my pay grade since I am 75 years old and semi-retired.
It is not our goal to blame a particular piece of equipment for this problem. The facts are the 1024 roll over happened and just about nobody in the paging business knew it was coming. A solution does not need to be found before replacement hardware arrives from wherever it is manufactured—in two weeks. I am sure the operators would rather solve it with a translator box, or something, than buy a new GPSDO for every transmitter in a system — because there are many.
When I worked in the paging industry and there was a public safety emergency because a system was off the air, no one ate or slept until it was fixed. Well that may be a slight exaggeration because I have never missed many meals.
Brad Dye, K9IQY (licensed 60 years)
Editor, The Wireless Messaging News
P.O. Box 266
Fairfield, IL 62837 USA
> On Aug 10, 2017, at 7:59 PM, Tom Van Baak <tvb at LeapSecond.com <mailto:tvb at LeapSecond.com>> wrote:
> 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 -- time-nuts at febo.com <mailto:time-nuts at febo.com>
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> and follow the instructions there.
More information about the time-nuts