Ouster sensor can reach a good PTP sync state (master_offset < |250000| & port_state = SLAVE) but a few minutes later it goes back to port_state = UNCALIBRATED with the master_offset value hanging.
Remedy
Ensure your network switches are PTP compatible. Look for things in the switch specs with wording like 1588v2, 802.1as, IEEE 1588-2008, IEEE 1588-2019.
“Although considered a transitory state, a PTP port can remain “Uncalibrated”. This
indicates that the downstream time transfer is not functioning properly. This could
mean either that Delay_Request messages are not forwarded correctly to the Master
or not processed by it. Another reason could be that Delay_Response messages are
either not transmitted by the Master or it is using an incorrect transport protocol.
These messages could get dropped on their way from the Master to the Slave,
however this is unlikely to happen and easy to detect using standard network
monitoring tools. This may occur due to the Time to Live (TTL) of the IP encapsulated
PTP packets causing them to be dropped before reaching their final destination.”
I’m running into a similar problem where the ouster can find the grandmaster but never gets out of theUNCALIBRATED port state. Looking at ethtool -T eno1 I see:
Time stamping parameters for eno1:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
so I believe my ethernet port is capable of being the grandmaster. I’m using the same ptp4l.conf that works with other robots so the ptp configuration should be correct. I’m following the steps outlined here. Our ouster is an OS1 and our base operating system is ubuntu 24.04. If you have any insights into why this is happening that would be greatly appreciated.
Would you be able to confirm your firewall settings to permit UDP traffic on 319 and 320? If possible capture the PTP packets with tcpdump $ sudo tcpdump -i dst port 319 or dst port 320 [-w <filename.pcap>]
Also confirm the ptp4l.conf details as to whether it is set up for default or gptp.
I am working an issue now where the default profile only works with the firewall turned off.
Thank you for your feedback. ufw status verbose shows inactive so no firewall is running. With sudo tcpdump -i eno1 port 320 I see.
IP phobos.ptp-general > ptp-primary.mcast.net.ptp-general: PTPv18
and with a tcpdump on port 319 I see
IP 192.168.100.12.ptp-event > ptp-primary.mcast.net.ptp-event: PTPv2, v1 compat : no, msg type : delay req msg, length : 44, domain : 0, reserved1 : 0, Flags [none], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xbc0fa7fffe0009dd, port id : 1, seq id : 3027, control : 1 (Delay_Req), log message interval : 127, originTimeStamp : 0 seconds, 0 nanoseconds
If I run sudo tcpdump -i eno1 dst 192.168.100.12 and port 319 where 192.168.100.12 is the IP of my lidar, I get nothing.
My ptpt4l.conf is setup for default, but on Ubuntu 24.04 some of the parameters are have different names. I’m not sure if this could be causing the issue.
Update: I was able to resolve the issue by running an older version of ptp4l in a docker container. It seems there is some sore of incompatibility with ptp4l v4.0 which is the only version that can be installed on Ubuntu 24.04.