Hi Best guess is that the “real work” on the firmware took place …errr… a bit over 19.6 years ago. That’s a massively long time ago in terms of development tools and hardware. Simply getting a tool suite back up and going on the “old code” would be a big task in most organizations. Ask me about stuff I did 20 years ago and you’ll get a bit of a blank stare. That assumes you still have me on the payroll. Dig into it from scratch with nobody having direct experience … yikes. Yes, I’ve been involved in those sort of projects, they rarely end well ….
Bob > On Aug 11, 2017, at 12:51 PM, Mark Spencer <m...@alignedsolutions.com> wrote: > > 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 <t...@leapsecond.com> 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 -- time-nuts@febo.com >> To unsubscribe, go to 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. _______________________________________________ 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.
