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-request@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
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 time-nuts@febo.com
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-request@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.
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
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-request@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.
Le 28 juil. 2017 à 17:36, Dave B via time-nuts time-nuts@febo.com 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-request@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