Re: [gpsd-dev] NMEA time calculation question

[Gary E. Miller]

Yo Ed!

On Mon, 07 May 2012 19:34:41 +0100
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?

"Use the source, Luke".

My guess is that gpsd takes a timestamp after the entire first sentence
of the new second with a good fix mode on it is decoded.  Since the daily 
jitter has been so bad on all the units I have seen there has been no 
effort to make the gpsd measurement better.  It already is far better
than measured jitter.  PPS is the way to go.

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

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

> >> 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?

No need for a double check.  This has been beat to death already on this
and the thumbgps mailing lists.  The CP210x is badly supported under
Linux (and other OS) and thus not of interest to the thumbgps project.

gpsd only supports CP210x for PVT since TIOCMWAIT is broken in the CP210x
kernel driver.

> 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?

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.

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?

> 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

gpsd needs TIOCMWAIT.  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.

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

And only interesting after you prove your NMEA time is stable.

But feel free to hack away and see if you can make any headway.

> 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)

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.

For my purposes, none of this interests me.  I am happy to be seeing 3
or 4 orders of magnitude better with serial PPS.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

signature.asc
Description: PGP signature