[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: |
Gary E. Miller |
Subject: |
Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent |
Date: |
Wed, 16 Sep 2020 10:59:00 -0700 |
Yo Marek!
On Tue, 15 Sep 2020 18:32:53 +0200
Marek Szuba <scriptkiddie@wp.pl> wrote:
> >> 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.
GLONASS has the worst timing of the big-4. Galileo has the worst outage
record. But most will never notice any difference.
> >> (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
That is telling you about a known bug in the pps-gpio driver. It
only passes on edge, so clients can not auto-detect the proper
PPS edge.
If you pick the wrong edge, you are off by the pulse width (often 100 ms),
not by a whole second.
> So I did pass capture_clear to pps-gpio.
WHich may, or may not be the correct edge.
> > 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
Well, fine, except for missing "clear'.
> and after enabling capture_clear I began seeing non-zero values for
> clear as well.
How did you do that?
>
> > What does the SHM data look like? Here is a sample:
> >
> > # ntpshmmon
> > ntpshmmon: version 3.21.1~dev
Looks good to me.
> Yes, almost exactly like this - except NTP1 lines show higher
> precision (-30) and there are way, way fewer of them than NTP0 ones.
The "precision" is a joke. It is just a constant someone pulled out of
air air. Itgnore it.
> >> - 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.
Eric wrote the howto, he likes gpsmon, so unlikely to happen soon.
> > 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.
Well, that would be a harware or kernel problem. Hard to say since it
is gone.
So far, looking good, do you have any questions?
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpfqJpxy3udh.pgp
Description: OpenPGP digital signature
- gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/14
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/16
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent,
Gary E. Miller <=
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/18
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/18
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/18
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Gary E. Miller, 2020/09/18
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Mike Simpson, 2020/09/19
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Greg Troxel, 2020/09/19
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Marek Szuba, 2020/09/21
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Greg Troxel, 2020/09/21
- Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Gary E. Miller, 2020/09/18
Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent, Gary E. Miller, 2020/09/18