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

[Bob Camp]

Hi

> On May 5, 2015, at 10:32 PM, Tom Van Baak <tvb at LeapSecond.com> wrote:
> 
>> Don't think it's _that_ much code though. There's some open source ACM date
>> algorithms, and it would be easy enough to implement a quick and dirty fix,
>> adding a number of days offset, while the rest of the algorithm is tested.
>> Will the next time this problem reoccurs be another 20 years?
>> 
>> Alan
> 
> Hi Alan,
> 
> Correct, the date conversion is trivial. See www.leapsecond.com/tools/gpsepoch.c or gpsweek.c for example.
> 
> The hard part is understanding when the GPS receiver fails and when to apply the 1024 week correction, or not. This is made difficult or impossible if the receiver does not give you internal information or if you do not already have external information (like an alternative, independent GPS, or UTC date source). If you wanted to cheat you could keep an independent clock inside the Arduino and then add or subtract 1024 weeks until it "looked right". But this is complicated by power failures in either the GPS receiver or the Arduino. Worse yet are cold starts where the receiver doesn't know what the UTC-GPS correction is.
> 
> It gets messy at best. And without testing in a GPS simulator you can't be sure what will happen when epoch changes again on 2019-03-31 or some other random date in the future. With these epoch issues going on I also wouldn't trust the receiver to handle the upcoming leap second correctly either. I mean, 2015-06-30 is an accepted date for a leap second. But if you're 1024 weeks back in time the receiver will try to apply the leap on 1995-11-14, which is not a valid end of month date. What will it do? I don't know. So these are all things that would have to be tested and perhaps delegated to the Arduino to sort out.
> 
> It's just not simple to get 100% reliable UTC from a sick GPS receiver. The receivers that fail right at the epoch (1999-08-15 or 2019-03-31 or 2038-11-14) are simple to work-around. Also receivers that allow user input of year, so that they can cache the GPS epoch number, are also simple to work-around. But this TymServe 2100 doesn't seem to fall into either of those categories.
> 
> I hope this sheds light on why a simple, trustworthy fix is not likely. And with millions of GPS receivers out there that have no problems this week, because they were designed right in the first place,

….. We will know if they are “designed right” in terms of epochs in about 10 or 20 years from now. We’ll know a bit more (but not everything) about them doing leap seconds July 1st …

Bob

> you have to ask yourself if a hack to this old make/model is worth it.
> 
> /tvb
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.