Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Chris Albertson]

On Thu, Aug 10, 2017 at 10:24 AM, Brad Dye  wrote:

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

An in-line device makes sense if you don't have control of whatever you
have the T-Bolt plugged into.  This would be the case in a cell tower.

But if the T-Bolt is plugged into a computer in your own house, I'd think
it would be far easier to modify the software your computer runs.   LH and
NTP are the only two most of us would run and both are open source and easy
to change.   Four of five lines of code, max.

Building an inline device would be easy, even an Arduino could work but it
would need more software and time to write it than a simple patch to NTP or
LH.

Patches are free, and thousands of people can use them just by downloading
but an in-line device has to be built for each user.

-- 

Chris Albertson
Redondo Beach, California
___
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.

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Jeremy Nichols]

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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Bob kb8tq]

Hi

The whole “offset frequency” simulcast thing is pretty old. It most certainly 
pre-dates
GPS. It’s actually old enough that the first OCXO I ever designed at Motorola 
went into that kind
of system. The “time sync” thing came along a while after that.

There’s always been a lot of infrastructure gear that goes on chugging for a 
*long* time. 
Budgets are pretty skinny for a lot of very important stuff. That doesn’t just 
go for the
gear, it also goes for the payroll to support them. Maybe it should not be so, 
but in most 
of the places I’m aware of, it is.

Bob




> On Aug 11, 2017, at 12:26 PM, 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 
___
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.

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Mark Spencer]

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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

[Tom Van Baak]

> 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] Article at gpsworld.com: NASA describes expected impact of total eclipse on GPS

[Martin Burnicki]

This may be interesting for time nuts:

NASA describes expected impact of total eclipse on GPS
http://gpsworld.com/nasa-describes-expected-impact-of-total-eclipse-on-gps/

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