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 # Default settings for the gpsd init script and the hotplug wrapper. # 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. # 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 <un...@physics.ubc.ca> wrote: > 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. > > > > > 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 |____ un...@physics.ubc.ca > Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/ > > On Mon, 27 Nov 2017, Joe Smith wrote: > > 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 <un...@physics.ubc.ca> wrote: >> 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 |____ >> un...@physics.ubc.ca >> Canada V6T 1Z1 ____|____ and Gravity ______|_ >> www.theory.physics.ubc.ca/ >> >> On Mon, 27 Nov 2017, Joe Smith wrote: >> >> 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 < >> joe.sm...@riptidesoftware.com> wrote: >> 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 Lichvar < >> mlich...@redhat.com> wrote: >> On Mon, Nov 27, 2017 at 11:15:07AM -0500, Joe Smith >> wrote: >> > Seems to be working now although I do get this >> warning/error from systemctl >> > status chrony >> > >> > Wrong owner of /var/run/chrony (UID != 0) >> > >> > Not 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 chrony-users-requ...@chrony.tu >> xfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tu >> xfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >> >> >> >> >> >>
