[Top][All Lists]

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

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

From: juergen perlinger
Subject: Re: [gpsd-dev] What is our current bug state?
Date: Tue, 03 Feb 2015 20:11:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hello Gary, Hello Hal!

I have another version in

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

reply via email to

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