[time-nuts] Warped back to 1993

[Bob Camp]

Hi

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
>> 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 -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.