[Top][All Lists]

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

Re: [gpsd-dev] NMEA time calculation question

From: Ed W
Subject: Re: [gpsd-dev] NMEA time calculation question
Date: Mon, 07 May 2012 22:51:58 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1


Any chance of clarifying the current method of calculating NMEA time
(presumably via ZDA sentence)?
ZDA does not include fix info, thus it cannot be used to gate time info.
So it is only used to determine the year.  This is all explained in the

Sure, but that is true whether you read the timestamp at the start or end of the sentence? The choice of where to read the timestamp doesn't seem relevant to the need to mask duff timestamps?

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
But without fix mode it is unuseable data.

I believe that's already implemented in gpsd? The issue seems to be more accurate measuring of the sentence start from what I can see - everything else appears to be there?

If all you need is NMEA time then you are correct.  If you think you
can wring some more stability out of the NMEA time then feel free to
pursue it.  But unless your GPS is dramatically different from others
tested the effort will yield nothing the GR-601W does not already
provide, nor as good as network ntp time.

?? The "other gps's" have been tested to be giving results to a few nanoseconds. You mean I need MORE accuracy than that?!

Perhaps you mean if my Venus GPS behaves like a Sirf then it's no good? I think we beat that to death already - it's not a sirf, it's a venus? Others have already confirmed that the behaviour is different

I think it's interesting to the gpsd project that there might be a widely available class of GPS that can give PPS resolution data without needing the PPS connected? At the end of the day I see no reason it's less accurate to read $ZDA every 1ms than it is to check the status of the CTS/DTR pin or whatever?

Additionally if you consider that PPS simply tells you that the pulse appeared sometime between the last poll of the USB and now, our time accuracy is 1ms. However, if the GPS reads at a certain baud rate which means we should have 0-4 characters in our buffer every 1ms, then the knowledge that we read say "$Z" rather than "$ZD" tells us something about the time the $ was emitted. As such it would appear that the accuracy of "pulse" can now be measured to the accuracy of a single character being emitted, usually this is more accurate than 1ms?

So, before proceeding, can you link to a local S1 and give us data that
shows your NMEA time is stable to better than 10 milliSec through a day?

I'm on it.

However, that's measuring gpsd's algorithm, we appear to have already proved that the GPS itself issues sentences with PPS level precision. Any inaccuracy is due to gpsd

gpsd needs TIOCMWAIT.

I think we need to tighten the terminology. *PPS* needs TIOCMIWAIT (by the way, you keep dropping the I?). Gpsd does not appear to need TIOCMIWAIT. Agreed?

So you will not get any PPS with gpsd.  We can
imagine improvements to gpsd that would not require TIOCMWAIT, feel free
to experiment and send patches when it works for you.

Sure - however, are you genuinely not interested to see if we can't get these improvements on a whole class of gps devices, not only this new one? Seems cool to me!

- 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.
Unlikely since USB data is sent as packets, not characters.

I'm not seeing why you disagree?

Every 1ms we get:

a) Knowledge of whether a PPS pulse was set on the DCD line
b) Knowledge of whether we read a $... which also indicates a PPS pulse

Both seem to be of similar accuracy. The big potential difference is that with a) we only know that this pulse occured somewhere in the last 1ms. However, with b) if the baud rate is high enough then we can infer where about within the 1ms gap the PPS occured, eg observe:


The $ is the point the PPS occurred. In the above case we learn a little about how far through the 1ms gap the PPS occurred.

Remember this is with respect to Venus chipsets where the ZDA sentence *is* the same accuracy as the PPS pulse

Since the thumbgps project already has a working $30 solution for 0.5
milliSec jitter it gets them nothing they don't already have.  If it
gets you something, then feel free to hack and send patches.

Sure - I get that. However, it seems interesting in it's own right to increase the accuracy on a bunch of chipsets if it's there for the taking. After all the reason people turn to gpsd rather than roll their own is to try and handle the idiosyncracies of a bunch of devices

Also note that the Venus devices are widely available from around $15. If they just happen to have 0.5ms jitter as well then this seems like a win?


Ed W

reply via email to

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