Agreed. Re-inventing stuff from twenty years ago was uneconomic and possibly impossible when I was in Silicon Valley, twenty years ago.
Jeremy On Fri, Aug 11, 2017 at 9:57 AM, Bob kb8tq <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 -- [email protected] > >> To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > _______________________________________________ > > time-nuts mailing list -- [email protected] > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > > and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
