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 [EMAIL PROTECTED] 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: > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > > 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. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
