Re: [time-nuts] Symmetricom TymServe 2100-GPS currently fails with GPS offset
Andrew Lindh writes: Use an engineering command to set it to 16: root engineering timing early_utc_leap 16 You can also set the TS2100 to add a leap second at the correct time: root timing leap 1 07/01/2015 00:00:00 Tried that, but it seems that this setting stays only for a ongoing hour. As soon the hour changes, the leap setting will be lost, UTC offset is 17 again and time has one second offset: Before hour change: 27 ? leap leap second insertion at JUL 01 2015 00:00:00.00 After hour change: 28 ? leap leap second none at NOV 15 1995 00:00:00.00 -- 73s! Esa OH4KJU ___ 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] Symmetricom TymServe 2100-GPS currently fails with GPS offset
Esa Heikkinen tn1ajb@... writes: Robert Watzlavick kirjoitti: I'm seeing the same thing with my TS-2100 - it is one second behind WWV based on the front panel display. My ET-6000 appears to be in sync. Ok - then this is verified... So the only way (for me) is to run this with 1PPS from Thunderbolt. Good thing is that Tymserve itself support leap second and when 1PPS is used it can be set manually. I did some quick tests and noticed that correct command to set the leap second event is: tim leap 1 07/01/2015 00:00:00 SPOLER ALERT - if you want to see the leap yourself, stop reading... It did not go 23:59:60, it was stopped at 23:59:59 two seconds. I have a nice set of TS2100 GPS Rubidium boxes as primary servers that provide time and PPS to more current NTP servers. It's too bad the firmware is so old and this bug won't be fixed. I see the same 1 second offset against my other time sources used by NTP on my test machine: Motorola Oncore M12+T, Garmin 18x LVC, Trimble Resolution T. Looking at the TS2100 menu you can see that it is using the GPS offset leap second early and reports 17 rather than the current correct setting of 16. I found you can use the engineering menu to hack temporary changes to the offset. These changes are unsupported, use at your own risk. Good luck! Telnet to your TS2100 and login. You can check the current offset using: root timing gps utcoffset also: root timing utils tfp 1 It will show 17, which is a bug because it's early. Use an engineering command to set it to 16: root engineering timing early_utc_leap 16 You can also set the TS2100 to add a leap second at the correct time: root timing leap 1 07/01/2015 00:00:00 I gave this a quick test by setting the leap to a minute from now and it did change the offset from 16 to 17. I guess it will only add 1 second when the time comes as instructed, but who knows... Maybe it will add 2 because of the manual setting and the GPS message change, or maybe it will just be correct when the GPS message changes. This fix does NOT survive a system restart as it syncs with GPS again. It does survive a GPS reset, but if the leap second message updates it may reset the offset. You can clear the manual offset and use GPS: root engineering timing early_utc_leap 0 Clearing the offset tells the system to use the default GPS offset. You can check the offset again with the above commands. Clearing the offset hack and leap settings after the real leap second and restarting would be a good idea (it's the only way to sure). This early_utc_leap setting hack does not require a restart and the TS2100 changes time (adjusts to the new office) in about a minute. - Andrew Lindh ___ 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] Symmetricom TymServe 2100-GPS currently fails with GPS offset
and...@netplex.net said: I have a nice set of TS2100 GPS Rubidium boxes as primary servers that provide time and PPS to more current NTP servers. It's too bad the firmware is so old and this bug won't be fixed. If you are using ntpd, you can fudge the time by a second so ntpd will compensate for their lies. You will have to remove the fudge at the magic midnight. Some/many of the GPS devices that ntpd supports have a way to tell ntpd that a leap second is pending. You might have to patch the code to ignore that or the kernel will go through the leap second dance at the end of each month. -- 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] Symmetricom TymServe 2100-GPS currently fails with GPS offset
I'm seeing the same thing with my TS-2100 - it is one second behind WWV based on the front panel display. My ET-6000 appears to be in sync. What's interesting though is that I have a little applet on my iPhone (NetTime) that connects to nist.time.gov and it is also a second behind. -Bob On 01/23/2015 03:36 PM, Esa Heikkinen wrote: Hi! It seems that there's serious bug in Symmetricom Tymserve 2100 most recent firmware (V4.1). When leap second pending flag was added to GPS transmission (according to data shown by Lady Heather) the Tymserve's time started to be exactly 1 second late from UTC! Currently it claims that current UTC offset is 17 seconds, while Lady Heather shows 16 seconds. Also if I compare the NTP time with another NTP servers it is really 1 seconds late. Playing with telnet: ? utcoffset GPS -- UTC Offset = 17 (And of course there's no way to set this manually) However in the utcinfo data the dTLs value received from GPS is correct (16) but it seems that Tymserver firmware uses wrong value dTLsf, which is the future value of UTC offset after leap second event: ? utcinfo A0:0.000 A1:0.000 dTLs:16 ToT:61440.000 WNt:1829 WNLsf:1851 DN:3 dTLsf:17 It seems that there's no way to fix this. There's also leap second command available, having no efffect on this. Everyone who owns this device please check what's going on with it... To me this is somehow suprising, assumed this to be professional grade, reliable and trouble free instrument, but obviously it's not. No wonder why these are sold so cheap on Ebay (where I got mine). Maybe only way is to run this with 1PPS from Thunderbolt until the leap second period is over. ___ 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] Symmetricom TymServe 2100-GPS currently fails with GPS offset
Robert Watzlavick kirjoitti: I'm seeing the same thing with my TS-2100 - it is one second behind WWV based on the front panel display. My ET-6000 appears to be in sync. Ok - then this is verified... So the only way (for me) is to run this with 1PPS from Thunderbolt. Good thing is that Tymserve itself support leap second and when 1PPS is used it can be set manually. I did some quick tests and noticed that correct command to set the leap second event is: tim leap 1 07/01/2015 00:00:00 SPOLER ALERT - if you want to see the leap yourself, stop reading... It did not go 23:59:60, it was stopped at 23:59:59 two seconds. -- 73s! Esa OH4KJU ___ 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] Symmetricom TymServe 2100-GPS currently fails with GPS offset
Hi! It seems that there's serious bug in Symmetricom Tymserve 2100 most recent firmware (V4.1). When leap second pending flag was added to GPS transmission (according to data shown by Lady Heather) the Tymserve's time started to be exactly 1 second late from UTC! Currently it claims that current UTC offset is 17 seconds, while Lady Heather shows 16 seconds. Also if I compare the NTP time with another NTP servers it is really 1 seconds late. Playing with telnet: ? utcoffset GPS -- UTC Offset = 17 (And of course there's no way to set this manually) However in the utcinfo data the dTLs value received from GPS is correct (16) but it seems that Tymserver firmware uses wrong value dTLsf, which is the future value of UTC offset after leap second event: ? utcinfo A0:0.000 A1:0.000 dTLs:16 ToT:61440.000 WNt:1829 WNLsf:1851 DN:3 dTLsf:17 It seems that there's no way to fix this. There's also leap second command available, having no efffect on this. Everyone who owns this device please check what's going on with it... To me this is somehow suprising, assumed this to be professional grade, reliable and trouble free instrument, but obviously it's not. No wonder why these are sold so cheap on Ebay (where I got mine). Maybe only way is to run this with 1PPS from Thunderbolt until the leap second period is over. -- 73s! Esa OH4KJU ___ 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.
