[time-nuts] Warped back to 1993
lists at rtty.us
Sun Aug 11 18:31:02 EDT 2013
On Aug 11, 2013, at 6:07 PM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> On 08/11/2013 11:32 PM, Hal Murray wrote:
>> lists at rtty.us 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
>>> 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.
> 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.
More information about the time-nuts