[Top][All Lists]

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

Re: gpsd time service: PPS-synchronised SHM samples rare, both sources g

From: Marek Szuba
Subject: Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent
Date: Tue, 15 Sep 2020 18:32:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 2020-09-15 18:00, wrote:

>>  - the GNSS receiver is an u-blox NEO-M8N,
> What signals are you using?  3.3V serial and 3.3V PPS?


>> with the only change to its
>> default configuration being that I have disabled BeiDou and enabled
>> Galileo
> Why?

Because I live in Europe and would rather use Galileo, hardware
limitations of this receiver mean it can only simultaneously work with
no more than three different frequencies, and since I would rather keep
both GPS and GLONASS enabled BeiDou was the odd one out. BTW. I have
since reset the received to factory settings to make sure there was
nothing odd there and it only had GPS+QZSS and GLONASS enabled
afterwards, I guess BeiDou must have been enabled by the unit vendor.

>> (TIMEPULSE; the driver has got the
>> capture_clear option set to avoid the possible one-second offset)
> What is this one-second offset you mention?  gpsd prefers to get both
> PPS edges.

I saw this message while running gpsd in debug mode:

KPPS:/dev/pps0 missing PPS_CAPTURECLEAR, pulse may be offset

So I did pass capture_clear to pps-gpio.

> Before starting gpsd, have you confirmed that /dev/pps0 has good
> data?

Yes, that's what I meant when I said "'ppstest /dev/pps0' works fine".
When I first tested it it looked exactly like

> source 0 - assert 1600105457.964698936, sequence: 1587031 - clear  
> 0.000000000, sequence: 0

and after enabling capture_clear I began seeing non-zero values for
clear as well.

> What does the SHM data look like?  Here is a sample:
>  # ntpshmmon
> ntpshmmon: version 3.21.1~dev
> #      Name Seen@                Clock                Real                 L 
> Prc
> sample NTP1 1600105612.072177652 1600105611.999999472 1600105612.000000000 0 
> -20
> sample NTP0 1600105612.161914767 1600105612.161782423 1600105612.000355529 0 
> -20
> sample NTP1 1600105613.001030853 1600105612.999998878 1600105613.000000000 0 
> -20
> sample NTP0 1600105613.159546423 1600105613.159483037 1600105613.000355735 0 
> -20

Yes, almost exactly like this - except NTP1 lines show higher precision
(-30) and there are way, way fewer of them than NTP0 ones.

>>  - while I do not see PPS lines in gpsmon output
> gpsmon is not really supported anymore.

I see. Might be worth not mentioning it in the Time Service HOWTO any
more, then.

> You need to go back to the beginning and look at what ppstest shows
> you.  No point at looking at gpsd, or ntpd, until ppstest looks good.

That's the weird thing, last time I checked ppstest looked okay (i.e. a
burst of quite a number of lines, haven't counted how many, every
second) both at the beginning of a run and when ntpd had long stopped
receiving samples from gpsd.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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