[time-nuts] Warped back to 1993

[Magnus Danielson]

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
> 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.

Cheers,
Magnus