[ntp:questions] Time accuracy in relation to position accuracy

markus.juenemann at gmail.com markus.juenemann at gmail.com
Mon Jan 15 21:28:09 UTC 2007


Replying to myself here :-)

The latest news from Trimble is that these units indeed don't
re-calculate (self-survery) their position
if in stationary mode, even after a power cycle. The rationale behind
this is probably to avoid the
long delay before the GPS is fully operational again. So always force a
self-survey whenever you move
the GPS or you will get bad timing info!!!

Markus

markus.juenemann at gmail.com wrote:
> Thanks to everyone for their very useful replies. Unfortunately I won't
> be able to perform some of the tests, e.g. comparing two GPS receivers
> and their 1 PPS output, because of their remote and distant location.
> Also the comment about the satellites position in relation to the
> receiver explains how the time error might possibly much smaller than I
> thought.
>
> I am still trying to find out how the GPS receiver (a Trimble
> Thunderbolt) behaves in "stationary" mode and under what circumstances
> it reports or auto-corrects errors. The error reporting unfortunately
> gets masked by the ntpd process.
>
> It might be (I need to verify this!), that the Thunderbolt stops
> providing timing information if it is in "non-stationary" mode and can
> see too few satellites (less than three). Some of our sites actually do
> get into situations where they can only see 2 satellites. This might be
> due to bad positioning of the GPS antenna and also must be
> investigated.
>
> Anyway, again thanks heaps for your replies
>
> Markus
>
> Darren Dunham wrote:
> > markus.juenemann at gmail.com wrote:
> > > This all works really well as long the stored position information is
> > > accurate. I was wondering, how inaccurate the time provided by the GPS
> > > receiver will become if the position information is incorrect by, for
> > > example, 100km. Is it correct to assume that this is equivalent to the
> > > time the GPS radio signal takes to travel 100km? If so, the time would
> > > be wrong by approximately(!) 0.3ms.
> >
> > Well, there's an angle factor as well.  If an individual satellite were
> > on the line between the receiver and the assumed location (and therefore
> > very near the horizon), then the error would be equivalent to the offset
> > distance.  But for any other location, the difference should be reduced
> > by a factor of cos*theta.  So the assumed time offset from an
> > approximately overhead satellite will be significantly less.
> >
> > > This issue is actually related to a real problem we have with a GPS
> > > synchronised simulcats radio paging network. For some unknown reason
> > > (this might be non-technical, e.g. operator error) we had a GPS
> > > reference clock in stationary mode with a position error of about
> > > 200km. If this would translate into a time error of at least 0.6ms this
> > > would be sufficiently bad to corrupt messages transmitted
> > > simultaneously by several paging transmitters at 512 bps (512 bps means
> > > that in the most trivial encoding scheme one bit takes about 2.5ms to
> > > transmit - 1000ms divided by 512).
> >
> > > The essential question is whether we have to check about 200 GPS
> > > receivers for incorrect position data or whether this wouldn't really
> > > cause any problem.
> >
> > I think that depends a great deal on the exact unit you have and its
> > behavior.  What does it do in zero-d when multiple satellites are
> > received and they are in conflict (due to position error)?
> >
> > Depending on the site, how likely is it to require a low-horizon
> > satellite?
> >
> > You might try sci.geo.satellite-nav as well.  Someone there might have
> > more information about how your unit would react.
> >
> > --
> > Darren Dunham                                           ddunham at taos.com
> > Senior Technical Consultant         TAOS            http://www.taos.com/
> > Got some Dr Pepper?                           San Francisco, CA bay area
> >          < This line left intentionally blank to confuse you. >




More information about the questions mailing list