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.0000000 A1:0.0000000 dTLs:16 ToT:61440.0000000 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
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.0000000 A1:0.0000000 dTLs:16 ToT:61440.0000000 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.
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
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
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.000000
After hour change:
28 ? leap
leap second none at NOV 15 1995 00:00:00.000000
--
73s!
Esa
OH4KJU