Poul-Henning Kamp wrote:
In message <[email protected]>, Magnus Danielson writes:
Of course it cannot output a correct UTC solution until it has received
page 18 subframe 4, but it can store the leapsecond offset in
non-volatile RAM since last lock and for most of times that would give
correct UTC from first lock [...]
And once again, this topic reminds me of my favourite Monty Python
episode:
"This is an official announcement from the Royal Navy.
Canibalism is a problem the Royal Navy has mostly under control.
[...]
"
"most of the times" is simply not good enough.
Then you haven't understood the limits. GPS itself only works "most of
the times". You are focusing on a single issue while a GPS based system
is exposed to a lot more threats of both systematic and random nature.
If you can't handle an issue like this, then don't use GPS at all!
It's not all about leapseconds you know.
Besides, one approach to handle lack of page 18, subframe 4 is just not
to output any time at all. That way you will not give the user the wrong
impression. Sure, the user would be without the UTC time during the
wake-up, but you wouldn't "lie". If that is better for you, then use
that approach.
Also, recall that as GPS reception cannot be guaranteed at all times
(for all kinds of reasons, including having GPS receiver restarted) you
better have some form of holdover capability. Now, technically it would
be lying to you a little for a little while, but if this is within
system limits then that is fine as it will make the precense of a singal
more continous. That's how we hide failures to the system. We just wait
a little before we say we lie about the time.
The important thing here is that various forms of failures is know,
detected and a suitable remedy can be designed. This is also possible
for the UTC time from GPS receivers, and the particular little detail of
having the fresh leapsecond count is one but many of those issues.
Cheers,
Magnus
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
