[time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix

[Chuck Harris]

Hi Tom,

One of the first words I taught my precocious kid when he was
less than a year old was balderdash.  It seemed appropriate for
him to know that word if I was going to be his father.  Hard
for me to believe that little boy graduates from CMU with his
BS in physics this month....

The currently buggy GPS receiver is outputting UTC time that is
offset by 1024 weeks, and some number of seconds from reality.
The past is irrelevant if we know the present offset.  Add in
that offset, reformat the UTC data frame and send it out when
asked.  An Arduino can do that in a very small number of
milliseconds.  And, the Arduino's time burden can be well known
and applied to the data, if it is significant.

Surely the receiver is still producing correct frames that
identify the future leapsecond, and those frames could be
read, and used to set a little routine that wakes up at the
appropriate second, and adjusts the overall offset?

Seems way simpler to me than all of that code I had to wade
through and cleanse of Y2K bugs.

Since the OP was talking about a multi million dollar research
telescope, which presumably matters to a lot of people, I will
refrain from commenting about the wisdom of ignoring the well
publicized 1024 week roll over bug, and not replacing/reflashing
the GPS receiver years ago.

-Chuck Harris


Tom Van Baak wrote:
> Hi Chuck,
>
> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And
> not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are
> always 604800 seconds long).
>
> So you have to convert the incorrect UTC date and time back to GPS date and time,
> then apply the 1024 GPS week correction, and then convert back to UTC. This
> requires knowledge of all leap seconds during the past 1024 week cycle and this
> information is not present in the GPS signal or in the binary or NMEA messages
> that come out of a GPS receiver. Don't forget to account for all the leap years
> during that period too: 1024 weeks is 19.638 normal years but 19.585 leap years.
> And when you power-on the GPS receiver it may have the wrong leap second count as
> well, wrong for both 1995 and wrong for 2015. You have to wait up to 12.5 minutes
> for that information to come down at 50 baud.
>
> Not saying it isn't possible, but it's not easy. And then you need to test it
> against last week and this week, and the week before and after June 30 of this
> year when the next leap second occurs. I realize the TymServe 2100 issue is
> unrelated to leap seconds. But leap seconds severely complicate any "simple"
> conversion between time scales, especially if you are interested in second or
> sub-second accuracy.
>
> /tvb