On Mon, May 7, 2012 at 2:34 PM, Ed W
<address@hidden> wrote:
Hi
Hi, Could Eric or similar give me a confirmation on the current gpsd
nmea time calculation?
I'll try.
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?
Nope, nothing anywhere near so fancy. And since the start of gps
sentences is so jittery there is no point to trying except for a
few special case GPS.
You have said how it *doesn't* work, but not how it *does* work here?
If it has a PPS output, you can put it and the RxD on an oscilloscope and measure the jitter. The problem is GPSD itself is semi-device-agnostic, so it can't tell if you've attached a SkyTraq or one of the jittery devices.
Any chance of clarifying the current method of calculating NMEA time (presumably via ZDA sentence)?
I think it needs the RMC and/or the GGA in order to get an indication if it is locked (or other info required for GPSD to work). The ZDA might be the first if alone, but if RMC is there it is the PPS synced sentence. It won't send the packet to NTP until it gets a full set of sentences, and ZDA alone is not sufficient.
Note also that we seem to have clarification now that at least several of the Venus chipsets has PPS accurate ZDA sentences. ie we have in the wild cheap devices with working PPS right now
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.
Until the CP210x kernel driver is fixed there is no point thinking about
any usage of CP210x for timing.
I think we reached the point we are starting to talk past each other now. I know we have a bunch of messages here, but could I ask you to just double check this so we don't cover old ground?
To recap my device doesn't have a traditional PPS, so I think we agreed some emails further back that the CP210x would gain nothing by implementing TIOCMIWAIT? Additionally I think you confirmed that there are no other driver changes which would benefit me, so I dont think the driver needs "fixing" at this point?
The CP210x would gain if the kernel implemented it - at least if PPS was attached to a serial control pin, but then you would have to wait for the kernel driver to be downstreamed into whatever you are running to have the capability.
Sparkfun's module and SkyTraq's EVK have the PPS pins broken out and they work.
Near as I can see the situation is:
- Reading the PPS will only ever poll every 1ms and so won't give you better than 1ms accuracy, regardless of implementation of TIOCMIWAIT
- Reading the serial data will give you $... and based on the number of characters in the buffer we can infer a more precise arrival time of the $ than the granularity of the USB poll. So the serial port data is potentially more accurate if we take the timestamp of the USB poll and from that work back to figure out the arrival time of some character during that poll?
The characters in the input buffer are polled only as often - not more often but less often if there is a FIFO with a high/low water mark or timeout - as the PPS. With a zero-delay for character USB serial chip you will still get a 1mS minimum jitter.
Taking a timestamp of the USB poll cannot be correlated to the actual arrival time of the character, at least not with an uncertainty less than 1mS.
So for your purpose it may be interesting to investigate GPS devices based on a Venus chipset. Accuracy has the potential to be better than PPS... (and devices are available)
Ed W