Yes. Lichvar seems to feel that it was gpsd that was doing that. Somewhere
perhaps you have a configureation for gpsd which tells it to use /dev/ttyS4.
I do not know how to use chrony to directly read the nmea. I only use the PPS
on bootup. I use network ntp to get the seconds for chrony and pps, not nmea.
I'm OK with not using gpsd if that's what's getting in my way here. The
Sorry I cannot help there.
All of the online resources that I found for building a GPS NTP server
indicated to install and use gpsd. I have the UART4
(/dev/ttyS4) mapped via a U-Boot overlay. I believe using gpsd and
gpsd-clients allows me to easily verify that I'm getting good
GPS data, 3D Fix, etc.
My PPS signal comes from the AdaFruit Ultimate GPS Breakout board that
I have connected to my BeagleBone Black. That board has
Tx/Rx pins and a PPS output.
My /etc/default/gpsd file contains the following. It seems like it
should be just using /dev/ttyS4 for the serial NMEA data but
you may very well be right that it's assigning /dev/ttyS4 as a source
for pps0 given what I see in the dmesg output. Maybe just
something I have wrong/missing in /etc/default/gpsd
The assignment of the /dev/pps? numbers has nothing to do with chrony or gpsd,
or any other user space program. It is assigned by the kernel depending on
what order the drivers request a device number from the kernel. Ie, it is long
before anything else happens. But I have no idea why you have two devices. You
have one pps signal I thought, and if you have two pps drivers they will fight
each other and make your timing much worse. soetimes one, sometimes the other
will get the interrupt first.
So I ask again, why are you using two interrupts?
Furthermore, chrony has the ability to driectly use the pps signal. It does
not need gpsd. I do not run gpsd, and chrony disciplnes my clock to of the
order of 1 microsecond.
# Default settings for the gpsd init script and the hotplug wrapper.
It does not matter.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
# Use USB hotplugging to add new USB devices automatically to the
daemon
USBAUTO="false"
# Devices gpsd should collect to at boot time.
^^^^^^^^ I assume that should be "coonnect"
# They need to be read/writeable, either by user gpsd or the group
dialout.
DEVICES="/dev/ttyS4"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
On Tue, Nov 28, 2017 at 4:21 AM, Bill Unruh <
Not sure why you use gpsd. If you are using the serial
port,
just doing (or
setting up a script in /etc/init.d and /etc/rc?.d to do an
ldattach 18 /dev/ttyS0 should work to set up /dev/pps0
and chrony can then use that.
(Or is your pps attached elsewhere).
And then put
refclock PPS /dev/pps0
into chrony.conf.
+1(604)822-3273
+1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____
Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/
Bill,
Thanks for your response. I actually did
basically what
you suggested prior to my post.
* Loaded latest BBB debian image onto the
BeagleBone
eMMC.
* Compiled NF3H-PPS-00A0.dts file into a .dtbo
file in
/lib/firmware
* Updated /boot/uEnv.txt to pull in
NF3H-PPS-00A0.dtbo
and BB-UART4-00A0.dtbo into U-Boot
configuration
* Rebooted
* apt-get update
* apt-get upgrade
* apt-get dist-upgrade
* apt-get autoremove
* apt-get autoclean
* apt-get install man-db
* apt-get install pps-tools
That should be installed before you try to recompile
chrony. In
particular,
you need the /usr/include/sys/timepps.h for chorny to
compile in
pps.
You can also use gpsd to handle the pps, and it will
feed the
pps times into
a shared memory.
At this point I could see I was getting PPS
pulses on
/dev/pps0 using ppstest
* apt-get install gpsd
Why?
* apt-get install gpsd-clients
* systemctl disable gpsd.socket
* systemctl stop gpsd.service
* Made edits to /etc/default/gpsd and
/lib/system/gpsd.service
* systemctl daemon-reload
* systemctl start gpsd.service
At this point I was able to verify PPS pulses on /dev/pps0
and valid NMEA data coming in on /dev/ttyS4
(using cgps)
* apt-get install chrony
* systemctl stop chrony
* In chrony source directory...
+ ./configure --prefix=/usr
--sysconfdir=/etc/chrony (this set up chronyd.exe to point to
/etc/chrony/chrony.conf)
+ make install
Upon my next reboot I found that chrony didn't start.
Complaining about /dev/pps0
I think gpsd may be grabbing pps0.
Checked /dev/pps1 and saw that pulses were now
coming in
there
Changed chrony.conf to use /dev/pps1
Rebooted
Saw using systemctl status chrony that the daemon didn't
start because it couldn't access /dev/pps1
Verified I was getting PPS pulses on /dev/pps1
using
ppstest
Started chrony using systemctl start chrony
Saw using systemctl status chrony that the daemon
started
successfully
Examined dmesg output to verify pps1
I'm not entirely sure what step along the way the PPS
switched over to /dev/pps1. All I can tell right
now is that once that
happens chrony won't start during boot due to it not being
able to access /dev/pps1 at the time systemd
starts it (or so it
seems). My plan is to take this BBB back to the base BBB
debian image again and do reboots after each
step (after installing
pps-tools), checking PPS after each reboot to try
an
isolate what step seems to cause the switchover. My
hope is that once I
isolate that I will be able to figure out what needs to
change to get chrony to start successfully on
reboot/power-cycle.
TRy not starting gpsd.
On Mon, Nov 27, 2017 at 6:47 PM, Bill Unruh
Firstly, your problem was I believe that chrony as
delivered by debian did not
support pps. You can make sure that it does
by
simply installing pps-tools by
debian and then recompiling the Debian
chrony.
Chrony looks for the file
/usr/include/sys/timepps.h and if it is theere it
compiles with PPS support.
So just install pps-tools, and then do whatever you
need to on debian to
recompile chrony source. (I use Mageia/rpm,
and
there a simple rpmbuild --rebuild <chrony src rpm>
would recompile
it with pps support. That might well solve
the
original
problem you had.
If pps0 is taken by something then the pps
support
in the kernel would use
pps1.
As you propose a link from /etc/chrony.conf to
/etc/chrony/chrony.conf would
solve the problem of the location of chrony.conf.
Ie, since you are having loats of problems with
compiling the latest chrony
going with the distribution's chrony is probably the
easierst way to get it
disciplining your system.
William G. Unruh __| Canadian Institute
for|____
Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research
_|____
Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____
Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/
Unfortunately chronyd doesn't appear
to like
that setting. Upon reboot it complained that
dropping root
privileges was not
supported. I rebuilt again without it but now
appear to be encountering other problems, more
related to
BBB and debian I think.
Seems like I can't seem to predict
very well
what device gets assigned for PPS and why. When
I started
the setup process the PPS
was going to /dev/pps0 as I would expect. Then
after my last reboot it was getting assigned
/dev/pps1
and it appears that device
isn't ready at the time chronyd is started by
systemd so it has to be started up manually
using
systemctl which is a no-go for
my application. I posted to the
BeagleBone
google group to see if anyone has ideas as to
why. I'm
relatively sure it has to do
with the startup order from systemd
but I'm
not expert enough to know how to remedy it.
I want to thank you again for all of the help
you've been providing (and the patience).
There are sooooo
many deep technical
details to all of this that it's hard
to come
up to speed.
On Mon, Nov 27, 2017 at 12:04 PM, Joe
Smith
It appears that the apt-get
chrony
package creates a _chrony user and _chrony group
for the
daemon. That is the user
that currently owns
/var/run/chrony.
When I started chrony after building/installing
from source I
did a "sudo
systemctl start chrony" and the
chronyd.exe process that is running is owned by root.
Given this,
it looks like the
best course of action is probably to
rebuild with the --with-user=_chrony option. I'm
assuming
(possibly wrongly)
that the daemon switches the user to
_chrony after it starts up if it's built with
that option.
On Mon, Nov 27, 2017 at 11:44 AM, Miroslav
On Mon, Nov 27, 2017 at
11:15:07AM
Post by Joe SmithSeems to be working now
although I do
get this warning/error from systemctl
Post by Joe Smithstatus chrony
Wrong owner of
/var/run/chrony (UID !=
0)
Post by Joe SmithNot sure that it's
significant given
that it seems to be running properly.
That indicates the previous
chronyd
dropped root privileges (the owner
of /var/run/chrony is not root), but the
new one is keeping them and
refusing to write to the
directory. It
will not be possible to use
chronyc to make changes in the
configuration until you reboot or
remove the directory and restart
chronyd.
You should either recompile
chrony with
the correct user specified by
the --with-user option, or
specify the
user with the -u option on
the chronyd command line or use the user
directive in chrony.conf.
--
Miroslav Lichvar
--
To unsubscribe email
with "unsubscribe" in the subject.
For help email
with "help" in the subject.
Trouble? Email