[Thumbgps-devel] Jitter and latency in a linux system might be a problem. Minimal BoM crosspost.

[Patrick Maupin]

On Mon, Mar 12, 2012 at 2:09 PM, tz <thomas at mich.com> wrote:
> The PPS change detect thread in gpsd might have latency problems if
> the kernel is busy and/or it isn't a high priority - a plain userland
> program shows about 1mS jitter - a loop with the ioctl to block until
> a pin-change followed by gettimeofday will vary over about a 1000 uS
> band on my dual-core netbook.

I thought sub-ms wasn't really necessary.  Sub-us would be useful in a
testbench for characterizing devices to make sure they meet ms...

> I'm not sure how much of the jitter might be due to  the USB latency
> to detect an interrupt condition at the far end, but USB 2.0 ought to
> be fairly fast.

That really depends on how the scheduler is set up.  A driver can
request 'x' interrupts per second.  But then there will be latency
inside the USB part as well.

>  However it might debounce or otherwise delay the
> detection of a serial line change to eliminate noise

That latency should be fairly fixed.  But we can measure it with a test setup.

> But to state the problem clearly, you want the clock to have 100nS
> accuracy,

Where was that listed as a requirement?  I think there's some
misunderstanding here.


> but there is no way in userland and/or USB to get better
> than 1mS jitter even if the edges going into a serial device are
> precise.

Which is probably good enough.

> Any SkyTraq GPS (I have the Venus 624 and 628, and their GLONASS/GPS
> modules), the "$" character in the first sentence can be synced to the
> UTC second and comes out at a fixed delay from the PPS edge, just over
> 1mS to stop bit with no visible jitter so technically it would be as
> accurate as the PPS itself, and the latency could be compensated for.

That's useful.  With a testbench we can test this, and with a small
CPLD in conjunction with such a module and a serial to USB converter,
we might even be able to make this work over USB by wiggling CTS or
DSR.  In other words, if we find a module without PPS, but *with*
accurate first-character message timing, we can wiggle a modem control
line when the first character starts to force an immediate USB
interrupt response, rather than waiting on the entire message plus
some extra latency, which is what the USB chip would normally do.

> At 115kBaud there will be over 500mS of serial silence before the $,
> so it can be detected fairly easily, perhaps even in a Linux-PPS
> interrupt timestamp (if $, grab temp timestamp, if temptimestamp is
> over 500mS from last timestamp, update - treat as PPS).  If the
> CTS/DCD line switch ioctl jitter is acceptable, this is about the same
> and requires no modifications.

Right.

> Also using just the NMEA mode in an unmodified GPSD, the latency error
> for the time was very consistent - about 17 mS with the standard
> sentence set,  there will be slightly more jitter since it invokes the
> PPS routine after the final sentence in the NMEA set
> (GPGGA/GSA/GSVx3/GPRMC), the sentences vary in length.  If you just
> counted the characters (they are a continual burst), you could divide
> by the baud rate to get the position of the start bit of the '$', but
> it would likely have the same userland or USB jitter.

It would be nice if you could backtrack like this.  Wouldn't need any
extr hardware.

> Perhaps a possibility would be an external clock that you could
> trigger a capture-time event when the packet arrived and read out
> slower.  The external timer could be synced to UTC and very precise
> (I've played with syncing signals from an Atmel chip to PPS), so the
> internal ntp synced clock might just be approximate.  It doesn't fix
> the kernel jitter but would act like an external precise and accurate
> stopwatch.

I think there are a lot of really good possibilities, but the first
thing to do is a hardware-assisted testbench to take accurate
measurements, so we know the source and size of all the latencies in
the system.  I haven't heard back from esr about what he thinks of
this approach, though, so I am reluctant to start work on anything
until we have some consensus on the idea that we should grab several
devices and USB modules and USB chips and see how well they really
operate.

> Does this have to be an actual router, or could it sit on the network
> right at the gateway?  If you just need to measure "router-to-router",
> it might be easier to use something like an arduino with ethernet
> shield and emit a UDP or ICMP packet EXACTLY at the UTC second
> (assuming no ethernet collisions, but a good switch should be able to
> avoid them).   There are embedded servers inside what appear to be
> large ethernet connectors which are fairly inexpensive.  Perhaps a UTC
> synchronized pingbot - ping it and it will do the echo exactly at the
> UTC second.  Two pingbots could measure to well under 1mS precision
> and accuracy.  Basically an embedded system that would only know UDP,
> but you could tell it to send a packet to a destination, but it would
> do so within microseconds of the PPS. and tag anything in and/or
> return an echo with the incoming timestamp, e.g. over a command line
> interface:

This is an interesting idea.  I had wondered about ethernet, but the
idea of setting up anything NTPish on a tiny micro seemed daunting.  I
like the idea of such a UDP request/response mechanism.

> Assuming you compile GPSD with PPS on CTS it might be done with the
> following three main parts:

I think we should compile a list of ways to build acceptable units.
But I really believe that to do so, we ought to test all the
components...

> The SkyTraq PPS is accurate to 60nS mainly due to the 16Mhz internal clock rate.

Have you checked that over days?  I'm intrigued by the graph that I
just saw of things going haywire.

> Even if you get a $30 GPS unit you would have to break it open and do
> some soldering under a stereo microscope, assuming you can attach the
> PPS to DCD or CTS or another pin easily.

Absolutely.  But esr's stated end product (which I think should be
possibly part of our range of solutions) is a tiny USB key.  I found
that one for $23, and it's particularly noteworthy because I've seen
pictures of it disassembled on the internet and it appears to have
everything we need except one blue wire.  I've also seen others on
Amazon for $19.  There's no way you could buy all the parts that
cheaply.