[ntp:questions] Jitter on $GPGGA of Sure board
gom at gom.invalid
Wed Mar 21 16:10:09 UTC 2012
However if you use NTP, it will average the values, hence reducing the
jitter by sqrt(number of seconds of polling).
So if you use 8 seconds, jitter of the Sure NMEA clock will be
10/sqrt(8)= 3,5 ms.
This is still waaaay jigher than the jitter of the Sure PPS : 22 ns
Le 21/03/2012 16:54, Gom a écrit :
> The thread priority is already maximum.
> The program has no problem disciplining the clock, as it's able to keep
> the calculated offset to under 30 µs with the precise PPS.
> What I wanted to show is that if you use the basic NMEA you will get
> about 50ms error on the arrival of the first NMEA sentance.
> That is confirmed here : http://www.leapsecond.com/pages/MG1613S/
> Check paragraph "NMEA latency" , you will see the dots are scattered in
> about a 50 ms windows. If you do the math on the distribution this
> represents a 10 ms jitter (standard deviation).
> Le 21/03/2012 15:49, Ron Frazier (NTP) a écrit :
>> Hi Gom,
>> I just posted a discussion on the PSYCHO PC thread about all the
>> different "jitter" type data we can measure and discuss. We'll see what
>> the replies are. Dave Hart said that jitter is an RMS value of the
>> offsets. So, technically, I don't think that's what your talking about.
>> You're talking about a short term variance in when you get your NMEA
>> data. I also thought that was jitter, but I may have been wrong. Take a
>> look at this graph.
>> Ignore the part at the end. This graph shows the offsets from my PC
>> clock to the GPS NMEA only data polling it every 8 seconds. I have a USB
>> based device, which is sending data through an internal serial / USB
>> converter. Note that the peaks are in the -7 / + 10 ms range, for a
>> total range of 17 ms. Going through a serial port might give better
>> performance. There is no serial port on my PC that I'm testing with.
>> Are you running Windows, and are you running NTP? I got that graph using
>> David Taylor's NTP Plotter and graphing the loopstats file that NTP
>> generates with the GPS as the only selectable clock. I'm not sure why
>> you are showing a variance of 50 ms. It may be in the way you're
>> measuring it. If you're using your own program, there are going to be
>> timing delays in that which are different from what NTP does.
>> You could boost your program's process priority to above normal or high.
>> Warning, that can destabilize or lock up your system.
>> Another thought is, what is your baud rate. Mine's at 9600. I had it up
>> to 57600 at one time, but being a USB connection, I'm not sure what that
>> means anyway. Some people said that could destabilize the system.
>> Boosting it didn't seem to improve my short term variance much, but you
>> could try boosting yours, both on the GPS and the PC, and see what
>> Maybe a stupid question, is the GPS moving at all? Any changes in
>> position data could increase variance as the GPS composes the NMEA data
>> You could try using the GPZDA string instead. It reports only time, and
>> shouldn't vary in length. However, it does not have a data validity
>> field. So, NTP might be more likely to fail to know it if the GPS data
>> is bad.
More information about the questions