[Top][All Lists]

[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 14:04:05 -0400

On Mon, May 7, 2012 at 1:41 PM, Ed W <address@hidden> wrote:

I think I might not be getting my point across.  Assuming more like 4,800 to 38,400 baud then there should be variation of only one character arrival uncertainty to the timestamp of the start of the ZDA sentence.  However the end of the sentence could have much larger jitter, up to 1ms (eg consider we read only the very last character and the rest of the buffer is empty)

So my jitter is currently 1ms ish, but I believe it should be possible to reduce that to 0.5ms.  Do you agree?

No, because USB "jitter" is random 0-1mS.  It will set the interrupt condition when it sees the character arrive, but it has to poll and it only polls every 1mS.  There is no way to average it out
First question though - did I correctly understand the current gpsd algorithm?

Yes, but it creates an offset, It remembers the time of something early but it doesn't try to compensate for baud rate, and may remember the end of sentence.

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

You cannot measure the error.  It is random and not a normal distribution.
Still think I didn't explain my idea correctly.

My Venus delivers characters at 9,600 baud, ie 1,200Hz, lets assume for the sake of argument that the jitter on the arrival time of each character is very low. The USB bus returns results approximately ever 1ms, but with high jitter, eg might be 1.5ms, then 0.5ms, then 1ms, etc

Assuming that the USB timestamp is accurate, ie it might be 1.5ms since the last read, but we can measure that gap accurately, then we can predict how many characters should be in the buffer.  Algorithm has one unknown, timestamp of first character.  Number of characters in each read at 1024Hz will depend on the timestamp of the first character and the delivery rate (1,200Hz in this case).

In fact if we maintain our estimate between loops it should be possible to setup a PLL which actually has quite high degree of accuracy in predicting the arrival time of each character. 

No, the USB "timing" is equivalent of white noise.   The timestamp of the USB will be 0-1mS from when the real interrupt occurs with no way of calculating or predicting it.

Remember if the assumption holds that we know the timestamp of the low frequency USB observations, then it doesn't in fact matter so much that they are at fairly random intervals, they still allow us to observe the underlying process with much higher accuracy.  In fact more USB jitter is actually beneficial because it will help observe the underlying process...

The kernel adds its own jitter.  Small but nonzero
I'm kind of intrigued that others haven't jumped in on this - on the surface it would appear that the PPS is irrelevant for USB - we can gain far higher accuracy using a PLL and observing the NMEA data (caveat this is true only on certain chipsets, eg many Venus).  Or equivalently you want a 10-20Hz PPS for usb?

You can't do a PLL if you don't have an accurate edge to determine the phase error, and that edge is accurate to worse than 1mS.

Ed W

reply via email to

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