This article focuses on the time synchronization scheme of gps+pps+gpsd+chrony+ptpd+gptpd, which is widely used in autonomous driving. This article is only my own record during the debugging process. If there is anything wrong, welcome to discuss: [email protected]
The detailed scheme is as follows: the ubxclient on the Tbox side (IMX8 series) receives the GPS time and PPS signal from the GPS (such as the ublox series), and the Tbox side forwards the NEMA/UBX message received from the GPS to the gpsd through udp, and then chrony is combined with the gpsd’s The time information and the pps information under linux are used for time synchronization and correction. The follow-up Tbox will be used as the server to synchronize the time of the automatic driving computing chip (such as nvida orin/xavier) through ptpd, and then the automatic driving computing chip will send it to the MCU through gptpd. /lidar etc. for time synchronization, the detailed block diagram is as follows:
1.PPS signal processing
Configure the ublox chip PPS signal output frequency 1HZ, measured tbox terminal pps_in input signal:
From the test results, the period of 17 pulse signals is 7.441s+9.564=17.005s, the period accuracy is less than 0.001s, and the accuracy is relatively high
Linux opens the pps configuration:
CONFIG_PPS=y
CONFIG_PPS_DEBUG=n
CONFIG_PPS_CLIENT_KTIMER=n
CONFIG_PPS_CLIENT_LDISC=n
CONFIG_PPS_CLIENT_GPIO=y
Note: If ktimer/ldisc is turned on, the device node may be different. You can see the specific corresponding device node in the kernel log. Our side ktimer/ldisc is not turned on, and the pps_gpio node is /dev/pps2. To eliminate errors, you need to configure this node
dts configuration:
pps_ubx{
compatible = "pps-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pps>;
gpios = <&gpio4 2 GPIO_ACTIVE_HIGH>;
status = "okay";
};
pps processing related code in kernel: drivers/pps/clients/pps-gpio.c
By default, linux has added pps-related processing to the kernel code, focusing on triggering PPS interrupts. My project uses the rising edge to trigger interrupts (because ublox defaults to aligning the rising edge with the whole second)
Interrupt handler:
static irqreturn_t pps_gpio_irq_handler(int irq, void *data)
{
const struct pps_gpio_device_data *info;
struct pps_event_time ts;
int rising_edge;
/* Get the time stamp first */
pps_get_ts(&ts); ----Get the time information triggered by the interrupt, and then pass it to the application layer
info = data;
rising_edge = gpio_get_value(info->gpio_pin);
if ((rising_edge && !info->assert_falling_edge) ||
(!rising_edge && info->assert_falling_edge))
pps_event(info->pps, &ts, PPS_CAPTUREASSERT, NULL);
else if (info->capture_clear &&
((rising_edge && info->assert_falling_edge) ||
(!rising_edge && !info->assert_falling_edge)))
pps_event(info->pps, &ts, PPS_CAPTURECLEAR, NULL);
return IRQ_HANDLED;
}
pps_event : register a PPS event into the system, and the subsequent application layer can obtain information such as the time and serial number of the pps trigger
For details about pps, please refer to: PPS - Pulse Per Second — The Linux Kernel documentation
pps-tools:http://linuxpps.org , GitHub - redlab-i/pps-tools: User-space tools for LinuxPPS
Use of ppstest/ppswatch (result after synchronization):
2. GPSD part
GPSD startup configuration:
/usr/sbin/gpsd -n -P /run/gpsd.pid -F /var/run/gpsd.sock udp://127.0.0.1:50000
-n don't wait for client connects to poll GPS must be selected when working with chrony
-F sockfile specify control socket location
udp://127.0.0.1:50000 Receive nema and ubx data sent by ubxclientsocket, and also directly configure uart device nodes of ublox
Related tools to use:
cgps:
Note: The time/latitude/longitude and other information in the figure can be used to determine whether the star has been searched, and the time and location information have been obtained. Only after the time and location information is obtained, gpsd can cooperate with chrony to synchronize the time to eliminate the pps error
3. Chrony part
Chrony is another implementation of NTP (Network Time Protocol, a protocol for server time synchronization). Unlike ntpd, it can synchronize the system clock faster and more accurately, minimizing time and frequency errors. , chrony is two programs used to maintain the accuracy of the computer system clock, these two programs are named chronyd and chronyc
chronyd runs a daemon process in the background for synchronizing system time
chronyc provides a user interface for monitoring performance and configuration
The principle of chrony+gpsd calibration:
gpsd reads the gnss data from the serial port or the network and analyzes it, and outputs the analysis result through UNIX socket or shared memory, and chrony obtains the analyzed gnss data from the UNIX socket or shared memory, combines it with the pps information, and corrects the system time
note: The principle of chrony correction is to achieve the correction time by controlling the increase or decrease rate of the time, and the way of jumping is rarely used. The way of jumping may affect other applications, which may lead to a slower correction, but if The deviation is too large or the first correction can also be configured as a conditional jump mode
Note: chrony and ntp are in conflict and cannot exist at the same time. You need to pay attention when systemd starts configuration
chronyd configuration file /etc/chrony.conf
One of the main activities of the driftfile chronyd program is to calculate the ratio of the computer's increase or decrease time based on the actual time. It is most reasonable to record it in a file. It will compensate the system clock after restarting, and even, if possible, Get better estimates from clock servers
allow/deny Here you can specify a host, subnet, or network to allow or deny NTP connections to the machine acting as the clock server
makestep Normally, chronyd will cause the system to gradually correct any time deviations by slowing down or speeding up the clock as needed. Under certain circumstances, the system clock may drift too quickly, causing the adjustment process to take a long time to correct the system clock. This directive forces chronyd to step up the system clock when the adjustment period is greater than a certain threshold, but only if there are no more clock updates because chronyd startup time exceeds the specified limit (a negative value can be used to disable the limit).
rtcsync enables kernel mode, and the system time is copied to the real-time clock (RTC) every 11 minutes
refclock set the clock source
Note: For detailed and complete instructions, please refer to the official chrony documentation : chrony – chrony.conf(5)
chronyc sources -v command to view the synchronization results:
It can be seen that the deviation is about 125ns
Related instructions:
M: This indicates the mode of the signal source. ^ means server, = means peer, # means local connection's reference clock
S: This column indicates the status of the source
* Indicates the source that chronyd is currently syncing to
- Indicates an acceptable source that is excluded by the merge algorithm
+ Indicates acceptable sources, combined with the selected source
? Indicates a source that has lost connectivity or whose packets failed all tests. It also shows on startup until at least 3 samples have been collected from
x indicates a clock that chronyd considers to be a fake quote (i.e. whose time does not agree with most other sources)
~ indicates a source where time seems to have too much variability
Name/IP address: This shows the name or IP address of the source, or the reference ID of the reference clock
Stratum: This shows the stratum of the source, as reported in its most recently received samples. Stratum 1 represents a computer with a locally connected reference clock. Computers that sync with tier 1 computers are on tier 2. Computers synced with tier 2 computers are in tier 3, and so on
Poll: This shows the rate at which the source is being polled, as the base 2 logarithm of the time interval in seconds. So a value of 6 means that a measurement is taken every 64 seconds. chronyd will automatically change the polling rate according to the current situation
Reach: This shows the reachability register of the source printed as an octal number. The register has 8 bits and is updated on every packet received or lost from the source. A value of 377 indicates that valid replies to all users were received from the last eight transmissions
LastRx: This column shows how long ago the last good sample was received from the source (displayed in the next column). Measurements that fail certain tests are ignored. Usually in seconds. letter m , h , d or y for minutes, hours, days or years
Last sample: This column shows the offset between the local clock and the source when it was last measured. Numbers in square brackets indicate actual measured offsets. Can be suffixed with ns (for nanoseconds), us (for microseconds), ms (for milliseconds), or s (for seconds). Numbers to the left of the square brackets represent raw measurements, adjusted to allow for any swing imposed on the local clock thereafter. The numbers following the +/- indicators indicate the margin of error in the measurement. A positive offset indicates that the local clock is ahead of the source clock
Reference documents: