gpsd-users
[Top][All Lists]
Advanced

[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: Fri, 18 Sep 2020 23:34:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 2020-09-18 21:36, Marek Szuba wrote:

> Regarding the PPS signal, I have decided to bring out the big guns and
> connected the receiver to an oscilloscope. Result - unless I have wired
> something wrong, the PPS waveform has exactly the same shape as what the
> receiver sends out on the TX line... That can't be right, can it? The
> odd thing is, I have checked both the computer-side connectors and (just
> to be extra sure) the pins of the chip (whose label by the way says
> NEO-M8N after all) for short circuits and there seem to be none.
> Something wrong with the configuration of the TIMEPULSE signal?

Yet another update: two hours ago I connected the same receiver (no
factory reset, no reconfiguration) to the same system using a USB-TTL
converter (with the PPS line connected to DCD), fired up gpsd and
configured chrony to listen to SHM 0 and SHM 1. Result: ever since the
received got the 3D fix chrony has been getting samples for both NTP0
and NTP1 every 4 seconds at most, PPS signal looks like it should both
on the oscilloscope (one 100-ms square pulse every second) and in
ppstest (two events in short succession every second), and while so far
there has been fairly sizeable offset on both sources (between 3 and 4 s
on SHM 0, solid 4002 ms on SHM 1; will keep it running to see what
happens) which resulted in them having been marked as false tickers, the
jitter stabilised pretty quickly at 100 ms and 440 us, respectively.

Native TTL + pps-gpio, on two different systems: unusable. Cheap USB 1.1
serial converter: works fine, until something starts competing with the
device for I/O bandwidth anyway. I honestly do not know what is going on
here.

-- 
MS



reply via email to

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