I suspect Dave is on the money here. I commonly see this with RS232 data from a multitude of GNSS receivers. GNSS hardware primary purpose is typically to compute position. We are leveraging off the very handy clock stability feature inherent of GNSS. It is not uncommon for firmware developers to develop code which takes the raw data (clocks, pseudo ranges and any augmentation data available), compute the position, then provide data on the output ports (USB / RS232 / Ethernet). This all sounds very good and reasonable. However, as satellite come and go, your receiver will systematically see a different constellation. This will trigger different computations in the firmware, which may execute faster or slower. Since data (typically NMEA) is output at the very end, the time that data is output is susceptible to the algorithms running beforehand. I can repeat this with ease on a variety of Trimble units. My thoughts would be:
*Check the sky visiblity of your GNSS antenna. If you have poor visibility, chances are the computations are struggling, which is delaying the output of the ZDA. This would be my first thought. *Disable any augmentation (eg WAAS) to the device. That often causes different code execution paths. *Disable all NMEA strings other than ZDA *Lift the baud rate to 38400 or 57k. Do not use 115k. I have seen situations where the baud rate was too low for the data being shipped. Nasty. *Have a look at the ZDA string in a terminal program or the debug logs of NTPD. If you are lucky, the timestamps will *not* by integer seconds. They will be the actual timestamp the data was transmitted. If not, speak to your GNSS manufacturer. I have an old Trimble 4000 sitting here with RS232. The ZDA outputs integer seconds in the string. If I enable various options in the firmware, the data is as much as 700 milliseconds old by the time I get hold of it ;-( I think USB is a red herring here. PPS is clearly the best case, but if all you have is RS232 / USB then you need to be more careful. hope this helps. pk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Hart Sent: Friday, 10 August 2012 6:16 AM To: Charles Elliott Cc: Rick Jones; [email protected] Subject: Re: [ntp:questions] is USB inherently evil, or only if something else is on the bus? On Thu, Aug 9, 2012 at 20:29 UTC, Charles Elliott wrote: > The process shown in the graph repeats indefinitely using my BU-353W. > In other words, the offsets always begin at about 300 ms, rise slowly > to about > 360 ms, vary erratically between 260 and 360 ms for about two hours, > settle at 260 ms, and then rise slowly to 360 ms to repeat forever. > > It is not clear to me if the problem is the USB interface or the GPS device. Drift of that magnitude must be due to the GPS not USB-triggered latency. Moreover, the real problem is you're assuming the GPS is designed to provide the NMEA sentence(s) at a consistent delay relative to the top of the UTC second. Very often, they are not -- the timing of the NMEA sentences wanders by 100 msec or even more. To get better-than-WAN-NTP performance out of such a GPS, you need to be using its PPS signal. Essentially all USB-interfaced GPSes do not wire the PPS signal through to DCD or another suitable input handshaking line on their serial-to-USB chip. Thanks to Eric Raymond's bufferbloat-related efforts, there is hope we will see PPS exposed on more USB GPSes in the future, however. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
