Re: [gpsd-dev] Port to QNX: PPS without SHM?

[Gary E. Miller]

Yo Norton!

Before I get into the meat of your email, you should take a look at
the gpsd time keeping and RasPi parts of the gpsd doc.  You have missed
some key concepts and jumped a bit too far in some odd directions.

On Tue, 5 Jan 2016 09:51:50 -0500
Norton Allen <address@hidden> wrote:

> >> I am invoking gpsd as:
> >>
> >>          gpsd /dev/gps1 /dev/pps1
> >>
> >> That mostly worked: I was able to see the JSON data and watch the
> >> NMEA interface, but ntpd was unable to synch. I believe this is
> >> because gpsd never attempted to access the PPS device, so never
> >> had data of sufficient quality to pass on to ntpd.

Unlikely.  All gpsd needs to sync is the raw NMEA.

> >> Any thoughts on what would be necessary to get PPS_ENABLE to work
> >> without NTPSHM_ENABLE?  

Not much point, gpsd json is new and problematic, keep the NTPSHM for
now.  You will find it a lot easier, less confusing, and less buggy than
the gpsd json driver.

> In particular, although I was originally
> unable to get ntpd to acknowledge the gpsd json data without gpsd
> receiving the PPS signal,

Yes, gpsd needs to be the ne getting the PPS signal.  Do not pass it directly
to ntpd.

> I have since managed to get that working.
> ntpd is now looking at gpsd json as 'prefer' and directly
> at /dev/pps1 for PPS.

That would be a bad thing.  You have now bypassed all that gpsd does to
clean up the PPS signal for you.

> In that scenario, the gpsd json offset wanders
> around 420 ms +/- 50 ms.

Sounds about right.  The only input gpsd has to work with is the
async, variable length, unsteady serial NMEA stream.
 
> The question I have is whether I should expect gpsd's output to be 
> significantly more stable with PPS,

Yes, and no.  The NMEA time will not change, but without PPS the gpsd
has no access to a high quality signal.

> or is it committed to providing
> the raw data with PPS as a secondary channel?

Yes, mostly.

> I rather assumed it
> would show up as much more stable, so I assume I have as yet failed
> to handle the PPS thread effectively enough.

There are two parts here, the NMEA time and the PPS time, they should
be reported separately to ntpd/chronyd by way of gpsd. The NMEA is
coarse grain time, and the PPS is fine grain time.  Nothing you can do
will get the NMEA time more stable.  And since only one daemon can
open /dev/pps1 at a time you must have gpsd and not ntpd accessing that.

> Perhaps related, the ntpd refclock 46 documentation describes a 
> secondary channel (e.g. 127.127.46.129) that would obtain PPS 
> information from gpsd. I have not been able to get that to work.

There is some confusion, the gpsd json driver and the gpsd ng driver
are one and the same thing.  And all ntpd drivers can have secondary 
channels, all the way up to over 250 channels.  You would use a secondary
channel for your 2nd GPS, and a third channnel for your 3rd GPS.

> I
> can understand why that might be less desirable than having ntpd
> obtain the PPS data directly from /dev/pps1,

Exactly wrong.  gpsd needs the data, and will pass on the ntpd/chronyd/etc
after cleaning it up.

> but I thought the data
> point might be relevant. I am guessing that this is another
> indication that gpsd (specifically my modified version) is not
> properly processing the PPS data, but I can also imagine that this
> might be an interface that isn't widely exercised.

Not widely exercised because it is not possible for two daemons to
read /dev/pps1 at the same time!  You can stop trying now, it is a
kernel limitation.

> This is not an immediate problem for basic timekeeping, since ntpd is 
> able to use the PPS signal directly, but there are plenty of reasons
> why other applications might want to receive time data from gpsd that
> is more precise.

Yes, many reasons to have gpsd read PPS, not ntpd.  Just follow the
RasPi setup instructions in gpsd and you will work fine.

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

pgp2V5V7RxoTO.pgp
Description: OpenPGP digital signature