David Taylor wrote:
On 16/08/2013 08:12, Magnus Danielson wrote:
Using ICD-GPS-200D gives a fair idea of what the older GPS receivers was
designed to meet.

In these documents, the "gears" of GPS is explained such that you should
be able to implement a correctly working receiver (in principle). There
are a handful of technical details outside of this spec you need to
figure out too, but there are good books for that.
[snip]

Yes, all my receivers are very simple, consumer-level ones.  Sometimes I
see as low as 2m "location accuracy" on the GPS 60 CSx, more likely 3m
when walking.

Thanks for the pointers to the documents.  A pity that they haven't been
able to find two or three spare bits to reduce the 1024 week ambiguity
to nearer a half-century or even 100 years.  Oh, well!

That would be even worse:

Exceptional events like the 10-bit week rollover needs to happen often enough that every programmer is forced to write code to handle them correctly, or it should not happen at all!

I.e. a fault-tolerant server setup is only fault-tolerant if you are comfortable doing monthly fire drills where you pull the power cord (or network cable(s)) from either half.

For GPS 19+ years was probably intended to be long enough that every given receiver would only live to see a single epoch, meaning that a simple test against the firmware generation time would suffice, right?

Well, now we've seen a lot of timing receivers that just keep on working, and that 19+ year range turned out to be not quite long enough.

If this has happened every year or so (i.e. a 64-week rollover), then every GS would have had some method to enter the current epoch, and a way to remember it across reboots.

Personally I think the (Trimble?) hack to use the TAI-UTC offset field as an epoch guess table index is pretty nice:

As long as the offset keeps increasing this will suffice to handle at least one or two epoch rollovers.

OTOH, the firmware timestamp method I outlined above will work perfectly as long as (a) somebody is still willing to generate new firmware versions and (b) you still have some machine with compatible hardware/software to allow you to load it onto the GPS.

Combined remote antenna/GPS receivers with an RS422 or similar connection to an NTP server requires that firmware update capability to be included in the NTP box. :-(

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to