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
