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

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

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
<tbolt-20170729T165941.gif><tbolt-20170729T165942.gif><TBoltrollover.gif>

_______________________________________________
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

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

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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

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

Post by 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
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
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Didier Juges]

Tom,

The sticker is a good idea. I will add an electronic equivalent: a user
selectable alarm to inform the user of impending week rollover on GPS week
935, the way the Thunderbolt sets an alarm for impending leap second.
Thanks for the tip :)

I use a routine that uses 1970 as a reference but still works before, it
simply returns a negative number of days for days before 1970. It uses 32
bit variables and works well with my 8 bit microcontroller and as of this
morning it is working fine.

I should have the alarm code done today. I will post an update here and on
my web site when it's available.

Didier



On Jul 29, 2017 10:19 PM, "Tom Van Baak" <***@leapsecond.com> wrote:

Hi Didier,

I concur with your decision about the manual selection of epoch. That
sounds safer and simpler to me also. Pick the default so your LCD monitor
works out-of-the-box for all TBolt's starting today. Add a cute sticker
that says: press menu on 2037-03-15. I'll sign up to be your first customer
when you roll the new firmware.

I suspect you don't have to code that 936 number; all you have to do is add
N*1024 to the TBolt-reported GPS WN and let the user pick N. So that's just
three lines of code, not counting the pair of day number conversion
functions.

Mark uses JD. I use MJD. An Excel date would work. A 32-bit unsigned unix
time_t would also work since it only needs to work from 1980 (or 2017) to
maybe 2080 or 2100 at the most. If you want some fun, there are many
days-between-two-calendar-dates algorithms on the web. In fact, before
PC's, web, and mobile apps, there were lots of cool pocket calculator
algorithms for doing these day calculations.

/tvb

----- Original Message -----
From: Didier Juges
To: Tom Van Baak ; Discussion of precise time and frequency measurement
Sent: Saturday, July 29, 2017 6:20 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines
thecorrect date


Tom,


Since my monitor does not mess with the TBolt data as it passes through (by
design and intentionally), the only issue is to keep the LCD display
correct.
My personal preference has always been that if I cannot come up with a very
robust method, I give the user the tools to deal with it himself.

Therefore, rather than using a routine like Mark is doing in Lady Heather
(which would seem to be fairly robust), I have added a menu selection where
the user can enter an epoch number and the kit will add the proper number
of weeks to the display accordingly.


The Thunderbolt manual indicates that for weeks before 936, they add 1024
weeks, so for the last few years and until tomorrow, they have been adding
1024 weeks and the date is OK. Then on the 31st, the week will be 936 and
they will not add 1024 so they will be behind 1024 weeks for another 19.6
years. When I wrote the previous email, I wrongly assumed they would be off
by two epochs, that does not seem to be the case after re-reading the
manual.


Anyhow, since such operation will only be required every 20 years or so,
that should be good enough, and in the mean time there will not be an issue
if the rollover detection has worked or not, or if it has been corrupted by
bad data. Seems worth it to me :) PC users have a back up time and date
source (the internet), so an error in the date would be quickly identified,
not so with a stand alone monitor. The little WiFi module I use on my
monitor is advertised as having SNTP capability, but being hard coded to
servers in China, I have decided not to take advantage of it.


I admire the decision to increase the bit count from 10 to 13 (what's wrong
with 16?) There is a very significant difference between 10 and 13 bits.
With 10 bits, whomever came up with that idea might not yet be retired when
that shortsightedness becomes apparent. With 13 bits, odds are good that he
will not only have been retired but have also passed away for a while.
That's good thinking!


Didier

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.

Didier,

There are work-arounds but none are perfect. Vendors have different
approaches to determining the 1024 week (~19.6 year) GPS cycle. You can get
the cycle or the year from the user. You can hardcode some base date and
then increment the cycle each time a rollover is encountered and save in
EEPROM. You can run in GPS mode and not worry about UTC or Gregorian dates
at all. You can try to guess the cycle by hacking on the almanac or leap
second info or other unspeakable acts. None of these is as robust as just a
few having more week number bits, which is what the new signal format will
provide.

I'm waiting until the TBolt rollover this weekend to see what actually
happens to the date fields in packet 0x8F-AB. The work-around may be as
simple as adding 1024 weeks. You mentioned it might be 2048 instead. I
guess we'll find out in a couple of days. Additionally, I wonder if running
GPS mode vs. UTC mode will make a difference. And I wonder if leap seconds
will create an issue -- since the week number factors into the leap second
count which is required for UTC; not to mention that a GPS week is not
quite aligned with a UTC week. I wonder if being in holdover or not will
make a difference. Or cold-start vs. warm-start, etc.

So you are wise to hold-off on your updated TBolt LCD monitor f/w until we
see what actually happens. Sample code to add 1024 weeks is at
www.leapsecond.com/tools/tbolt1.c if that's all it takes to patch the date
field in the packet.

We've had people run TBolt's under GPS signal simulators and they report no
loss of lock. However, a Trimble memo says a 2 hour holdover may occur, so
I wonder which is right. I'm not worried either way. Instead I'll be
logging outputs and TSIP from several TBolt's just to catch what happens,
if anything.

/tvb


_______________________________________________
time-nuts mailing list -- time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mark Sims]

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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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-***@febo.com] On Behalf Of Mark Sims
Sent: 30 July 2017 17:18
To: time-***@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-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

Post by 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-----
Sent: 30 July 2017 17:18
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.

_______________________________________________
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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-***@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

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-----
Sent: 30 July 2017 17:18
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.

_______________________________________________
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Attila Kinali]

On Thu, 27 Jul 2017 19:03:35 -0700

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

[Mike Cook]

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

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

_______________________________________________
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

Loading Image...



-----Original Message-----
From: time-nuts [mailto:time-nuts-***@febo.com] On Behalf Of Tom Van Baak
Sent: Saturday, July 29, 2017 18:16
To: Discussion of precise time and frequency measurement <time-***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

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

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

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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 <CR> <LF> ) 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

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

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

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[ed briggs]

The current model Thunderbolt E #60333-50<tel:[phone]>, v1.04 firmware has a last valid date on the 22nd December 2029<x-apple-data-detectors://1>.

It is probably a good idea to specify what firmware you have in these discussions as different versions will have different properties, and some of the used Thunderbolts are quite old.



On Jul 28, 2017, at 9:05 AM, "time-nuts-***@febo.com<mailto:time-nuts-***@febo.com>" <time-nuts-***@febo.com<mailto:time-nuts-***@febo.com>> wrote:

Send time-nuts mailing list submissions to
time-***@febo.com<mailto:time-***@febo.com>

To subscribe or unsubscribe via the World Wide Web, visit
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
or, via email, send a message with subject or body 'help' to
time-nuts-***@febo.com<mailto:time-nuts-***@febo.com>

You can reach the person managing the list at
time-nuts-***@febo.com<mailto:time-nuts-***@febo.com>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of time-nuts digest..."


Today's Topics:

1. Trimble Thunderbolt no longer determines thecorrect date
(Mark Sims)
2. Symmetricom X72 and Lady Heather results (Mark Sims)


----------------------------------------------------------------------

Message: 1
Date: Fri, 28 Jul 2017 02:32:44 +0000
From: Mark Sims <***@hotmail.com<mailto:***@hotmail.com>>
To: "time-***@febo.com<mailto:time-***@febo.com>" <time-***@febo.com<mailto:time-***@febo.com>>
Subject: [time-nuts] Trimble Thunderbolt no longer determines
thecorrect date
Message-ID:
<***@SN1PR11MB1024.namprd11.prod.outlook.com<mailto:***@SN1PR11MB1024.namprd11.prod.outlook.com>>

Content-Type: text/plain; charset="iso-8859-1"

Actually, Lady Heather's rollover compensation code has no limit on the correction. It can compensate for any number of rollovers. In fact you can use it to adjust the receiver time by any number of seconds (including fractional seconds).

The default behavior is to trigger after 10 seconds of consecutive time messages where the time is before year 2016. The 10 second filter is to avoid false triggers from corrupted packets. This means that for the first 10 seconds after starting Heather on a Tbolt, the date will be wrong. When rollover compensation is in effect, the date is shown in yellow and a "ro" flag appears next to it. It would nice if somebody could come up with a patched firmware...

You can get a false rollover detection if you start monitoring a receiver before it has acquired the almanac since most receivers output time based upon the GPS epoch if they don't have an almanac.

----------------

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.

------------------------------

Message: 2
Date: Fri, 28 Jul 2017 01:27:07 +0000
From: Mark Sims <***@hotmail.com<mailto:***@hotmail.com>>
To: "time-***@febo.com<mailto:time-***@febo.com>" <time-***@febo.com<mailto:time-***@febo.com>>
Subject: [time-nuts] Symmetricom X72 and Lady Heather results
Message-ID:
<***@SN1PR11MB1024.namprd11.prod.outlook.com<mailto:***@SN1PR11MB1024.namprd11.prod.outlook.com>>

Content-Type: text/plain; charset="iso-8859-1"

I'm in the process of adding support to Lady Heather for the Symmetricom X72 (and SA22) rubidium oscillators. I have a most of the functionality working. The X72 has a "health" message that dumps a couple dozen values. The values are labeled with some rather cryptic names that give some hint about what they are, but no where in their (miserable) documentation do they elaborate on what the values mean. Does anybody have any info on them.

The X72 is user interface is a very frustrating an infuriating thing to work with. The device has several glaring omissions in what it does... like no way to read back any settings that you have made and no way to save most of them in EEPROM and no command to restore the unit to its factory default state.

Attached is a plot showing most of the non-static health values... it looks like most of them are highly correlated with temperature. Without heavily average-filtering the display, the values look a lot like noise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x72.gif
Type: image/gif
Size: 66809 bytes
Desc: x72.gif
URL: <Loading Image...>

------------------------------

Subject: Digest Footer

_______________________________________________
time-nuts mailing list
time-***@febo.com<mailto:time-***@febo.com>
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

------------------------------

End of time-nuts Digest, Vol 156, Issue 34
******************************************
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Magnus Danielson]

Attila,

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

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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

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, 27 Jul 2017 17:49:14 -0500

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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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: [phone]
Skype: braddye
http://www.braddye.com


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

Post by 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: [phone]
Skype: braddye
http://www.braddye.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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

Post by 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
http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html
It does rather more than you need, there may be cheaper alternatives.

Post by 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: [phone]
Skype: braddye
http://www.braddye.com
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

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

Post by 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
http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html
It does rather more than you need, there may be cheaper alternatives.

Post by 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: [phone]
Skype: braddye
http://www.braddye.com
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Chris Albertson]

Post by Brad Dye
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.

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

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

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

Post by Brad Dye
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?

Post by Brad Dye
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.

Post by Brad Dye
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,

Post by Brad Dye
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,

Post by Brad Dye
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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 <http://braddye.com/angus_flex_at_6400.html>

A simple explanation of simulcasting is here: http://braddye.com/simulcasting.html <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 <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: [phone]
Skype: braddye
http://www.braddye.com <http://www.braddye.com/>

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

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

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

Post by Brad Dye
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?

Post by Brad Dye
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

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.

Post by Brad Dye
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,

Post by Brad Dye
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,

Post by Brad Dye
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts <https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Tom Van Baak]

Post by Brad Dye
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 ;-)

Post by Brad Dye
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)?

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

Post by Tom Van Baak

Post by Brad Dye
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 ;-)

Post by Brad Dye
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)?

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Bob kb8tq]

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

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

Post by Tom Van Baak

Post by Brad Dye
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 ;-)

Post by Brad Dye
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)?

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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.

Post by Brad Dye
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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

Post by Bob kb8tq
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

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

Post by Mark Spencer
Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
The E911 installation, in the news, is just one of several. Others are

hospitals,

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
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 ;-)

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
In a wide-area simulcast-overlap paging system, the transmitters in

the same

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
coverage area are carefully set to all transmit at exactly the same

time.

Post by Mark Spencer

Post by Tom Van Baak
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)?

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
So to me "synchronizing transmitters” means the control system sends

the

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
traffic out to all the transmitters (over satellite) and tells them

all to hold the

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
messages in a buffer until “the big hand points straight up” or

whatever data

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
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).

Post by Mark Spencer

Post by Tom Van Baak
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.

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
The problems being experienced right now appear to be the interface of

the ThunderBolt

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
with the Zetron Model 620 simulcast controller over TSIP. The Zetron

box is also called

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
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.

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
It is not our goal to blame a particular piece of equipment for this

problem.

Post by Mark Spencer

Post by Tom Van Baak
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.

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
The facts are the 1024 roll over happened and just about nobody in the

paging

Post by Mark Spencer

Post by Tom Van Baak

Post by Brad Dye
business knew it was coming.

Ok, now you know about GPS rollovers! Fun, isn't it? Leap seconds are

fun too.

Post by Mark Spencer

Post by Tom Van Baak
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.

Post by Mark Spencer

Post by Tom Van Baak
/tvb
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

Post by Mark Spencer

Post by Tom Van Baak
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/

mailman/listinfo/time-nuts

Post by Mark Spencer
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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

Post by Tom Van Baak

Post by Brad Dye
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 ;-)

Post by Brad Dye
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Magnus Danielson]

Post by Tom Van Baak

Post by Brad Dye
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 ;-)

Post by Brad Dye
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.

Post by Tom Van Baak

Post by Brad Dye
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.

Post by Tom Van Baak

Post by Brad Dye
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.

Post by Tom Van Baak

Post by Brad Dye
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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.