Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent

[Marek Szuba]

On 2020-09-15 18:00, gpsd-users-request@nongnu.org wrote:

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

Exactly.

>> 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.

-- 
MS

signature.asc
Description: OpenPGP digital signature