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

[juergen perlinger]

Hello Gary, Hello Hal!

I have another version in

http://people.ntp.org/perlinger/for_test/refclock_gpsd/refclock_gpsdjson.c

It should log / print any errors 'getaddrinfo()' returns, by number an 
the corresponding error text as provided by 'gai_strerror()'. If 
'gpsd_init_socket()' is never called, then it's most likely that 
'getaddrinfo()' failed indeed, and it would be useful to know why.

On 02/03/2015 12:13 AM, Gary E. Miller wrote:
> Yo Hal!
>
> On Mon, 02 Feb 2015 14:12:21 -0800
> Hal Murray <address@hidden> wrote:
>
> > The symptom is that ntpd is seeing 20 ms of fuzz on a JSON connection
> > that should be using PPS.
> As soon as I can see ntpd use GPSD_JSON I'll work on it directly.  I've
> never seen it work at all.
>
> Another of my complaints about the new GPSD_JSON driver is it will
> flip-flop from GPS serial time to PPS time and back with no warning.
>
> Note this in refclock_gpsdjson.c:
>
>          /* now aggregate TPV and PPS -- no PPS? just use TPV...*/
>
> That will lead to mysterious problems like 20mSec jumps.
>
> 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.

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.

I'm not sure if the jitter results from using TPV alone, or from jumping 
between PPS-augmented time and TPV receive time. 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. This 
would indeed cause problems. It might be best to remove the TPV-only 
feature in that case -- Any thoughts on that?

Thanks for the feedback & Cheers
    Pearly