[ntp:questions] is USB inherently evil, or only if something else is on the bus?

Kennedy, Paul P.Kennedy at fugro.com.au
Fri Aug 10 00:31:07 UTC 2012

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.
*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.

-----Original Message-----
From: questions-bounces+p.kennedy=fugro.com.au at lists.ntp.org
[mailto:questions-bounces+p.kennedy=fugro.com.au at lists.ntp.org] On
Behalf Of Dave Hart
Sent: Friday, 10 August 2012 6:16 AM
To: Charles Elliott
Cc: Rick Jones; questions at lists.ntp.org
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

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.

Dave Hart
questions mailing list
questions at lists.ntp.org

More information about the questions mailing list