3.7. PTP time synchronization#

3.7.1. PTP setting via web UI#

The Web UI has a tab called PTP Settings. Opening it reveals five buttons. The description below describes each button’s functionality.

../../_images/ptp_web_gui.png

Fig. 3.10 Web GUI for PTP settings#

3.7.1.1. Update System Time#

Retrieves the local time via an HTTP request and updates the system time.

Equivalent command is shown as below.

sudo date -s "$(wget -qs0- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z" && sudo phc_ctl /dev/ptp0 set

3.7.1.2. Start PTP-based Synchronization#

Starts the ptp4l slave (client) program on eth0.

Equivalent command is shown as below.

sudo ptp41 -i eth0 -s

3.7.1.3. Sync System Clock to PHC#

Starts a program that updates the system clock based on the PHC time.

Equivalent command is shown as below.

sudo phc2sys -a -r

3.7.1.4. Stop PTP-based Synchronization#

Stops the ptp4l slave program.

Equivalent command is shown as below.

sudo pkill -x "ptp41"

3.7.1.5. Stop PHC to System#

Stops the PHC-based system

Equivalent command is shown as below.

sudo pkill -x "phc2sys"

3.7.2. Testing PTP#

In order to use PTP, the host PC must be running ptp4l on master mode (-m flag), while the device must be in slave mode. The device can start the appropriate PTP programs through the web GUI, as shown in the table above. The following steps to start PTP and test it have been shown to work.

3.7.2.1. Start the PTP master on the host#

You can start the PTP master by issuing the following command on the host:

sudo ptp41 -i enp2s0f1 -m -S -A # replace enp2s0f1 with the proper interface

3.7.2.2. Start the PTP slave on the device#

Click on “Start PTP-based Synchronization” on the PTP tab of the web GUI. It is the second button in the image above.

3.7.2.3. Verify that PTP-based streaming works#

In the “RTP Control” tab of the web GUI, enable Custom Timestamp and Start of Frame Then, start streaming according to the section on streaming. Afterwards, in the host PC, verify that the packets contain appropriate RTP information by issuing the following command:

sudo tcpdump -i enp2s0f1 -T rtp -x | grep "0x0020" | awk '{print "0x"$3$4}'

This should print out the current epoch seconds in HEX format. You can verify this by comparing side-by-side with the website epoch converter.

For instance, if you get 0x66bb12ac, the timestamp embedded in the data is 2024-8-13 Tuesday 08:00:44 (GMT)

Note

The custom timestamp is constructed as follows: 96 bits possible in total:

  • 48b - MSBs from [95:48] for seconds representation

  • 32b - [47:16] for nanoseconds representation

  • 16b - [15:0] for fractions of nanoseconds representation

Thus the RTP header will contain the following set of data when used with custom_timestamp:

  • RTP header’s timestamp - 32b all for the 32b of MSBs from the seconds-related portion of the timestamp array

  • RTP header’s SSRC_ID - 32b - 16b - MSBs [31:16] for low part of the seconds on 16b, and the rest for the high part of the nanoseconds representation

  • Additional RTP header’s CSRC_ID (only one in this case by using a CSRC count == 1 and a first CSRC field with 32b added to the packet - resulting a larger packet dimension) - 16b for the low part of the nanoseconds and 16b for the fractions of nanoseconds representation

3.7.2.4. Verify that the system clock synchronizes via PTP#

Pressing the “Sync System Clock to PHC” button synchronizes the system clock. You can verify that the two clocks are in sync by comparing the output given by the following command on the two machines:

watch -n 0.1 date +%s. %N

You can simulate a wrong clock by issuing the following command on the board:

sudo date +%T -s "15:00:00"

Synchronization result

You can confirm that “With synchronization” result, the system clock is matching between the host and the board. On the other hand, in the case of “Without synchronization”, the system clock differs between the host and the board.