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

[Hal Murray]

tim...@timeok.it said:
>Hal, I suppose your opinion is correct. A friend has found  the same
> problem with an HPZ3016A GPSDO. The solution was to resetting the internal
> counter inside the Motorola GPS module. To do this , the friend has removed
> the GPS module and communicate using his proper serial port to reset the
> internal counter. I have not some more details about the operation, but if
> request I can ask him. 

With the HP Z3801A, you can do it without removing the GPS module.  The 
command is something like:
  :GPS:INIT:DATE 2016,09,05
I think you have to do it on each power up, or maybe not if the battery on 
the GPS is good.  You may have to disconnect the antenna before doing it.

I expect it will work on other HP GPSDOs, but I haven't tried it.  I have a 
KS-24361 that rolled over a few weeks ago and is now giving bogus time.  I'm 
deliberately not fixing it until I have time to chase an NTP quirk.  (It's 
working rather than rejecting the bogus time, but I can't find the fixup 
code.)


-- 
These are my opinions.  I hate spam.



___
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

[timeok]

   Hal, I suppose your opinion is correct. A friend has found  the same problem 
with an HPZ3016A GPSDO. The solution was to resetting the internal counter 
inside the Motorola GPS module. To do this , the friend has removed the GPS 
module and communicate using his proper serial port to reset the internal 
counter. I have not some more details about the operation, but if request I can 
ask him.
   Luciano


   Da "time-nuts" time-nuts-boun...@febo.com
   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
   Cc hmur...@megapathdsl.net
   Data Tue, 29 Aug 2017 22:36:59 -0700
   Oggetto Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 
date

   w...@arrl.net said:
   > So, at this time is there a viable solution that will make the LCD read the
   > proper date? I am less concerned about the date showing accurately on the
   > desktop Thunderbolt Monitor program. Many thanks!

   It's the GPS rollover problem. There is a 10 bit field for the week number
   in the data from the satellites. After you decode the date/time you have to
   compare what you get with a magic date. The magic date is typically the time
   the software is compiled or a constant in the code that is whenever the
   programmer last updated it. If the GPS date is earlier, add 1024 weeks.
   Repeat if necessary.

   The simple solution is to fix the software driving the display, It's 2 or 3
   lines of code in the right place. If you can't do that, you might be able to
   insert something between the TBolt and the display that will fixup that slot.


   --
   These are my opinions. I hate spam.



   ___
   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

[Hal Murray]

w...@arrl.net said:
> So, at this time is there a viable solution that will make the LCD read the
> proper date?  I am less concerned about the date showing accurately on the
> desktop Thunderbolt Monitor program.  Many thanks!

It's the GPS rollover problem.  There is a 10 bit field for the week number 
in the data from the satellites.  After you decode the date/time you have to 
compare what you get with a magic date. The magic date is typically the time 
the software is compiled or a constant in the code that is whenever the 
programmer last updated it.  If the GPS date is earlier, add 1024 weeks.  
Repeat if necessary.

The simple solution is to fix the software driving the display,  It's 2 or 3 
lines of code in the right place.  If you can't do that, you might be able to 
insert something between the TBolt and the display that will fixup that slot.


-- 
These are my opinions.  I hate spam.



___
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

[Magnus Danielson]

On 08/11/2017 06: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 
documentation that it has a 1024 week / 19.6 year window of valid UTC times)?


Due to ignorance. This is why I have been working for over a decade to 
spread the knowledge. What is "generally known" at time-nuts and PTTI 
does not reach these folks. There is no common knowledge here.



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.


If they also extract the time, and several systems do that, then you are 
out of luck thought.


There is great benefits in synchrocasting, something I have worked with 
for over a decade too, but then delivering alternative to GPS dependence 
on each station.



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.


Might work out, but to be honest, don't hold your breath. Transmitter 
vendors have not the best record of understanding the system aspects and 
how they can contribute. Worth a try thought. Any user of GPS should 
have a workaround for the 1024 weeks wrap-around if they use the time.


Oh, there is a lack of common specification of GPS user equipment 
covering stuff like this, every little market have their "unique" 
requirements. It ends up that they are not comparing notes, learning 
from each other and find common strategies for common problems. Most of 
the uniqueness is in interfacing to their environment.



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.


No, it is treated as company secrets. We are far from the point where it 
is open source and can be inspected by many eyes. You are expected to 
buy a "black box" and trust the vendor to do the right thing. When the 
vendor do not do the right thing, throw the box and buy a new one. Some 
vendors have been black-listed in the process.


I just wished the vendors was acting better.
I had to go to Washington for this mess.

Cheers,
Magnus
___
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

[Bob kb8tq]

Hi

My guess would be that the box the TBolts connect to uses a pretty limited set 
of messages. Like you,
I’d hope that the firmware on the “other end” is happy with the E version.

Bob

> On Aug 11, 2017, at 6:09 PM, Mark Sims  wrote:
> 
> I wonder if they have tested their system with a Thunderbolt-E?   The -E is 
> not necessarily a drop-in replacement for the original.   
> 
> There are a few differences between the original Tbolt messages and the -E 
> messages.   Some messages are different or unsupported and I know of a couple 
> that will crash the device if you use the wrong version of a message for that 
> model.
> ___
> 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

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

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

[Brad Dye]

Tom, et.al.

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

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. Each 
transmitter frequency is set to be slightly different in order to control 
signal overlap/signal cancellation (read: a few Hertz). This has allowed 
simulcast paging to achieve better coverage that any other technology that I am 
aware of — especially in a one-to-many transmission.  Some of the fine points 
of this system engineering are discussed here: 
http://braddye.com/angus_flex_at_6400.html 


A simple explanation of simulcasting is here: 
http://braddye.com/simulcasting.html 

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) 

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.” 
https://www.zetron.com/Portals/0/PDFs/products/Spec%20Sheet%20PDFs/04-Paging/005-1232%20Model%20600-620%20Spec.pdf
 

 This is beyond my pay grade since I am 75 years old and semi-retired.

It is not our goal to blame a particular piece of equipment for this problem. 
The facts are the 1024 roll over happened and just about nobody in the paging 
business knew it was coming. A solution does not need to be found before 
replacement hardware arrives from wherever it is manufactured—in two weeks. I 
am sure the operators would rather solve it with a translator box, or 
something, than buy a new GPSDO for every transmitter in a system — because 
there are many.

When I worked in the paging industry and there was a public safety emergency 
because a system was off the air, no one ate or slept until it was fixed. Well 
that may be a slight exaggeration because I have never missed many meals.

Best Regards,

Brad Dye, K9IQY (licensed 60 years)
Editor, The Wireless Messaging News
P.O. Box 266
Fairfield, IL  62837 USA
Telephone: 618-599-7869
Skype: braddye
http://www.braddye.com 
> On Aug 10, 2017, at 7:59 PM, Tom Van Baak  > wrote:
> 
> Brad,
> 
> Strictly speaking, there's no problem with GPS, or Trimble, or the 
> Thunderbolt GPSDO: each did exactly as designed and documented. Anyone 
> working with timing systems (from astronomy to calendars to watch making to 
> operating systems) knows there are many subtle details. Just wait until 2038 
> for MOAR (the unix Mother of all Rollovers)!
> 
> Each GPS receiver manufacturer deals with dates and times and rollovers 
> differently. Still, it sounds like the 3rd party who wrote software for the 
> E911 or paging system forgot to read the manual on the GPS receiver they 
> chose.
> 
>> The Trimble Thunderbolts are used in many Radio Paging Systems to
>> synchronize their transmitters in simulcast mode.
>> Systems that are using the models affected by the 1024 week epoch
>> are currently off the air or functioning poorly.
> 
> If you are able, can you explain to us what exactly in the transmitters is 
> the problem? All of our TBolts continue to give valid 1 PPS and 10 MHz 
> outputs. What exactly do you mean by "synchronizing transmitters"?
> 
>> Trimble's only distributor, Novotech, did not know about it and had no
>> inventory of the new replacement E series Thunderbolt GPS Receivers.
>> Trimble says they are shipping new units from their overseas factory in
>> about 2 weeks -- that's the best they can offer!
> 
> Is there no way for E911 people to manually set the clock on their system?
> 
>> 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
> 
> Right, that was an idea I mentioned. Easy to do but I don't think anyone 
> bothered, because:
> 
> 1) Mark had already fixed Heather.exe for his users, some NTP people added 
> code to their TBolt drivers, Didier updated his LCD Monitor board -- these 
> are all solutions that keep the same TBolt and just tweak the interpretation 
> of the received TSIP date. Hence no need to update the TBolt or create an 
> inline date-fixer gizmo.
> 
> 2) Almost all of us use TBolts for their precise time & frequency outputs, 
> not their TSIP packets, so rollovers don't matter.
> 
>> Does anyone plan to do this? Or does anyone have any ideas for a short-term 
>> solution.
>> Any suggestions 

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

[Tom Van Baak]

Brad,

Strictly speaking, there's no problem with GPS, or Trimble, or the Thunderbolt 
GPSDO: each did exactly as designed and documented. Anyone working with timing 
systems (from astronomy to calendars to watch making to operating systems) 
knows there are many subtle details. Just wait until 2038 for MOAR (the unix 
Mother of all Rollovers)!

Each GPS receiver manufacturer deals with dates and times and rollovers 
differently. Still, it sounds like the 3rd party who wrote software for the 
E911 or paging system forgot to read the manual on the GPS receiver they chose.

> The Trimble Thunderbolts are used in many Radio Paging Systems to
> synchronize their transmitters in simulcast mode.
> Systems that are using the models affected by the 1024 week epoch
> are currently off the air or functioning poorly.

If you are able, can you explain to us what exactly in the transmitters is the 
problem? All of our TBolts continue to give valid 1 PPS and 10 MHz outputs. 
What exactly do you mean by "synchronizing transmitters"?

> Trimble's only distributor, Novotech, did not know about it and had no
> inventory of the new replacement E series Thunderbolt GPS Receivers.
> Trimble says they are shipping new units from their overseas factory in
> about 2 weeks -- that's the best they can offer!

Is there no way for E911 people to manually set the clock on their system?

> 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

Right, that was an idea I mentioned. Easy to do but I don't think anyone 
bothered, because:

1) Mark had already fixed Heather.exe for his users, some NTP people added code 
to their TBolt drivers, Didier updated his LCD Monitor board -- these are all 
solutions that keep the same TBolt and just tweak the interpretation of the 
received TSIP date. Hence no need to update the TBolt or create an inline 
date-fixer gizmo.

2) Almost all of us use TBolts for their precise time & frequency outputs, not 
their TSIP packets, so rollovers don't matter.

> Does anyone plan to do this? Or does anyone have any ideas for a short-term 
> solution.
> Any suggestions would be sincerely appreciated.

Presumably the E911 system runs some kind of software or operating system? 
Surely there's a way to have the guys who wrote the s/w put a fix in? That 
should be much faster and cheaper than waiting 2 weeks for new h/w, no?

Bob,

> Next up is the comment that it took two weeks and $27,000 to fix.

Wow! At that price, I bet quite a few time-nuts will have a R-Pi or Arduino or 
PIC solution ready by the weekend. Me, I'm busy with family and eclipse and so 
will have to pass on the offer.

You'll want to continuously read serial, unpack TSIP (the DLE stuff), fix the 
0x8F-AB message, repack into TSIP and serial output. You may even get away with 
a single UART since the Rx/Tx pins are both 9600 baud and full duplex. The 
0x8F-AB date fix involves converting UTC ymd to #days, adding 1024, converting 
#days to UTC ymd, where #days is any linear day counting system that works from 
1980 to 2100. Both Mark and I posted samples a while ago. It may take some work 
to make the inline translator code asynchronous enough to avoid data loss or 
excessive packet latency, though. And it's impossible to do real-time 
byte-for-byte translation because the DLE escapes in TSIP can slightly alter 
the byte count.

Adrian,

> While it wouldn't be difficult to build such a device, manufacturing a decent
> quantity in less than 2 weeks to beat Trimble would be a tall order.

Agreed. You know as there's a customer, a weekend project can easily turn into 
a 2 week project.

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

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

[Bob kb8tq]

Hi

Indeed, this could be a new wave of TBolts into the market. My fear is that 
those
handling it are not going to sell off the “rejects”. They’ll just toss them in 
the trash.

Bob

> On Aug 10, 2017, at 8:00 PM, paul swed  wrote:
> 
> Just remember you are taking on E911 responsibility.
> Not that brave.
> But come on all those tbolts going in the trash. Sounds like goodies.
> Regards
> Regards
> Paul
> WB8TSL
> 
> 
> On Thu, Aug 10, 2017 at 7:55 PM, Adrian Godwin  wrote:
> 
>> While it wouldn't be difficult to build such a device, manufacturing a
>> decent quantity in less than 2 weeks to beat Trimble would be a tall order.
>> 
>> There are, however, programmable converters : all the hardware you need and
>> just needs some suitable software. For example :
>> 
>> http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html
>> 
>> It does rather more than you need, there may be cheaper alternatives.
>> 
>> 
>> 
>> On Thu, Aug 10, 2017 at 6:24 PM, Brad Dye  wrote:
>> 
>>> The Trimble Thunderbolts are used in many Radio Paging Systems to
>>> synchronize their transmitters in simulcast mode. Systems that are using
>>> the models affected by the 1024 week epoch are currently off the air or
>>> functioning poorly. This is a very serious issue because many doctors and
>>> nurses as well as first responders rely on their pagers for emergency
>>> notification.
>>> 
>>> Trimble’s only distributor, Novotech, did not know about it and had no
>>> inventory of the new replacement E series Thunderbolt GPS Receivers.
>>> Trimble says they are shipping new units from their overseas factory in
>>> about 2 weeks — thats the best they can offer!
>>> 
>>> 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”
>>> 
>>> Does anyone plan to do this? Or does anyone have any ideas for a
>>> short-term solution.
>>> 
>>> Any suggestions would be sincerely appreciated.
>>> 
>>> Best Regards,
>>> 
>>> Brad Dye
>>> Editor, The Wireless Messaging News
>>> P.O. Box 266
>>> Fairfield, IL  62837 USA
>>> Telephone: 618-599-7869
>>> Skype: braddye
>>> http://www.braddye.com
>>> 
>>> 
>>> ___
>>> 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.

___
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

[paul swed]

Just remember you are taking on E911 responsibility.
Not that brave.
But come on all those tbolts going in the trash. Sounds like goodies.
Regards
Regards
Paul
WB8TSL


On Thu, Aug 10, 2017 at 7:55 PM, Adrian Godwin  wrote:

> While it wouldn't be difficult to build such a device, manufacturing a
> decent quantity in less than 2 weeks to beat Trimble would be a tall order.
>
> There are, however, programmable converters : all the hardware you need and
> just needs some suitable software. For example :
>
> http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html
>
> It does rather more than you need, there may be cheaper alternatives.
>
>
>
> On Thu, Aug 10, 2017 at 6:24 PM, Brad Dye  wrote:
>
> > The Trimble Thunderbolts are used in many Radio Paging Systems to
> > synchronize their transmitters in simulcast mode. Systems that are using
> > the models affected by the 1024 week epoch are currently off the air or
> > functioning poorly. This is a very serious issue because many doctors and
> > nurses as well as first responders rely on their pagers for emergency
> > notification.
> >
> > Trimble’s only distributor, Novotech, did not know about it and had no
> > inventory of the new replacement E series Thunderbolt GPS Receivers.
> > Trimble says they are shipping new units from their overseas factory in
> > about 2 weeks — thats the best they can offer!
> >
> > 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”
> >
> > Does anyone plan to do this? Or does anyone have any ideas for a
> > short-term solution.
> >
> > Any suggestions would be sincerely appreciated.
> >
> > Best Regards,
> >
> > Brad Dye
> > Editor, The Wireless Messaging News
> > P.O. Box 266
> > Fairfield, IL  62837 USA
> > Telephone: 618-599-7869
> > Skype: braddye
> > http://www.braddye.com
> >
> >
> > ___
> > 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.

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

[Adrian Godwin]

While it wouldn't be difficult to build such a device, manufacturing a
decent quantity in less than 2 weeks to beat Trimble would be a tall order.

There are, however, programmable converters : all the hardware you need and
just needs some suitable software. For example :

http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html

It does rather more than you need, there may be cheaper alternatives.



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

> The Trimble Thunderbolts are used in many Radio Paging Systems to
> synchronize their transmitters in simulcast mode. Systems that are using
> the models affected by the 1024 week epoch are currently off the air or
> functioning poorly. This is a very serious issue because many doctors and
> nurses as well as first responders rely on their pagers for emergency
> notification.
>
> Trimble’s only distributor, Novotech, did not know about it and had no
> inventory of the new replacement E series Thunderbolt GPS Receivers.
> Trimble says they are shipping new units from their overseas factory in
> about 2 weeks — thats the best they can offer!
>
> 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”
>
> Does anyone plan to do this? Or does anyone have any ideas for a
> short-term solution.
>
> Any suggestions would be sincerely appreciated.
>
> Best Regards,
>
> Brad Dye
> Editor, The Wireless Messaging News
> P.O. Box 266
> Fairfield, IL  62837 USA
> Telephone: 618-599-7869
> Skype: braddye
> http://www.braddye.com
>
>
> ___
> 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

[Brad Dye]

The Trimble Thunderbolts are used in many Radio Paging Systems to synchronize 
their transmitters in simulcast mode. Systems that are using the models 
affected by the 1024 week epoch are currently off the air or functioning 
poorly. This is a very serious issue because many doctors and nurses as well as 
first responders rely on their pagers for emergency notification.

Trimble’s only distributor, Novotech, did not know about it and had no 
inventory of the new replacement E series Thunderbolt GPS Receivers. Trimble 
says they are shipping new units from their overseas factory in about 2 weeks — 
thats the best they can offer!  

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”

Does anyone plan to do this? Or does anyone have any ideas for a short-term 
solution.

Any suggestions would be sincerely appreciated.

Best Regards,

Brad Dye
Editor, The Wireless Messaging News
P.O. Box 266
Fairfield, IL  62837 USA
Telephone: 618-599-7869
Skype: braddye
http://www.braddye.com


___
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

[Van Horn, David]

Hmm.. Just a while ago, I watched the heather display on ours go to 12:59:59 
and stop...

Still giving me 10 MHz though which is all I really need.
___
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

[Magnus Danielson]

It should only be the failure of producing the wrong "display-date".
The internal time system use different gears for everything, so the 
display-date is a side-product. Adjust with +1024 weeks and you should 
be all set. Leap-second info work on internal gears.


Cheers,
Magnus

On 07/28/2017 02:36 AM, paul swed wrote:

Well quite an unpleasant surprise. So after the 30th do the TBolts stop
working or is it a case of just the wrong date? I know my Hp3801s been
working just fine and its old. Is the TBolt the same issue. Wrong date but
still locks thats all I care about actually.
With to respect of some sort of a hack I can see that being fairly
difficult.
Regards
Paul
WB8TSL

On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali  wrote:


On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges  wrote:


I cannot imagine a work around since the problem stems from the GPS

service

only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the

GPS

system. Somebody has to use other method to determine the epoch and add

the

corresponding offset.


There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
raw GPS messages and decode them yourself.


Attila Kinali

--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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.

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

[Magnus Danielson]

Attila,

On 07/28/2017 02:01 AM, Attila Kinali wrote:

On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges  wrote:


I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.


There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
raw GPS messages and decode them yourself.


Yes, but it is only relevant if you to L2C, on which CNAV is encoded. As 
far as I have seen, there is no support in the L1 C/A NAV, also known as 
LNAV, message for anything but 10 bit GPS-week numbers, which brings 
back the topic.


Now, there is a reason I advocate for L2C and L5 capable receivers, this 
is one of them.


Don't blame receiver vendors for not using L2C CNAV messages when they 
only do L1 C/A receivers.


Cheers,
Magnus
___
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

[Ralph Smith]

I have updated my version of tboltd to do the following:

1) I incorporated your fix for the GPS epoch rollover, with the following
change: Since I was already converting the time internally to the Unix
epoch I did not use the Julian conversion, rather I simply modified the
returned Unix epoch time prior to writing to the NTP shared memory
segment.

2) Sprinkled in some #ifdef statements so the unmodified source will
compile on FreeBSD and on Debian Linux.

3) This does not include the gpsdclientd. I may or may not care enough to
fix that in the future.

Source is available at http://ralphsmith.org/~ralph/tboltd-2017-08-02.tar.gz

There are also some changes in there from the 2010 base originally used,
mostly parsing of some additional packets. Don't do anything with them
though. I also added the ability to write a PID file when running as a
daemon on BSD systems.

I should probably pull all of this into a github project, and use autoconf
or something similar to address cross-platform builds. I'm too lazy to
mess with that at the moment.

Let me know if this works for you.

Ralph
AB4RS

> Thank you, Ralph!
>
> Indeed, I had tarred up the branch on github with your original code,
> not the branch with my changes...how embarrassing!
>
> I've updated the tarball and re-arranged the page to make it easier to
> find the latest.
>
> Also, if you make an official version I'll remove my download and just
> put back the startup scripts that I have added.  Note that I didn't
> touch gpsclientd...
>
> Leigh/WA5ZNU
>
> On 08/01/2017 09:37 AM, Ralph Smith wrote:
>> Thanks for doing this, I was just about to dive into this. I've been
>> neck deep in some other things recently and just became aware of this
>> issue.
>>
>> Could you check the source tarball? I just downloaded it and it appears
>> to be the unmodified version of my code from 2010.
>>
>> Ralph
>> AB4RS
>>
>> Sent from my iPhone
>>
>>> On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU
>>>  wrote:
>>>
>>> Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's
>>> NTP daemon to handle the rollover.  I haven't updated the gpsd.
>>>
>>> https://wa5znu.org/2011/08/tbolt/
>>>
>>> It's not as ambitious as Mark's update; this one doesn't read system
>>> time so it will have to be recompiled again in about 20 years.
>>> I took Mark's Julian and Gregorian date calculations as is ;-)
>>>
>>> This is running now as well as it ever did.  Thanks for the great
>>> community.
>>>
>>> Leigh/WA5ZNU
>>>
>>> ___
>>> 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.
>


___
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

[Leigh L. Klotz, Jr WA5ZNU]

Thank you, Ralph!

Indeed, I had tarred up the branch on github with your original code, 
not the branch with my changes...how embarrassing!


I've updated the tarball and re-arranged the page to make it easier to 
find the latest.


Also, if you make an official version I'll remove my download and just 
put back the startup scripts that I have added.  Note that I didn't 
touch gpsclientd...


Leigh/WA5ZNU

On 08/01/2017 09:37 AM, Ralph Smith wrote:

Thanks for doing this, I was just about to dive into this. I've been neck deep 
in some other things recently and just became aware of this issue.

Could you check the source tarball? I just downloaded it and it appears to be 
the unmodified version of my code from 2010.

Ralph
AB4RS

Sent from my iPhone


On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU  wrote:

Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP 
daemon to handle the rollover.  I haven't updated the gpsd.

https://wa5znu.org/2011/08/tbolt/

It's not as ambitious as Mark's update; this one doesn't read system time so it 
will have to be recompiled again in about 20 years.
I took Mark's Julian and Gregorian date calculations as is ;-)

This is running now as well as it ever did.  Thanks for the great community.

Leigh/WA5ZNU

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

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

[Ralph Smith]

Thanks for doing this, I was just about to dive into this. I've been neck deep 
in some other things recently and just became aware of this issue. 

Could you check the source tarball? I just downloaded it and it appears to be 
the unmodified version of my code from 2010. 

Ralph
AB4RS

Sent from my iPhone

> On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU  
> wrote:
> 
> Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP 
> daemon to handle the rollover.  I haven't updated the gpsd.
> 
> https://wa5znu.org/2011/08/tbolt/
> 
> It's not as ambitious as Mark's update; this one doesn't read system time so 
> it will have to be recompiled again in about 20 years.
> I took Mark's Julian and Gregorian date calculations as is ;-)
> 
> This is running now as well as it ever did.  Thanks for the great community.
> 
> Leigh/WA5ZNU
> 
> ___
> 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

[Leigh L. Klotz, Jr WA5ZNU]

Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's 
NTP daemon to handle the rollover.  I haven't updated the gpsd.


https://wa5znu.org/2011/08/tbolt/

It's not as ambitious as Mark's update; this one doesn't read system 
time so it will have to be recompiled again in about 20 years.

I took Mark's Julian and Gregorian date calculations as is ;-)

This is running now as well as it ever did.  Thanks for the great community.

Leigh/WA5ZNU

___
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

[David C. Partridge]

> Unfortunately the unit that you have does not allow for a fw update.

Oh well it was worth asking.

Dave


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
Sent: 31 July 2017 17:30
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 
date

Hi

Trimble, even on supported products, is pretty firm about a service contract 
being in place for updates.
The only exception seems to be security related patches. There have been a lot 
of examples of this over the years ….AFIK, there isn’t even a “public” firmware 
loader for the TBolt. 

Indeed, you might get lucky. 

Bob


> On Jul 31, 2017, at 5:27 AM, David C. Partridge 
> <david.partri...@perdrix.co.uk> wrote:
> 
> I emailed Trimble on the off chance they might have a firmware upgrade.  They 
> sent me an email which covered some units that rolled over in Feb. 2016 for 
> which they say they have no upgrade.
> 
> I sent them all the information on the label stuck to the outside of my TB 
> (one of the group buy set), to see if there's any hope ...
> 
> I'm not optimistic, but if you don't ask, you don't get.
> 
> Cheers
> Dave
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark 
> Sims
> Sent: 30 July 2017 17:18
> To: time-nuts@febo.com
> Subject: [time-nuts] Trimble Thunderbolt no longer determines the 
> correct date
> 
> That does not appear to be the case.   If it did a reset the DAC should have 
> gone to the InitV eeprom setting  of 2.800V,  but instead mine spiked to 
> 0.308V which is not close to the InitV or the last known DAC values.  
> 
> My log file shows the unit did a filter-reinit  followed two seconds later by 
> phase locking the PPS.
> 
> --
> 
>> Or maybe the TBolt reset on rollover and went back to a previously saved DAC 
>> value.
> ___
> 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.

___
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

[Bob kb8tq]

Hi

Trimble, even on supported products, is pretty firm about a service contract 
being in place for updates.
The only exception seems to be security related patches. There have been a lot 
of examples of this
over the years ….AFIK, there isn’t even a “public” firmware loader for the 
TBolt. 

Indeed, you might get lucky. 

Bob


> On Jul 31, 2017, at 5:27 AM, David C. Partridge 
>  wrote:
> 
> I emailed Trimble on the off chance they might have a firmware upgrade.  They 
> sent me an email which covered some units that rolled over in Feb. 2016 for 
> which they say they have no upgrade.
> 
> I sent them all the information on the label stuck to the outside of my TB 
> (one of the group buy set), to see if there's any hope ...
> 
> I'm not optimistic, but if you don't ask, you don't get.
> 
> Cheers
> Dave
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims
> Sent: 30 July 2017 17:18
> To: time-nuts@febo.com
> Subject: [time-nuts] Trimble Thunderbolt no longer determines the correct date
> 
> That does not appear to be the case.   If it did a reset the DAC should have 
> gone to the InitV eeprom setting  of 2.800V,  but instead mine spiked to 
> 0.308V which is not close to the InitV or the last known DAC values.  
> 
> My log file shows the unit did a filter-reinit  followed two seconds later by 
> phase locking the PPS.
> 
> --
> 
>> Or maybe the TBolt reset on rollover and went back to a previously saved DAC 
>> value.
> ___
> 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.

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

[David C. Partridge]

I emailed Trimble on the off chance they might have a firmware upgrade.  They 
sent me an email which covered some units that rolled over in Feb. 2016 for 
which they say they have no upgrade.

I sent them all the information on the label stuck to the outside of my TB (one 
of the group buy set), to see if there's any hope ...

I'm not optimistic, but if you don't ask, you don't get.

Cheers
Dave

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims
Sent: 30 July 2017 17:18
To: time-nuts@febo.com
Subject: [time-nuts] Trimble Thunderbolt no longer determines the correct date

That does not appear to be the case.   If it did a reset the DAC should have 
gone to the InitV eeprom setting  of 2.800V,  but instead mine spiked to 0.308V 
which is not close to the InitV or the last known DAC values.  

My log file shows the unit did a filter-reinit  followed two seconds later by 
phase locking the PPS.

--

> Or maybe the TBolt reset on rollover and went back to a previously saved DAC 
> value.
___
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

[Mike Cook]

Unfortunately I did not have the log activated. 

Although I did not see a phase shift I think that that may be just luck as 
looking back at the screen print of tboltmon 1 sec after the roll, I see that 
the DAC voltage changed by +0,00533mV from the value 10mins prior to the roll. 
My antenna is not positioned optimally so I am used to seeing occasional 
40-200ns phase offsets due to multi path. My phase shift before rollover 
(-9min) was -118ns and drifting toward 0. The Tbolt and only been powered on 
4Hrs prior to rollover but was in position hold and had a good almanac.  At 
rollover +1s it was 50,52ns and at 41secs after rollover the offset was 
127,66ns so I didn’t think it unusual. Looking at it again, I see that the 
10MHz frequency offset was 0,10ppb prior to the rollover , but 2.01ppb at +1s , 
so it looks like I did get a glitch, but one of lesser magnitude than you 
reported.



> Le 30 juil. 2017 à 16:18, Tom Van Baak <t...@leapsecond.com> a écrit :
> 
> Hi Mike,
> 
>> I was running Tboltmon as the rollover occurred and did not see any phase 
>> shift.
> 
> I'm pleased you saw no phase shift at all. Did you happen to have a TBoltmon 
> log running?
> 
>> Maybe your phase offset was due to your Tbolt being in survey mode and its 
>> apparent position shifted . 
> 
> The particular TBolt I used for the screen capture was powered up too soon 
> before GPS midnight for the survey to complete. So I just entered the 
> coordinates manually before the photo-op.
> 
> But if you look at the two images again, the phase shift may be due to a 
> change in DAC value. My theory at this point is that the DAC voltage 
> calculation includes at least one component based on slope; and slope implies 
> elapsed time interval. A calculation like that would be upset if the 
> underlying time frame changes by -1023 weeks instead of +1 week, or -7168 
> days instead of +1 day, etc. Or maybe the TBolt reset on rollover and went 
> back to a previously saved DAC value. I don't know. But for those of you 
> making your own GPSDO, keep subtle details like this in mind.
> 
> The duration of the recovery depends on the time constant. Notice that Mark 
> uses a 500 s time constant and I used the default (100 s), so my TBolt 
> recovered much quicker than his. I'll have more info as I sift through 
> several TBolt's.
> 
> /tvb
> 
> 
> - Original Message - 
> From: "Mike Cook" <michael.c...@sfr.fr>
> To: "Tom Van Baak" <t...@leapsecond.com>; "Discussion of precise time and 
> frequency measurement" <time-nuts@febo.com>
> Sent: Saturday, July 29, 2017 11:47 PM
> Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 
> date
> 
> 
> Hi,
>  I was running Tboltmon as the rollover occurred and did not see any phase 
> shift. Old type Tbolt firmware 3.0
> Maybe your phase offset was due to your Tbolt being in survey mode and its 
> apparent position shifted . 
> 
> Mike
> 
> 
>> Le 30 juil. 2017 à 02:16, Tom Van Baak <t...@leapsecond.com> a écrit :
>> 
>> Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:
>> 
>> GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to
>> GPS WN 936 TOW 0 (December 13, 1997) instead of
>> GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).
>> 
>> 1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. 
>> Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC 
>> leap seconds). I did not expect the reported 2.75 us 1PPS phase change and 
>> will look into that.
>> 
>> /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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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

Hi Mike,

> I was running Tboltmon as the rollover occurred and did not see any phase 
> shift.

I'm pleased you saw no phase shift at all. Did you happen to have a TBoltmon 
log running?

> Maybe your phase offset was due to your Tbolt being in survey mode and its 
> apparent position shifted . 

The particular TBolt I used for the screen capture was powered up too soon 
before GPS midnight for the survey to complete. So I just entered the 
coordinates manually before the photo-op.

But if you look at the two images again, the phase shift may be due to a change 
in DAC value. My theory at this point is that the DAC voltage calculation 
includes at least one component based on slope; and slope implies elapsed time 
interval. A calculation like that would be upset if the underlying time frame 
changes by -1023 weeks instead of +1 week, or -7168 days instead of +1 day, 
etc. Or maybe the TBolt reset on rollover and went back to a previously saved 
DAC value. I don't know. But for those of you making your own GPSDO, keep 
subtle details like this in mind.

The duration of the recovery depends on the time constant. Notice that Mark 
uses a 500 s time constant and I used the default (100 s), so my TBolt 
recovered much quicker than his. I'll have more info as I sift through several 
TBolt's.

/tvb


- Original Message - 
From: "Mike Cook" <michael.c...@sfr.fr>
To: "Tom Van Baak" <t...@leapsecond.com>; "Discussion of precise time and 
frequency measurement" <time-nuts@febo.com>
Sent: Saturday, July 29, 2017 11:47 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 
date


Hi,
  I was running Tboltmon as the rollover occurred and did not see any phase 
shift. Old type Tbolt firmware 3.0
Maybe your phase offset was due to your Tbolt being in survey mode and its 
apparent position shifted . 

Mike


> Le 30 juil. 2017 à 02:16, Tom Van Baak <t...@leapsecond.com> a écrit :
> 
> Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:
> 
> GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to
> GPS WN 936 TOW 0 (December 13, 1997) instead of
> GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).
> 
> 1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. 
> Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC 
> leap seconds). I did not expect the reported 2.75 us 1PPS phase change and 
> will look into that.
> 
> /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.

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

[Mike Cook]

Hi,
  I was running Tboltmon as the rollover occurred and did not see any phase 
shift. Old type Tbolt firmware 3.0
Maybe your phase offset was due to your Tbolt being in survey mode and its 
apparent position shifted . 

Mike


> Le 30 juil. 2017 à 02:16, Tom Van Baak  a écrit :
> 
> Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:
> 
> GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to
> GPS WN 936 TOW 0 (December 13, 1997) instead of
> GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).
> 
> 1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. 
> Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC 
> leap seconds). I did not expect the reported 2.75 us 1PPS phase change and 
> will look into that.
> 
> /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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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

[CubeCentral]

It happened here too.  It is reporting having the 3.0 firmware.  Right at the 
time Tom said.  Fortunately I am simply using this unit for PPS and nothing 
else.

https://i.imgur.com/sganU3F.png



-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
Sent: Saturday, July 29, 2017 18:16
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 
date

Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:

GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to GPS WN 936 TOW 0 
(December 13, 1997) instead of GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).

1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. 
Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC 
leap seconds). I did not expect the reported 2.75 us 1PPS phase change and will 
look into that.

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

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

[Tom Van Baak]

Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:

GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to
GPS WN 936 TOW 0 (December 13, 1997) instead of
GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).

1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. 
Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC 
leap seconds). I did not expect the reported 2.75 us 1PPS phase change and will 
look into that.

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

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

[David G. McGaw]

It appears there is no command to set the current time in the 
Thunderbolt.  Too bad.  I have some very old Garmin OEMs (GPS35) that 
work fine as long as I set the time and date to be close.  I just had to 
do a RAM reset ( $PGRMI,,,C   ) on one which had gotten 
corrupted and would not report position properly (all zeros).  After 
reset, once it got its initial fix it was reporting a date in 1997, but 
reports correctly now that the time and date were set (also using the 
$PGRMI command).  It even has the current GPS week (1959) correct.


David N1HAC


On 7/28/17 11:36 AM, Dave B via time-nuts wrote:

Interesting.

What about NTPD implementations, when using a TB as the reference time
source?  Does that handle the week count roll over as well?  If that was
added, from what version?

I suspect I may have some updating to do!   I use a TB as a frequency
ref' and local NTP/NTPD server reference.

The local TB here is showing "week 1959" top left of LH's display window
(Rev 5.01)

Cheers.

Dave G0WBX.


On 28/07/17 08:14, time-nuts-requ...@febo.com wrote:

Well quite an unpleasant surprise. So after the 30th do the TBolts stop

Paul,

This topic has been covered a number of times over the years. Some time-nuts have even run 
TBolt's under GPS simulators to verify that the 10 MHz and 1PPS outputs will be fine. So 
apparently the only effect is that the date & time (in binary TSIP messages) are off by 
1024 weeks. This rollover-related effect is by now a "common" issue with many GPS 
receivers.

The current version of Mark's Lady Heather program has code to detect this and 
fix it so you're good to go for the next 19.6 years.

/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

[Mike Cook]

> Le 28 juil. 2017 à 17:36, Dave B via time-nuts  a écrit :
> 
> Interesting.
> 
> What about NTPD implementations, when using a TB as the reference time
> source?  Does that handle the week count roll over as well?  If that was
> added, from what version?

   Which driver are you using? Palisade? I had a look at that code and there is 
no correction that I can see.  So you will need to either find/write a patch, 
remove the refclock altogether or configure NTP to use just the 1PPS signal,  
which won’t be affected, by using the ATOM driver. You will need to define a 
separate preferred source (internet for example) for naming the seconds. 

> 
> I suspect I may have some updating to do!   I use a TB as a frequency
> ref' and local NTP/NTPD server reference.
> 
> The local TB here is showing "week 1959" top left of LH's display window
> (Rev 5.01)
> 
> Cheers.
> 
> Dave G0WBX.
> 
> 
> On 28/07/17 08:14, time-nuts-requ...@febo.com wrote:
>>> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
>> Paul,
>> 
>> This topic has been covered a number of times over the years. Some time-nuts 
>> have even run TBolt's under GPS simulators to verify that the 10 MHz and 
>> 1PPS outputs will be fine. So apparently the only effect is that the date & 
>> time (in binary TSIP messages) are off by 1024 weeks. This rollover-related 
>> effect is by now a "common" issue with many GPS receivers.
>> 
>> The current version of Mark's Lady Heather program has code to detect this 
>> and fix it so you're good to go for the next 19.6 years.
>> 
>> /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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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

[Attila Kinali]

On Thu, 27 Jul 2017 19:03:35 -0700
"Tom Van Baak"  wrote:

> Yes -- paragraph 30.3.3.1.1.1 in www.gps.gov/technical/icwg/IS-GPS-200D.pdf 
> describes a 13-bit extended week number.
> 
> No -- because this is part of the new CNAV format and existing GPS SV do not 
> transmit that information.
> 
> Interesting links and PDF's if you google: "Transmission Week Number" CNAV

Oops.. missed that part that this wasn't the normal NAV data.
But it is already transmitted by the IIR-M satellites. Though
only on L2CM and on L5. And L1C will have a different NAV message again...

Attila Kinali

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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

[Bob Bownes]

Forgive my naivete, but if this is something as simple as the t'bolt adding
a 10 bit number to a base date, could not the base date be changed in the
PROM? (Presuming one can get to it, etc) Though I suspect that might not be
all that simple of course. And I'm not taking mine apart to look. :)


On Fri, Jul 28, 2017 at 11:36 AM, Dave B via time-nuts 
wrote:

> Interesting.
>
> What about NTPD implementations, when using a TB as the reference time
> source?  Does that handle the week count roll over as well?  If that was
> added, from what version?
>
> I suspect I may have some updating to do!   I use a TB as a frequency
> ref' and local NTP/NTPD server reference.
>
> The local TB here is showing "week 1959" top left of LH's display window
> (Rev 5.01)
>
> Cheers.
>
> Dave G0WBX.
>
> 
> On 28/07/17 08:14, time-nuts-requ...@febo.com wrote:
> >> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
> > Paul,
> >
> > This topic has been covered a number of times over the years. Some
> time-nuts have even run TBolt's under GPS simulators to verify that the 10
> MHz and 1PPS outputs will be fine. So apparently the only effect is that
> the date & time (in binary TSIP messages) are off by 1024 weeks. This
> rollover-related effect is by now a "common" issue with many GPS receivers.
> >
> > The current version of Mark's Lady Heather program has code to detect
> this and fix it so you're good to go for the next 19.6 years.
> >
> > /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

[Dave B via time-nuts]

Interesting.

What about NTPD implementations, when using a TB as the reference time
source?  Does that handle the week count roll over as well?  If that was
added, from what version?

I suspect I may have some updating to do!   I use a TB as a frequency
ref' and local NTP/NTPD server reference.

The local TB here is showing "week 1959" top left of LH's display window
(Rev 5.01)

Cheers.

Dave G0WBX.


On 28/07/17 08:14, time-nuts-requ...@febo.com wrote:
>> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
> Paul,
>
> This topic has been covered a number of times over the years. Some time-nuts 
> have even run TBolt's under GPS simulators to verify that the 10 MHz and 1PPS 
> outputs will be fine. So apparently the only effect is that the date & time 
> (in binary TSIP messages) are off by 1024 weeks. This rollover-related effect 
> is by now a "common" issue with many GPS receivers.
>
> The current version of Mark's Lady Heather program has code to detect this 
> and fix it so you're good to go for the next 19.6 years.
>
> /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.

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

[paul swed]

Thanks I thought it would still work as the 3801 does.

On Thu, Jul 27, 2017 at 10:03 PM, Tom Van Baak  wrote:

> > There is: There is a 13bit week number in message type 10.
>
> Attila,
>
> Well, yes and no.
>
> Yes -- paragraph 30.3.3.1.1.1 in www.gps.gov/technical/icwg/IS-
> GPS-200D.pdf describes a 13-bit extended week number.
>
> No -- because this is part of the new CNAV format and existing GPS SV do
> not transmit that information.
>
> Interesting links and PDF's if you google: "Transmission Week Number" CNAV
>
> https://lists.ntpsec.org/pipermail/devel/2017-April/004331.html
> https://lists.nongnu.org/archive/html/gpsd-dev/2016-07/msg2.html
>
> > The new 13-bit week number is only provided by the new "CNAV" data,
> > which in turn is (or will be) available only in newly added GPS signals.
> > Based on the carrier frequencies used, only the newest of the new
> > signals (L1C) will be available to common civilian receivers, even with
> > compatible hardware and firmware.  This signal is unavailable from
> > satellites earlier than Block III, which are currently (July 2016) not
> > expected to begin to launch earlier than September 2016.  Given that it
> > takes years to launch a full constellation of satellites, it's highly
> > unlikely that CNAV data with "operational" status will be available to
> > common civilian receivers in time for the April 2019 10-bit rollover.
>
> /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]

> There is: There is a 13bit week number in message type 10.

Attila,

Well, yes and no.

Yes -- paragraph 30.3.3.1.1.1 in www.gps.gov/technical/icwg/IS-GPS-200D.pdf 
describes a 13-bit extended week number.

No -- because this is part of the new CNAV format and existing GPS SV do not 
transmit that information.

Interesting links and PDF's if you google: "Transmission Week Number" CNAV

https://lists.ntpsec.org/pipermail/devel/2017-April/004331.html
https://lists.nongnu.org/archive/html/gpsd-dev/2016-07/msg2.html

> The new 13-bit week number is only provided by the new "CNAV" data,
> which in turn is (or will be) available only in newly added GPS signals.
> Based on the carrier frequencies used, only the newest of the new
> signals (L1C) will be available to common civilian receivers, even with
> compatible hardware and firmware.  This signal is unavailable from
> satellites earlier than Block III, which are currently (July 2016) not
> expected to begin to launch earlier than September 2016.  Given that it
> takes years to launch a full constellation of satellites, it's highly
> unlikely that CNAV data with "operational" status will be available to
> common civilian receivers in time for the April 2019 10-bit rollover.

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

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

[Bob kb8tq]

Hi


> On Jul 27, 2017, at 8:01 PM, Attila Kinali  wrote:
> 
> On Thu, 27 Jul 2017 17:49:14 -0500
> Didier Juges  wrote:
> 
>> I cannot imagine a work around since the problem stems from the GPS service
>> only identifying the current date within a particular 1024 weeks epoch
>> unless the government changes the amount of data that is sent over the GPS
>> system. Somebody has to use other method to determine the epoch and add the
>> corresponding offset.
> 
> There is: There is a 13bit week number in message type 10. This gives
> a 157 year span instead of the ~19 years of the 10bit week number.
> This has been part of the GPS standard since IS-GPS-200D which was
> released in 2004.

The magic “extra bits” only get here when they launch the next block of GPS
sat’s. That was sure to happen in 2005 … 2007 ….2011 … Last time I saw, it
was out in 2018 / 2019. The “problem” is that the old ones are not dying as fast
as they should.  

One would think that a simple re-shoot of firmware would get everything up to 
date.
That’s not the way they make these beasts. Again good news / bad news. The same
sort of approach makes them more reliable. It’s not the direct reason they are 
up 
there longer though. 

Bob



> As such I am a little bit surprised that the u-blox
> receivers still don't support this message (the LEA-5 family was released
> in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
> raw GPS messages and decode them yourself.
> 
> 
>   Attila Kinali
> 
> -- 
> You know, the very powerful and the very stupid have one thing in common.
> They don't alters their views to fit the facts, they alter the facts to
> fit the views, which can be uncomfortable if you happen to be one of the
> facts that needs altering.  -- The Doctor
> ___
> 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

[Pete Stephenson]

I seem to recall several people (tvb?) doing tests and determining that
the 10 MHz and PPS outputs will continue to function as normal, since
the Thunderbolt will continue to track and lock onto the satellites.

The only difference is it'd think the date and time were N weeks in the
past, where N is whatever offset they used. This can be corrected in
software, as Lady Heather does, or perhaps with some in-line device that
re-writes the serial data as it comes out of the Thunderbolt (I've been
tempted to make such a thing myself, but real-world commitments have
gotten in the way).

Cheers!
-Pete

-- 
Pete Stephenson

On Fri, Jul 28, 2017, at 02:36 AM, paul swed wrote:
> Well quite an unpleasant surprise. So after the 30th do the TBolts stop
> working or is it a case of just the wrong date? I know my Hp3801s been
> working just fine and its old. Is the TBolt the same issue. Wrong date
> but
> still locks thats all I care about actually.
> With to respect of some sort of a hack I can see that being fairly
> difficult.
> Regards
> Paul
> WB8TSL
> 
> On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali  wrote:
> 
> > On Thu, 27 Jul 2017 17:49:14 -0500
> > Didier Juges  wrote:
> >
> > > I cannot imagine a work around since the problem stems from the GPS
> > service
> > > only identifying the current date within a particular 1024 weeks epoch
> > > unless the government changes the amount of data that is sent over the
> > GPS
> > > system. Somebody has to use other method to determine the epoch and add
> > the
> > > corresponding offset.
> >
> > There is: There is a 13bit week number in message type 10. This gives
> > a 157 year span instead of the ~19 years of the 10bit week number.
> > This has been part of the GPS standard since IS-GPS-200D which was
> > released in 2004. As such I am a little bit surprised that the u-blox
> > receivers still don't support this message (the LEA-5 family was released
> > in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
> > raw GPS messages and decode them yourself.
> >
> >
> > Attila Kinali
> >
> > --
> > You know, the very powerful and the very stupid have one thing in common.
> > They don't alters their views to fit the facts, they alter the facts to
> > fit the views, which can be uncomfortable if you happen to be one of the
> > facts that needs altering.  -- The Doctor
> > ___
> > 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.

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

[paul swed]

Well quite an unpleasant surprise. So after the 30th do the TBolts stop
working or is it a case of just the wrong date? I know my Hp3801s been
working just fine and its old. Is the TBolt the same issue. Wrong date but
still locks thats all I care about actually.
With to respect of some sort of a hack I can see that being fairly
difficult.
Regards
Paul
WB8TSL

On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali  wrote:

> On Thu, 27 Jul 2017 17:49:14 -0500
> Didier Juges  wrote:
>
> > I cannot imagine a work around since the problem stems from the GPS
> service
> > only identifying the current date within a particular 1024 weeks epoch
> > unless the government changes the amount of data that is sent over the
> GPS
> > system. Somebody has to use other method to determine the epoch and add
> the
> > corresponding offset.
>
> There is: There is a 13bit week number in message type 10. This gives
> a 157 year span instead of the ~19 years of the 10bit week number.
> This has been part of the GPS standard since IS-GPS-200D which was
> released in 2004. As such I am a little bit surprised that the u-blox
> receivers still don't support this message (the LEA-5 family was released
> in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
> raw GPS messages and decode them yourself.
>
>
> Attila Kinali
>
> --
> You know, the very powerful and the very stupid have one thing in common.
> They don't alters their views to fit the facts, they alter the facts to
> fit the views, which can be uncomfortable if you happen to be one of the
> facts that needs altering.  -- The Doctor
> ___
> 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

[Attila Kinali]

On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges  wrote:

> I cannot imagine a work around since the problem stems from the GPS service
> only identifying the current date within a particular 1024 weeks epoch
> unless the government changes the amount of data that is sent over the GPS
> system. Somebody has to use other method to determine the epoch and add the
> corresponding offset.

There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX  messages to get the
raw GPS messages and decode them yourself.


Attila Kinali

-- 
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor
___
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

[Didier Juges]

Since the Thunderbolt is hard coded to detect a particular week to
determine if it should add 1024 to the week number, I would guess that each
product has a magic date based on the anticipated release date of the
product (week 936 for the Thunderbolt), and it will work for 1024 weeks
from that date.

I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.



On Thu, Jul 27, 2017 at 12:36 PM, Keith Loiselle 
wrote:

> Hi,
>
> It came to our attention at Jackson Labs that the Trimble Thunderbolt will
> fail to start with the correct date after July 30, 2017.   See the clip
> from the Thunderbolt manual below.
>
> Does anyone have any updates from Trimble regarding fixes for this
> problem?  Does does this affect other Trimble products (i.e. Mini-T,
> Resolution T) in the same way?
>
> [image: Inline image 1]
>
> Please note that Jackson Labs products are not affected by the up-coming
> April 2019 GPS week roll over, and can determine the correct date until the
> following dates:
>
>
>
>uBlox-8 based products - 4/24/2033
>
>uBlox-6 based products - 5/12/2030
>
>Legacy uBlox-5 based products - 12/3/2028
>
> Thanks,
> Keith
>
> ___
> 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.