I realize that it's been almost 5 months since I started this thread. I moved to other more pressing work during this time, and I'm now coming back to this. Thank you for all that information. That is very useful to me, and I appreciate it.
The GPS/IMU I'm using won't work with gpsd. It has its own custom binary format for the time and other inertial values. I have already written code that can read these packets, so now I need to pass this time to PTP. From the sounds of it, I don't think I can simply take the time from the GPS and call clock_settime() to set the PHC. It sounds like I need a bunch of algorithms to get the PPS and do other things to reduce jitter and adjust the time before setting the PHC, all of which are outside my expertise at the moment. ntpd and chronyd already do this. So one idea would be to configure ntpd/chronyd to take the PPS and then my application can pass the time using SHM. ntpd/chronyd can do their thing to smooth out and properly adjust the system clock. With the system clock being disciplined, I can then use phc2sys to synchronize the PHC to the system clock using something like "-s CLOCK_REALTIME -c eth0". (Do I need to use the -d option to pass /dev/pps0?) Are there any downsides to this? On Mon, Aug 13, 2018 at 5:35 PM Chris Caudle <ch...@chriscaudle.org> wrote: > I am replying to a digest, hopefully the message headers are still OK. > > > From: Keith Squier <keith.squ...@gmail.com> > > > How do I feed the 1 PPS to the PHC? > > As Richard mentioned, that depends on your hardware. You will need > appropriate signal conditioning and protection circuitry that takes the > PPS input from your GPS time source, makes sure the signal is at the > appropriate voltage level, ESD protection, etc. > > There are two slightly different forms of pulse-per-second. From the raw > GPS receiver the PPS signal will jitter around on order of ten to a few > tens of nanoseconds compared to a perfect pulse-per-second signal. There > are devices known as GPS disciplined oscillators which take a high quality > temperature compensated or oven controlled oscillator, slave the long term > average frequency of that oscillator to GPS time, and regenerate the > pulse-per-second output from the high quality oscillator. I point this > out a little bit out of order in the discussion, it will come up again > later. > > > read the 1 PPS time stamps from the PHC and set the PHC? > > As Richard pointed out there is a kernel API for that. You have to > reinvent some wheels to a certain extent. > > > Instead of feeding the PPS to the PHC, reading the time stamps from the > > PHC, and then setting the PHC to match the GPS time, wouldn't it be > better > > to have a separate program that reads the PPS and time from the GPS and > > sets the PHC? > > That is one approach. You can have ntpd or chronyd handle keeping system > time synchronized to GPS, then transfer the system time to the PHC. > The advantage is that ntpd has what in PLL terms would be the loop filter, > to help filter out short term or transient noise in the PPS timestamps and > smoothly adjust the system clock to follow. It also moves the tedious > work of parsing all the GPS messages out to ntpd (which may actually > offload the work to gpsd). > > That does add additional pieces in the way, and typically ntpd does not > have access to a timer that can latch the time of the PPS in hardware, > which is absolutely required for reasonably tight accuracy. > > > Of course, then I wonder what the point of the PPS is if I > > have the time from the GPS. > > PPS is a hardware signal which provides indication of the top of the > second. The time message from the GPS is a text string which has to be > parsed to determine the current time, and due to vagaries of how the > message is generated in most GPS receivers no matter what you key off of > in the text stream you will get a minimum milliseconds of variation, and > often tens of milliseconds variation in the arrival time of the first (or > last) character relative to a perfect clock. That is compared to the tens > of nanoseconds variation in the PPS signal, so roughly a million times > worse. You need both the PPS signal for accurate rate keeping, and the > time message from the receiver to know the correct starting time. > > > Is it really this difficult to synchronize a system to a GPS receiver, or > > am I overthinking things? > > It can be tricky. For a truly robust system you would want a filtering > behavior to prevent over-reacting to short term variations in either the > PHC timer clock source, or the PPS input from the GPS, possibly handling a > missed PPS pulse if you want to be able to handle slightly buggy GPS > receivers, parse out error and status messages from the GPS receivers, > etc. Probably it would be better to separate out rate handling and GPS > handling, pass off the details of GPS message handling to gpsd, and just > make sure that the PPS is handled correctly in hardware. Studying ntpd > could be useful for ideas about the filtering, but the time constants > would probably be an order of magnitude different. > > > I'm going to reiterate to make sure I'm > > understanding correctly. I need to physically connect the 1 PPS output > pin > > to an input pin on my network card. > > To have the network MAC perform the timestamp of the PPS, yes. > Keep in mind that the clock of the MAC will be free-running compared to > when the PPS arrives. Depending on how accurate the clock is, and whether > it is temperature compensated, the rate of the PPS signal arrivals will > appear to change. There will need to be an adjustment loop which compares > the PHC cycle count with the expected cycle count, and either the PHC rate > will need to be adjusted (if the hardware supports that), or a synthetic > software clock will need to be used to simulate a clock running at the > corrected rate. > > > Then I need to use phc2sys to synchronize > > the system clock to the PHC. Is that correct? > > Assuming you need the system clock to be synchronized to PTP time (as > opposed to some other software using PTP time directly without needing the > system time to be synchronized). > > > Does this mean I don't need an NTP server like ntpd or chrony? > > Correct, this would take the place of ntpd or chronyd. > > > about other configurations where people feed the PPS and NMEA sentences > > from the GPS into gpsd, which then feeds the time to ntpd/chrony to set > > the Linux system clock, which is then used to synchronize the PHC > > That allows you to use existing software components. As far as I am > aware there is not an existing software package which has PPS drivers, and > the ability to parse time provided by gpsd, and set the system time > directly while also disciplining the rate of the PHC clock to follow the > rate set by the PPS input. > > > phc2sys. Your method is skipping NTP altogether. Wouldn't an NTP server > > more smoothly adjust the system clock? > > Probably. > > -- > Chris Caudle > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
