Configure your Ouster Sensor to use gPTP(802.1AS-2011)

Owned by Michael Swisher (Deactivated), created
Last updated: Apr 07, 2023
4 min read

This is guide touches on some of finer configuration settings needed to properly configure Ouster Sensors with gPTP

Requirements

System Requirements:

  1. One Ouster Sensor

  2. One linux machine with hardware timestamping

    1. sudo ethtool T <interface name>
    2. Example of a PTP compatible ethernet interface

  3. linuxptp(https://github.com/richardcochran/linuxptp)

    1. ptp4l

    2. phc2sys

    3. pmc(optional but extremely helpful!)

Differences between default and gPTP

gPTP is a more stringent than the default configuration. Ouster sensors are running linuxptp under the hood, and the profiles available are taken from the linuxptp repository.Here are some of the important client setting in the default profiled outlined in our firmware user manual:

  1. Transport: UDP

  2. IPv4 Delay Mechanism: E2E

  3. Sync Mode: Two-Step Announce Interval: 1 - sent every 2 seconds

  4. Sync Interval: 0 - sent every 1 second

  5. Delay Request Interval: 0 - sent every 1 second

Reminder that all of the linux command line utilities used in this guide have extensive man pages. The above settings are detailed more extensively in man pages.

Each profile is a set of difference between that profile and the default profile. For gPTP it looks like the following:

[global] gmCapable 1 priority1 248 priority2 248 logAnnounceInterval 0 logSyncInterval -3 syncReceiptTimeout 3 neighborPropDelayThresh 800 min_neighbor_prop_delay -20000000 assume_two_step 1 path_trace_enabled 1 follow_up_info 1 transportSpecific 0x1 ptp_dst_mac 01:80:C2:00:00:0E network_transport L2 delay_mechanism P2P

The most important settings here are delay_mechanism, network_transport, neighborPropDelayThresh and transportSpecific.

delay_mechanism is the one that users get tripped up on the most. This profile is P2P or peer to peer. That means that the device the sensor is connected to must also be gPTP compatible. If you are directly connecting to a machine running gPTP as the linuxptp profile, you should have no problem. However, if you have an intermediate switch that isn’t gPTP compliant, the protocol will not work. This is a common issue our customers run into, and if this is the case, you should consider an E2E or end to end solution.

A gPTP time aware bridged network contains two classes of components:

  1. time-aware endpoints, one of which is the grandmaster (the source of time information)

    1. Ouster sensors and gPTP compatible ethernet hosts

  2. time-aware bridges, which receive time information from the grandmaster (perhaps indirectly through other time-aware bridges), apply corrections to compensate for delays in the LAN and the bridge itself, and retransmit the corrected information

Configuring your sensor

  1. Configure your sensor’s TIMESTAMP_MODE to TIME_FROM_PTP1588

  2. Change the ptp profile your sensor is using by issuing the following curl request

    curl --request PUT -H “Content-Type: application/json” <Sensor IP address>/api/v1/system/time/ptp/profile -d ‘“gptp”’

Starting your services

We recommend you use systemd services to run ptp4l and phc2sys on your host machine.

You can start by running:

Edit the ptp4l override file with the following contents:

where /etc/linuxptp/gPTP.cfg is the path to your version of gPTP configuration file. It is a common practice to keep your configuration files in that directory.

Edit phc2sys override ride file with the following contents:

I find that I often need to restart my ptp and phc2sys services quite often to accommodate changes, so I include the following shell function in my .zshrc to speed up development:

Verification

A properly synchronized sensor should output something like this.

Ouster REV-07 sensors have an improved chip and can get lower offset_from_master than their older counterparts. Older models will oscillate between 250000 and -250000

The following items should be noted:

  1. “port_state”: “SLAVE”

  2. "gm_identity": "0001f2.fffe.00ee36" should be set and “gm_present”: true. Note a bridged network should have a different grand master than a directly connected host.

  3. “profile”: “gptp”