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
_______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
