> The E911 installation, in the news, is just one of several. Others are 
> hospitals,
> fire stations, etc. using different dispatch systems.

Hey, at least important things like mobile phones, ISP's, Google, Amazon, FedEx 
and Starbucks aren't affected ;-)

> 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.

That's fine. And very clever. But why is this "life safety" system tied to GPS, 
to a particular vendor, to a particular model of receiver (that clearly states 
in the documentation that it has a 1024 week / 19.6 year window of valid UTC 

> 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) 

Exactly. In most of the precise timing world the "big hand" is the "top of the 
second", or the so-called 1 PPS pulse. The idea is that all 1PPS agree with 
each other, whether from a cesium clock, or WWVB receiver, or NTP, or GPS (or 
any other GNSS system).

Since the paging system failed it sounds like it was synchronized to some 
"hand" other than 1PPS. The rare GPS rollover events tend not to disrupt the 
1PPS output -- it is still perfectly aligned with UTC -- which is why almost no 
one else worries about the recent TBolt episode, or any other GPS receiver for 
that matter.

> 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.”

Ah, ok. So do you or anyone have contact within Zetron? The easy fix would be 
for them to upgrade their firmware and send out a patch. Probably cheaper than 
supplying new receivers from Trimble. I don't know; for us, a s/w fix is easy 
compared to a h/w fix or a h/w swap-out. But in the real world, once 
technicians have driven to a remote installation, maybe there's no real 
difference between a s/w fix and a h/w swap.

> It is not our goal to blame a particular piece of equipment for this problem.

Right, no need to blame. I think many of us would just want to pinpoint the 
root cause of the problem, out of engineering curiosity. By root cause I mean 
actual schematics or lines of source code. It's always been my hope, after 
every one of these widespread infrastructure events, that the actual source 
code or design decisions be published eventually so that we can all learn from 

> The facts are the 1024 roll over happened and just about nobody in the paging
> business knew it was coming.

Ok, now you know about GPS rollovers! Fun, isn't it? Leap seconds are fun too.

When the dust settles, you may want to look into the more general topic of life 
safety infrastructure vs. free-from-the-sky time & frequency. These days 
nanosecond precise time is cheaper than water -- but it's also fragile. A lot 
has been written about this. It's both a wake-up call for naive vendors of 
products based on GPS alone and also an opportunity for vendors who know how to 
design and market resilient timing products.


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.

Reply via email to