Hi > On May 5, 2015, at 10:32 PM, Tom Van Baak <t...@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
