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 09:51:50 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0



On 1/5/2016 3:12 AM, Eric wrote:
Norton Allen <address@hidden>:
I am attempting to use ntpd and gpsd in order obtain accurate system time
and position data from an NMEA GPS device with PPS output under QNX. If
you're unfamiliar with QNX, it is very POSIX and a little more BSD than
Linux.

In the initial build of both gpsd and ntpd, I determined that both were
looking for SYSV IPC shared memory, and QNX only provides POSIX shared
memory, so I figured I would try to use gpsd's JSON interface instead.

I have a driver that supports the PPS API, so I expect gpsd should be able
to talk to it.

I configured a minimal build with:

    scons minimal=yes socket_export=yes nmea0183=yes pps=yes

The serial data is coming in on /dev/ser11, and I have a soft link /dev/gsp1
-> /dev/ser11. The PPS signal is routed to DCD on /dev/ser1, and the pps
driver monitors that and provide the PPS API on /dev/pps1. 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.

Looking into the gpsd souce code, it appears that in order to get PPS
monitoring going, pps_thread_activate() needs to be called, and the only
place that is called is from ntpshm_link_activate() in timehint.c. Not
surprisingly, that is all qualified by #ifdef NTPSHM_ENABLE.

Any thoughts on what would be necessary to get PPS_ENABLE to work without
NTPSHM_ENABLE?
It shouldn't be very difficult if you have reasonable C chops.  I
didn't originally write the PPS thread handling (it's Gary Miller's
baby) but I was pretty careful about isolating it from the SHM stuff -
I had in mind that we might end up re-using it elsewhere, someday.

Take a look after "Entry points begin here." in ppsthread.c.  Study the way
those four functions are used elsewhere in the codebase.  Probably most of
what you need to do is arrange for pps_thread_activate() to be called
in gpsd::open_device() when PPS is enabled but NTPSHM_ENABLE is not.

Thanks Eric, That is essentially what I have done, and I did manage to get to a point where I thought I was seeing a change in gpsd's output for the better, but since that point, I spent quite a lot of time looking at ntpd, and now I'm not sure my gpsd changes really accomplished anything. In particular, although I was originally unable to get ntpd to acknowledge the gpsd json data without gpsd receiving the PPS signal, I have since managed to get that working. ntpd is now looking at gpsd json as 'prefer' and directly at /dev/pps1 for PPS. In that scenario, the gpsd json offset wanders around 420 ms +/- 50 ms.

The question I have is whether I should expect gpsd's output to be significantly more stable with PPS, or is it committed to providing the raw data with PPS as a secondary channel? 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.

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. I can understand why that might be less desirable than having ntpd obtain the PPS data directly from /dev/pps1, 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.

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.



reply via email to

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