gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] NMEA time calculation question


From: tz
Subject: Re: [gpsd-dev] NMEA time calculation question
Date: Mon, 7 May 2012 13:17:05 -0400



On Mon, May 7, 2012 at 12:58 PM, Ed W <address@hidden> wrote:
Hi


My Skytraq Venus 634 and 638 at 1Hz update (with UTC sync enabled) can work this way with a fixed latency  to the start bit of the first sentence  (I think 2mS - it is perfectly consistent on my scope on the TTL line).  I don't know about other chipsets, but most don't even have a way to do this.

Yes, I have a Venus 6 and I believe it's the same.  Rumour is that the first bit is of similar jitter to the PPS?  Do you observe that on a scope?

Within the resolution of the scope, yes.   Well under a few microseconds.



USB 1.1 has a 1mS jitter minimum since that is the polling interval.  USB2.0 can go down to 125uS.

See my previous email - it appears that only USB2 *high* speed goes to 125uS

Yes, and the device has to request that polling interval

I don't know what the goal is, but you would need a hardware pin and some kernel patches if you want a linux or bsd system to sync to sub mS accuracy.

Well, I obviously didn't get my point across.

1) My jitter is slightly higher than expected.  Q: is this related to the way GPSD estimates the arrival time of the first $, ie can I make a change to the gpsd algorithm which would give me 0.5ms precision on my NMEA time (from venus 6 over usb)
 
The system latencies (over USB) is such that GPSD will see it with this variable latency.  If you are doing better than 1mS over USB you are lucky.  If PPS was going to a dedicated pin (RI, DCD) on a hardware UART on an non-busy system you could get much better precision.  With a kernel timing patch, probalby <1uS.
 
2) *IF* not just the initial bit, but in fact if every bit of the Venus 6 output were of low jitter, then because we collect multiple observations of the serial output via USB, then it should be possible to improve our estimate of the arrival timestamp below the 0.5ms mark.  ie we can observe the number of characters read on each USB timestamp, compare with our predicted number of characters we should be able to get sub ms estimates of the arrival time of a particular character - use that to work back and get the arrival time of the first bit. Note that if feasible, this technique would give better accuracy than PPS over USB !

I've done similar experiments.  There is an OFFSET because of the latency to the last sentence, but the jitter is consistent with USB jitter.  115200 baud is fast enough that it takes a 10 character difference in the messages to add up to 1mS.  You might want to try 230400, though the Venus meters the characters out at less than full speed.

That said, an Arduino Mega with an Ethernet shield (available at radio shack and globally, just under $100 US, cheaper if you shop) is pure embedded so the PPS can go into an input capture and be tagged with 67nS precision (and measure and compensate for crystal accuracy), so you can create a very accurate clock down to a few microsecnds and there should be enough space to implement SNTP, and at 100Mbps, Ethernet will have far less latency and jitter than USB.

Agreed.  I think the goal here is to see how far one can push USB for accuracy?  For the vast majority of uses I think 0.5ms is very decent.  If we could get that into the few hundred microsec range then we almost certainly surpass the average stratum 1.

The only thing which might work there is if you could run the PPS to a circuit that would do an "insert" and/or a "remove" event on a second USB port as those could be on an interrupt so you would not have the USB jitter.

PPS into a GPIO is the way to go for best accuracy, but don't you find it interesting that we might be able to get into the few hundred microsecs using only usb?

Only USB2, if you can get a client side chip to implement a minimum latency configuration.
 
Cheers

Ed W


reply via email to

[Prev in Thread] Current Thread [Next in Thread]