Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
GPS provides only the current UTC offset from GPS time, which could be made
available via a custom vendor message, or derived from the difference
between messages which provide UTC and messages (e.g. $GPZDG) which provide
GPS time.
I think it's more complicated than that.
The GPS satellites provide GPS time, the offset to UTC, and the the time of
the next leap second. (Obviously, the latter only works if one is scheduled
and the folks who run the satellites have had time to update things.)
Some GPS receivers make that info available to the user. Most of the low
cost receivers default to NMEA which provides UTC and doesn't provide any
leap-warning.
I think the GPS time via GPZDG is a proprietary hack, but maybe I didn't look
hard enough. NMEA wants $$$ for the official documents so google probably
won't find any. I didn't notice anything other than the NMEA driver in ntpd
being able to process them.
Most of the proprietary/non-NMEA protocols provide the next-leap info. My
sample may be biased. Mostly, I've been looking for the leap-scheduled bit
which is what ntpd wants. I think they also provide the when if you dig
deeper, but I haven't been looking for that.
Stratum 1 NTP servers need to be provided with a copy of the NIST leap
second file and will propagate the warning to higher (numeric) stratum
clients.
I think ntpd will work without the file. It may be simpler or less buggy
with the file, but things should work without it.
Some GPS units provide a leap-scheduled flag. I think ntpd will believe a
refclock if it says leap-pending.
If you are stratum 1 and your refclock isn't smart enough to tell you about
leap-pending, you can get the info from other servers. I think it's
something like a majority vote, but I'd have to look at the code and/or
documentation to be sure. It's the same logic as used by non-stratum-1
servers. (A long time ago, it used to believe just one server, but that got
changed after a few broken servers caused a lot of trouble.)
You want a stratum-1 server to be watching other servers anyway as a sanity
check.
It will be interesting to see how well things work.
--
These are my opinions. I hate spam.
Hi Hal,
Why is that so hard?
Depends if you want a quick hack (easy) or a solid solution (hard).
If I understand things correctly, the time (UTC) is correct because the GPS
receiver is using the current GPS-UTC offset. But the date is off by 1024
weeks. (or some multiple of that)
You don't know if the UTC time is correct until the receiver locks to GPS and waits up to 12.5 minutes to get UTC-GPS corrections. At that point you have some to high confidence. Before that point it's a guess. That guess depends very much on the implementation of the receiver; what they hardcode, what they cache, soft resets, hard resets, NVRAM clear, etc.
As much as I cringe when I hear that telecoms often use GPS time instead of UTC, I have come to understand the wisdom of that decision.
All you need for "external information" is the date when the fixup software
was compiled. Call that the build-date. Then the recipe is:
t = dateAndTimeFromGPS
while t < build-date
t += 1024 weeks
That won't solve the problem forever but it will give you another 20 years,
and you can restart the timer anytime you want by rebuilding and reinstalling
the fixup software.
Good, you understand my point. You need "external information" and "That won't solve the problem forever" and oh, well, yeah, duh, just "rebuild and reinstall the fixup software" anytime there's trouble in the future.
To me this is replacing a broken GPS receiver algorithm with a broken Arduino hack. You're not solving anything except pushing a problem to the next unsuspecting user or customer. Worse yet, now instead of being part of a group of N people sharing the same TymServe problem, you are a group of 1 with both a TymServe problem and an Arduino problem.
I think the problems with leap-seconds are also non-problems because the
broken firmware will be working with the correct/current GPS-UTC offset. I
don't remember any problems like that 2 years ago.
Re-read the TymServe field service bulletin. It's not about when leap seconds happen. The issue with TymServe is more like when leap seconds don't happen!
/tvb