gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Norton Allen
Subject: Re: [gpsd-dev] Port to QNX: PPS without SHM?
Date: Tue, 5 Jan 2016 14:03:49 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 1/5/2016 1:34 PM, Gary E. Miller wrote:
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.

I will do that. I think you are missing the biggest motivation for most of what I have done. This is to run on QNX, which does not support the SYSV IPC shared memory API that both gpsd and ntpd use. I would be happy to use NTPSHM, but that would seem to require quite a bit more porting effort in both programs in order to add support for POSIX shared memory.

In addition, the /dev/pps I am using (under QNX) does indeed allow more than one reader. QNX being a micro kernel OS, /dev/pps is implemented outside the kernel.

I don't know how much that affects your advice below, I'll comment:


On Tue, 5 Jan 2016 09:51:50 -0500
Norton Allen <> 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.

As stated, this is not really an option.


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.

ntpd does not seem to be having trouble with the PPS signal. What should I be looking at that would show the inherent limitations of my approach.


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.

What is the value of having gpsd get the pps time if it doesn't actually produce a more precise output? ntpd is capable of putting the coarse time signal together with the precise PPS already. Is every application that uses gpsd then required to handle and combine the two signals?


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.

Yes, that is the one and only gpsd driver I am referring to.

  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 am specifically referring to the documentation on this page:
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver46.html
In the section labeled 'PPS secondary clock unit'. It's not just a second NMEA channel, it's specifically for the PPS data. I am not confused by the ability to have secondary channels. I was simply pointing out that in my implementation, using this specific secondary channel to obtain PPS data from gpsd did not work. This is very likely a fault with my implementation, but if someone were to say "oh yeah, that has never worked," then that would be useful information.


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.

My experience is not consistent with that statement. I have managed to get ntpd to happily accept NMEA data from gpsd ng together with PPS data directly from /dev/pps even when gpsd is not configured to access the PPS channel.


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.

As stated, this is not your Linux kernel. I do not have that 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.

I will definitely take a look at that, thanks.


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


reply via email to

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