William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Wed, 16 Sep 2020,
Just as a side note here, I am on /dev/ttyAMA1 because the Raspberry Pi 4 has
additional UARTs that can be configured with other device tree overlays.
> On Sep 15, 2020, at 9:02 PM, Hal Murray wrote:
>
>> But then I do not use something like a Rasberry.
>
> On a Pi, the built in serial port
> But then I do not use something like a Rasberry.
On a Pi, the built in serial port is /dev/ttyAMA0
It doesn't have any pins for the modem control signals.
At least with the typical setup.
On a Pi and similar SoC chips, there are not enough pins for all the potential
uses. There is a layer of
> I do not use gpsd for the pps. I use the serial port to read the interrupt
> modprobe ppl-ldisk
> ldattach 18 /dev/ttyS0
This is very interesting, thank you very much for mentioning it. I'll try
it out when I get the moment.
> Sticking another program (gpsd) between the device and the kernel
I do not use gpsd for the pps. I use the serial port to read the interrupt
modprobe ppl-ldisk
ldattach 18 /dev/ttyS0
Now I have no idea what kind of device a ttyAMA0 is (USB emulation of a serial
port?) Sticking another program (gpsd) between the device and the kernel does
not seem like a great
Wait a while. Your PPS is still catching up.
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_
Reading the replies by Gary E. Miller it seems that your only options are
to either rewire your PPS output or patch gpsd to fix the wrong
association. I personally went with rewiring my PCB because it was less
effort than building my own gpsd.
On Wed, Sep 16, 2020 at 1:56 AM Ryan Govostes
Here is the bug I filed: https://gitlab.com/gpsd/gpsd/-/issues/103
Specifying /dev/pps0 on the gpsd command line works to an extent in that it
causes gpsd to start publishing to chrony.pps0.sock. However, it still has
trouble in that it refuses to publish to chrony.ttyAMA1.sock because there’s
> I’ll file a bug against gpsd for this case.
Well no need, this behaviour was deemed "correct" already.
> sudo gpsd -n -N -D3 -F /tmp/gpsd.sock /dev/ttyAMA1
Manually specifying /dev/pps0 here doesn't help?
On Wed, Sep 16, 2020 at 12:49 AM Ryan Govostes wrote:
> Seems like gpsd hardcodes
Seems like gpsd hardcodes /dev/ttyAMA0 as “oh you’re using a Raspberry Pi HAT”
and then uses /dev/pps0, which would be the GPIO PPS source. Otherwise it
searches sysfs to find the PPS device for the given NMEA device.
The reason it has to have that hardcoded is because the kernel pps-gpio
On 9/15/20 6:10 AM, Miroslav Lichvar wrote:
Of course it isn't easy to detect the case where more than what is required
has been opened up. However possibly with suitable documentation this is not
a major issue?
Do you think the following description of the option would be
sufficient?
*-U*::
I can confirm that /dev/ttyAMA1 streams incoming NMEA messages. I can confirm
/dev/pps0 is a working PPS device.
I can confirm that gpsd is configured to access /dev/ttyAMA1 and when I launch
it with
sudo gpsd -n -N -D3 -F /tmp/gpsd.sock /dev/ttyAMA1
I see it getting a satellite fix,
Check what you have specified in the list of devices to be used.
I personally couldn't convince gpsd to use pps1 instead of pps0, but you
might be having the opposite issue :S
What actually is pps1 on your system? It might play a role.
On Tue, Sep 15, 2020 at 11:02 PM Ryan Govostes wrote:
>
I’m not sure. Its logs look OK, but it prints out:
gpsd:INFO: KPPS:/dev/ttyAMA1 RFC2783 path:/dev/pps1, fd is 9
Note that /dev/pps1 is _not_ the PPS device I expect to use. This device only
appears while gpsd is running so it appears to be created by it? ppstest only
reports timeouts
> However, `chronyc` does not report any updates being received from this
source.
If you aren't seeing anything on SHM1 either, then gpsd still has issues
with reading the PPS source. Check its logs.
On Tue, Sep 15, 2020 at 10:56 PM Ryan Govostes wrote:
> Ah OK, I guess the part that was not
Ah OK, I guess the part that was not clear to me was that chronyd _creates_
this socket when configured with refclock SOCK, rather than simply connecting
to it.
When I configured this and restarted chronyd and then gpsd, it did create the
socket file. However, `chronyc` does not report any
> but also I don’t see that socket you’re referencing being created.
> I don’t see any AppArmor logs that seem to indicate anyone was prevented
from creating this file.
Have you actually told chrony to create it?
> for a while but the PPS never updated:
Yes, this is exactly why I suggested you
First, disable systemd-timesyncd if you're using chrony: *sudo systemctl
disable --now systemd-timesyncd*
Second, enable chrony, pretty sure it isn't enabled by default after
install: *sudo systemctl enable chrony*
Why do you want to SHM 0 (non-PPS-corrected) NMEA time, instead of SHM 1 or
Thanks, I removed the offset and delay so the reference clock configuration is
now:
refclock SHM 0 refid GPS precision 1e-1
refclock PPS /dev/pps0 refid PPS
My intention is to have GPS set the system date and time and then have the PPS
signal keep it from drifting.
After
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Tue, 15 Sep 2020,
> Finally, I read that using Unix sockets rather that shared memory is
preferable, but my chronyd does not seem to create those sockets.
You need to check the AppArmor policies in-use. Broken gpsd ones were
shipped to Ubuntu users, make sure gpsd has access to the chrony sockets
and the pps
Hi all,
I am setting up chronyd on an embedded Linux device to synchronize the system
clock using a GPS module. The GPS device sends NMEA strings over the character
device /dev/ttyAMA1 and I have also configured /dev/pps0, both of which appear
to be working OK.
The system is running Ubuntu
On Mon, Sep 14, 2020 at 07:59:23PM -0400, Kevin wrote:
> As for breaking features I don't think this will be a major concern as the
> failure will be obvious. As I understand it after reading the config chrony
> opens all of the files it needs (before dropping privledges) so it would be
> easy to
23 matches
Mail list logo
