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
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 cl
gt; Yes, this is awfully documented online.
>
>
>
> On Tue, Sep 15, 2020 at 10:08 PM Ryan Govostes wrote:
> Below Bill argued against using /var/run/chrony.ttyAMA0.sock, but also I
> don’t see that socket you’re referencing being created. I don’t see any
> AppArmor logs
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:/de
18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3Dreserved=0
>
> On Tue, 15 Sep 2020, Ryan Govostes wrote:
>
>> Hi all,
>>
>> I am setting up chronyd on an embedded Linux device to synchronize the
>> system
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
/dev/ttyAMA1
Manually specifying /dev/pps0 here doesn't help?
On Wed, Sep 16, 2020 at 12:49 AM Ryan Govostes
mailto:rgovos...@whoi.edu>> wrote:
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. Otherwis
, that hack doesn’t trigger.
I’ll file a bug against gpsd for this case.
Ryan
On Sep 15, 2020, at 4:33 PM, Ryan Govostes
mailto:rgovos...@whoi.edu>> wrote:
I can confirm that /dev/ttyAMA1 streams incoming NMEA messages. I can confirm
/dev/pps0 is a working PPS device.
I can confirm tha
I use chrony to synchronize an embedded system’s clock. There are
systemd-controlled services on the system that I’d like to configure to wait
until the system clock is synchronized.
I can order these services to start after time-sync.target, but I need some
other service to start *before*
I am running ntpd on a local server. That server syncs its clock to
pool.ntp.org.
Now I want another device, running chrony, to sync its clock to the local
server, so I configured chrony with `server asdfasdfa iburst`. For comparison I
also added `server time.nist.gov iburst`.
I’m not sure
to seem off.
Fourth, what does ntpq tell you on the ntpd server? How accurate does it think
it is?
____
From: Ryan Govostes [rgovos...@whoi.edu<mailto:rgovos...@whoi.edu>]
Sent: Tuesday, March 16, 2021 14:10
To: chrony-users@chrony.tuxfamily.org<mail
I have a GPS receiver with PPS connected to an embedded Linux system. GPSD
feeds Chrony time updates from the GPS receiver over the Chrony socket.
The system clock is behind by a few months, and Chrony does not want to update
the clock to the time reported by GPSD.
I have read the FAQ and a
n 4 Mar 2022, at 7:07 am, Ryan Govostes (he/him)
mailto:rgovos...@whoi.edu>> wrote:
I have a GPS receiver with PPS connected to an embedded Linux system. GPSD
feeds Chrony time updates from the GPS receiver over the Chrony socket.
The system clock is behind by a few months, and Chrony does
hysics.ubc.ca%2Fdata=04%7C01%7Crgovostes%40whoi.onmicrosoft.com%7Cd7c24eedb1ac4cd05e8308d9fd98918b%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637819654143563575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=zqw7eoga2Z%2Fn%2BXQa9JVwPdh265mcK%2FhhnLkrUdcrIm4%3Dr
14 matches
Mail list logo
