Nice post Tom.  I was also wondering about the replacement hardware vs software 
patch issue.  Just speculation on my part but perhaps changing the software 
involves an extensive QA / test process, vs swapping out a piece of hardware ?  
 Again this is just pure speculation on my part.

Mark Spencer

On Aug 11, 2017, at 9:26 AM, Tom Van Baak <> wrote:

>> 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 times)?
>> 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 it.
>> 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.
> /tvb
> _______________________________________________
> time-nuts mailing list --
> To unsubscribe, go to
> and follow the instructions there.
time-nuts mailing list --
To unsubscribe, go to
and follow the instructions there.

Reply via email to