PTP Struggles and Solutions after Migrating to Rev7 Sensors

Hardware
,
1

I post this only for others who might stumble upon similar problems.
With the great help of the Ouster Support we where able to figure out all issues during the migration process.

But as it was far from Plug and Play as I had hoped for - just unplug old OSx , plug in new OSx and go - I report here our findings.

Thanks again to the Ouster support!

HW Setup:

  • Novatel PwrPak7 as GM Clock → ETH enp5s0
  • CLOCK_REALTIME is synched via chrony SHM to this port
  • phc2sys syncs all other ETH ports to CLOCK_REALTIME
  • at enp3s0s0 a automotive grade switch (hw ptp enabled) is connected
  • three Ouster LiDAR are connected to this switch (OS0, OS1, OS2)

PTP Setup with Rev5+Rev6 Sensors

  • Ubuntu 20.04
  • linuxptp v3.1.1 installed via apt
  • OS0, OS1, OS2 with FW 2.5.3
  • ptp_profile default-relaxed
  • IP of Sensors as static_ip: 169.254.xxx.xxx

Results

All sensors would converge to port_state==SLAVE stable. master_offset was within spec <250.000ns

PTP Setup with Rev7 Sensors

We then updated to newer Rev7 sensors to gain from the better performance.

Setup Number 1:

  • Ubuntu 20.04
  • linuxptp v3.1.1 installed via apt
  • OS0, OS1 with FW 3.1.0
  • OS2 with FW 2.5.3
  • ptp_profile default-relaxed
  • IP of Sensors as static_ip: 169.254.xxx.xxx

Issues

Only the OS2 would sync into SLAVE. OS0 and OS1 would stay UNCALIBRATED

Solution

With FW 3.1.x it is no longer ok to set the static_ip to the link_local range - 169.254.xxx.xxx although data etc came through, PTP did not like it.

So I reconfigured the IP into 192.168.xxx.xxx range and it worked.

Setup Number 2:

  • Ubuntu 24.04
  • linuxptp v4.0 installed via apt
  • OS0, OS1 with FW 3.1.0
  • OS2 with FW 2.5.3
  • ptp_profile default-relaxed
  • IP of Sensors as static_ip: 192.168.xxx.xxx

Updated host system as I continue working with ROS2 now.

Issues

  • All three Ousters would report port_state==SLAVE. But only OS0 and OS1 are within spec master_offset < 1000ns (FW3.1)

  • OS2 master_offset was > 300.000.000ns so 300ms and more.

  • Also OS2 would not accept phase_lock and reported this Warning:

    0x01000050 MOTOR_CONTROL
Warning
The phase lock offset error has exceeded the threshold. Check that the time source is accurate and the reduce the movement of the sensor including mechanical movement, shock, or vibration.

Solution

Motivated from Issue 99 I uninstalled linuxptp and build it from source with version 3.1.1

Which did in fact solve the issue.
So unfortunately it is not possible to use the Ubuntu 24.04 default linuxptp package but one has to build the old version. At least for FW 2.5.3. FW 3.1.0 is fine with

With this:

  • OS0 + OS1 have a master_offset < 1000ns
  • OS2 has a master_offset < 250.000ns
2 Likes
2

Great post, thank you! The complexity you experienced is the result of REV7 OS2’s still running on a firmware 2.X while all other REV7 sensors transitioned to firmware 3.X.

1 Like