Re: [gpsd-dev] What is our current bug state?

[Gary E. Miller]

Yo juergen!

On Tue, 03 Feb 2015 20:11:05 +0100
juergen perlinger <address@hidden> wrote:

> I have another version in
> 
> http://people.ntp.org/perlinger/for_test/refclock_gpsd/refclock_gpsdjson.c

That shook things up nicely.  See attached log and screenshot.

Now GPS_JSON fails loudly:

robin ntp-4.2.8p1-RC2 # fgrep JSON tmp.log
 3 Feb 11:59:43 ntpd[15698]: GPSD_JSON: failed to resolve 'localhost:gpsd', 
rc=-8 (Servname not supported for ai_socktype)
GPSD_JSON: failed to resolve 'localhost:gpsd', rc=-8 (Servname not supported 
for ai_socktype)
 3 Feb 11:59:43 ntpd[15698]: GPSD_JSON(0): no GPSD socket address, giving up

Here is my localhost definition:

robin ntp-4.2.8p1-RC2 # fgrep localhost /etc/hosts
# IPv4 and IPv6 localhost aliases
127.0.0.1       localhost robin.rellim.com
::1             localhost

Removing the IPv6 definition makes no difference.

BTW, I still see IPv6 errors:

 3 Feb 12:49:11 ntpd[29626]: bind(26) AF_INET6 fe80::d8ca:2adf:82a8:8149%2#123 
flags 0x11 failed: Cannot assign requested address
 3 Feb 12:49:11 ntpd[29626]: unable to create socket on enp2s0 (13) for 
fe80::d8ca:2adf:82a8:8149%2#123


Adn, as previously seen, compiling for IPv4 only does not help the
GPSD_JSON thing.

Oddly, gpsd is NOT in my /etc/services:

robin ntp-4.2.8p1-RC2 # fgrep -i gpsd /etc/services
robin ntp-4.2.8p1-RC2 # 

I will file a gpsd bug report right now.

Adding gpsd to /etc/services gets me GPS_JSON!

The ntpd code should default to 2947 if gpsd not found
in /etc/services.  Many distros will likely not have that entry.

Oddly my GPS_JSON time and SHM(1) time do not agree.  I'll have to
ponder that a bit.  I have recently found several regressions in the
gpsd PPS code leading to loss of precision.

> > And note that code never reports the big decision it just made.
> Gary, your right. The original design requested TPV+PPS together and 
> refused to to do anything with TPV alone. I cannot remember who
> thought it useful if the driver could do that, too. Perhaps I find it
> somewhere in my mail archive, but I obviously coded for it anyway. I
> simply forgot about it. My fault.

How can we fix it or mitigate it?
 
> I changed the behavior a bit. If there was a good reliable PPS signal 
> for more than 30s, then it should take 30s again until the driver
> starts to use TPV alone. And it will log a warning when it starts to
> do so. I should do a debug print also, I guess, which I don't right
> now -- I'll put that in immediately, so with the next push the output
> should be there. The code does no 'jitter suppression' if the PPS
> signal comes and goes. This would not do for the final version, but
> it might help right now.

And the PPS will come and go.  Some u-blox turn off PPS when the fix
is not good.  gpsd will stop pushing PPS data if it thinks the fix is
not good.

Another part of the problem is that the fudge for PPS and the fudge
for NMEA will differ by 100's of millSec.

> I'm not sure if the jitter results from using TPV alone, or from
> jumping between PPS-augmented time and TPV receive time.

Thus the failure of the design.

> Could this
> indicate that there is not always a PPS pulse in the second before
> TPV is received? I heard rumors that the PPS pulses of some receivers
> are so short that the pulse is not reliably detected by the serial
> port.

Actually the UART can do this fine, the problem is that some RS-232
level shifters are not fast enough, or the drive level from the GPS is
not hard enough to drive the shifters fast enough.

But whatever the reasons, PPS will come and go.

> This would indeed cause problems. It might be best to remove
> the TPV-only feature in that case -- Any thoughts on that?

I would split TPV and PPS, just as we now send TPV to SHM(0) and
PPS to SHM(1).  That makes it makes it easy to debug with just
'ntpq -p' and allows easy fudge tuning.

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

Screenshot02032015.png
Description: PNG image

tmp.log
Description: Text Data