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 12:15:27 -0400

This varies a lot wth the GPS - Some have a mode where they will sync the first sentence (typically GPRMC) with the UTC edge, though there is sometimes a small latency to the start bit.

Others have no synchronization mechanism, and without a true PPS, they can drift if the lock isn't perfect (many have dead-reckoning, some even keep the pps going).

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.

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

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.

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.

On Mon, May 7, 2012 at 11:44 AM, Ed W <address@hidden> wrote:
Hi, Could Eric or similar give me a confirmation on the current gpsd nmea time calculation?

My understanding is that you take the final GPZDA sentence, then work *back* the timestamp of the initial $ by counting the number of characters divided by baud rate?

So my question would be: if using USB with it's 1ms polling interval, then it's possible to read the first part of the ZDA sentence, then it will be a known 1ms later that we get the last few characters and presumably then timestamp the sentence.  This would appear to give an approx 1ms additional delay over recording the timestamp of the first $ and using that if we later discover that it is the ZDA sentence?

Granted NMEA time is not traditionally considered incredibly accurate, but *if* the calculation is as I describe above, then we could potentially increase measurement accuracy by 0.5-1ms?

Actually, the thought occurs that given USB is around 1024Hz and serial around 600-5000Hz, but the sentences are 10+ characters long, we could use a custom timing mode for USB reads to increase timestamp accuracy.  The logic would be that the usb timestamps have jitter, but the supply rate of the serial port is presumed of lower jitter - by examining the number of characters on each read we could get a far higher estimate of the timestamp that a character is actually emitted (and hence work back to figure out the timestamp of the $).


The reason for asking is that my Venus6 + CP210x has NMEA time that appears to measure almost as accurately as a theoretical PPS over USB.  However, there is slightly higher than expected deviation and my initial results suggest that this has a positive skewed distribution, perhaps fitting the effect described above.

I'm going to collect a couple of hours results and plot them.  My observations over the last few months (without having thought it special) are that the Venus6+CP210x never visibly deviates more than around 1ms on the NMEA time.  I never see any of these few hundred ms drifts that others talk about?

The Venus6 is a -160dB tracking chipset. The ublox 6 is a -162dB chipset.  So not quite as good, but real use is likely to be more important than specs.  I don't own a ublox6 to compare

Regards

Ed W



reply via email to

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