Hi On Aug 11, 2013, at 6:07 PM, Magnus Danielson <[email protected]> wrote:
> On 08/11/2013 11:32 PM, Hal Murray wrote: >> [email protected] said: >>> The issue with the fudge option is that you need to engage it at exactly the >>> right point. Put another way, there's a period between it failing and your >>> entering a fudge that the NTP server is down. >> Yup. But if you are running along and suddenly your GPS breaks, you might >> be >> able to fix it by editing a config file and not needing to install any new >> software or wait for the bug to get fixed. >> >>> With a couple lines of auto correct code in there, it would (essentially) >>> never fail. If you are running a GPS, you enable the auto-correction and >>> forget about it. My guess is that many GPS devices will eventually suffer >>> from the wrap around >> Agreed. >> >> >>> The only way they could avoid it would be some sort of external correction >>> (like continuous firmware updates) or a "no reverse" on the year. Both >>> approaches have their drawbacks….. >> There is another option that may be good-enough for some/many of us. That >> is >> a way to tell the GPS unit the date. >> >> If a GPS device knows the rough date, it can get the right answer. >> >> Most GPS units have a battery and 32KHz clock to keep track of the time so >> they can get started (much) quicker on power up: warm start vs cold start. >> This isn't quite "no reverse", but it's pretty close. >> >> 1024 weeks is 20 years, so the batteries are probably old by the time this >> gets interesting. But even an old tired battery might keep a clock ticking >> for a few minutes/hours. That might cover rearranging cables or a >> not-too-long power outage. >> >> But after the unit has been powered off too long (relative to the battery) >> or >> after you replace the battery, you need some way to set the date. >> >> My Z3801A has been happy since I told it the date. I don't know if it has >> been powered off since then. I should probably try the experiment. >> >> >> > The problem is not that it is hard to encode a solution such that with > some user-setting you can get the right date. It is what we hope is in > there. The problem is that so many recievers use the wrapped time > quick-fix as it was sufficient for the expected life-time of the > product. Most of the things it do does not really depend on it, other > than cranking out a date which looks OKish. If we care, we can > compensate accurately for it, if we have an rough idea of the date... > that is, code around the internal limit and achieve what should have > been in there from the start. Not ideal, but will work. > All we really would need to know is the date to within a decade. Past that it's pretty easy. It's more like an error correcting code than anything else. A fully automated solution would be vulnerable to a multi decade glitch, so I'd allow both a fully automated solution and a "tell me the decade" solution. If I want to supply the config file with a date once a year, I'm good for quite a while….. In some ways this is a bit like the leap second debate. With enough warning (10 years) it's not a big issue. Bob > Cheers, > Magnus > _______________________________________________ > 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. _______________________________________________ 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.
