Starting from the firmware V3.1.0, a REV-07 OS lidar supports 6 PTP profiles, namely:
- “default” - The IEEE 1588 Default PTP profile addresses many common applications. Most PTP capable devices support the Default profile.
- “default-relaxed” - based on “default” profile but with a relaxed 1 second time step threshold.
- “gptp” - Generalized PTP (gPTP) is the common name for the IEEE standard 802.1AS-2011 which improves the interoperability of PTP by simplifying the supported options. The gPTP profile is useful when using the Ouster sensor with gPTP compatible hardware such as an Audio Visual Bridge (AVB), e.g. the MOTU AVB.
- “gptp-relaxed” - based on “gptp” profile but with a relaxed 1 second time step threshold.
- “automotive-slave” - The Automotive Slave PTP profile is an extension to gPTP for automotive specific use cases. In particular it disables the BMCA and handles time steps to expedite convergence.
- “default-l2-relaxed” - This profile is based on the “default” profile, but with the network transport set to L2 and a relaxed 1 second time step threshold.
The current active PTP profile of the lidar can be queried through the following ways.
- HTTPie command
- cURL command
3.Web browser http API
Different PTP profiles are configured based on different applications and the PTP master requirements.
Among all the supported PTP profiles, “default” profile is most commonly used.
Now let me take the recent troubleshooting support for a customer on PTP time synchronisation as an example to discuss more about Ouster lidar PTP time synchronisation in the “default”/“default-relaxed” profile.
-
Firstly, you need to configure the Timestamp_Mode of the lidar to “TIME_FROM_PTP_1588”. Web browser is recommended to do the settings.
By default, the PTP profile of the lidar is “default”. I would recommend to confirm it with the above command. If your PTP master has a possibility to experience a time change or jump in the application (this is not a normal situation which should be avoided), please configure the PTP profile to “default-relaxed”.
HTTPie command:
cURL command:
-
If you are using a dedicated PTP Time Server device as the PTP master, before you are going to check for the lidar time synchronisation status, please check whether the master device is working properly by following the steps in the user manual of the device or by capturing the data stream through Wireshark.
If you are going to run the PTP service software on your Linux controller as the PTP master, please make sure the Ethernet interface that the lidar is connected to supports time stamping.
The ethtool utility can be used to query the supported capability of the network interface.
As the pictures shows, the Ethernet interface of the PC I am using supports both HARDWARE TIME STAMPING and SOFTWARE TIME STAMPING. Some Ethernet interface might only supports SOFTWARE TIME STAMPING which also can be used as the PTP master to synchronise OS lidar sensor. Ouster lidar supports HARDWARE TIME STAMPING and SOFTWARE TIME STAMPING. -
To verify whether the OS lidar PTP time synchronisation is successful or not, we can use commands or the web browser to query the response.
Here are the commands.
HTTPie command
http GET http://<IP address>/api/v1/system/time/ptp
cURL command
curl -X GET --url http://<IP address>/api/v1/system/time/ptp
Web browser
http://<IP address>/api/v1/system/time/ptp
Usually there are four indicators that can be used to judge whether the time synchronisation is successful or not.
parent_data_set.grandmaster_identity is the MAC address the Ethernet interface with “fffe” inserted in the middle.
time_status_np.gm_present is true, means the lidar has received the valid sync messages from the master and identified it as PTP master.
port_data_set.port_state is SLAVE, the lidar is working as the PTP slave.
time_status_np.master_offset this offset value is usually fluctuating within the range -250000 ~ 250000, it also varies among different Ethernet interface cards. The smaller the value, the higher the synchronisation precision.
But sometimes you might see the port_data_set.port_state remains “LISTENING” which means the lidar is not synchronised.
The illustration below shows the synchronisation process of the OS lidar.
If the port_state of the lidar remains “LISTENING”, you need to check the Annouce Message sent out from the PTP master. Ususally this is caused by settings in the config file of the PTP master don’t match the PTP time synchronisation requirements of the OS lidar.
Below are some parameters in the PTP master that I was focusing on to finally get the OS lidar synchronised onsite.
(1) Transport: UDP IPv4 (lidar PTP profile "default"/"default-relaxed")
(2) Delay Mechanism: E2E (lidar PTP profile "default"/"default-relaxed")
(3) PTP_TWO_STEP: true. (A one-step clock uses specialised network hardware not only to timestamp when a PTP Sync message leaves the device, but also to modify the outgoing Sync message’s t1 value with the actual departure time. )
(4) Priority1, Priority2: 128 (the values are used by the BMCA algorithm for the most accurate master clock selection. Lower values take precedence. )
(5) Grandmaster Clock Class: announced in master state, 255 for slave-only. The lowest number wins. If set to 13, announced time scale is always set to ARB. This setting controls the states a PTP port can be in. If below 128, port will only be in MASTER or PASSIVE states (master only). If above 127, port will be in MASTER or SLAVE states.
(6) Announce Interval: 1 (Specifies the announce message sending interval in seconds. The intervals use log base 2 values. If the PTP profile is IEEE 1588 version 2, the value range for the argument is 0 to 4. If the PTP profile is IEEE 802.1AS, the value range for the argument is 0 to 6.)
(7) Sync Interval: 0 (Specifies the Sync message sending interval in seconds. The intervals use log base 2 values. If the PTP profile is IEEE 802.1AS, the value range for the argument is -4 to 6. If the PTP profile is IEEE 1588 version 2, the value range for the argument is -1 to 1.)