gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Very basic PPS question:


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Very basic PPS question:
Date: Sat, 19 Oct 2013 14:44:17 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Greg Troxel <address@hidden>:
> > When a GPS asserts PPS, is it top of second for the in-stream 
> > data *preceding* or *following*?  
> >
> > I presume following, but I want an expert to confirm before I
> > put it in the HOWTO.
> 
> There can be no standard answer, and the question is really just about
> how in-stream is sent, not about the PPS pulse.

Of course.
 
> PPS is supposed to be the on-time tick of every second.  That can exist
> without any timecode data.  It is possible in the NTP world to get PPS
> From one device and timecode from the net or another device.

We're not dealing with that general case here. We're dealing with what
actual GPSes actually do.

> I would say that typically devices that have PPS have a relatively sane
> relationship of timecode tranmission to the on-time seconds tick, like
> the start bit of the CR after the time code is aligned, or something.
> So for sane devices, this should not be super hard in practice.

I looked at the ntpshm.c code and found the place where it quietly makes
an assumption about this. Here's the comment I added:

    /*
     * This innocuous-looking "+ 1" embodies a significant  assumption:
     * that GPSes report time to the second over the serial stream *after*
     * emitting PPS for the top of second.  Thus, when we see PPS our
     * available report is from the previous cycle and we must increment.
     */
 
And here's the paragraph I have added to the draft HOWTO:

    Note that gpsd assumes that after each fix the GPS will assert
    1PPS first and ship sentences reporting time of fix second. Every
    GPS we know of does things in this order.  If you ever encounter 
    an exception, it should manifest as reported times that look like
    they're from the future and require a negative fudge. If this
    ever happens, please report the device make and model to the GPSD
    maintainers.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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