Tom, et.al. 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. Best Regards, Brad Dye, K9IQY (licensed 60 years) Editor, The Wireless Messaging News P.O. Box 266 Fairfield, IL 62837 USA Telephone: 618-599-7869 Skype: braddye http://www.braddye.com <http://www.braddye.com/> > On Aug 10, 2017, at 7:59 PM, Tom Van Baak <t...@leapsecond.com > <mailto:t...@leapsecond.com>> wrote: > > Brad, > > 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? > > Bob, > >> 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. > > Adrian, > >> 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. > > /tvb > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@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. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
