Hello, I’ve been investigating how to ensure time alignment between a network capable PTP synchronized lidar unit with an Orin device connected to GMSL cameras.
This post suggests that all cameras are triggered via the same PWM signal, and thus should be captured at the same time:
I was wondering if the PWM signal has consistent time alignment with respect to the system’s PTP synchronized clock, or if the PWM signal drifts with respect to the PTP synchronized system clock.
If the PWM signal is tied to the PTP synced clock, does the trigger occur in phase with the change in seconds?
For example, imagine a camera capturing images at 10Hz. is the behaviour detailed below roughly in line with what we would expect to see regarding the captured image timestamps w.r.t the capture indices?
Dear @ssimpson1,
with lidar.socket sensor, please use sensor parameter disable-kernel-timestamping=true to use host/ptp timestamp. otherwise, kernel timestamp is used as default for host timestamp. In general, if system is ptp synced, all the sensors can be configured to use ptp time
Thank you for the info, quoting from the linked document:
Orin SOC provides a hardware assisted mechanism to align/sync the TSC (clock/counter) with one of the Tegra SOC Ethernet MAC on second boundary using the PPS signal from the MAC. This feature is useful in synchronizing camera fsync signals (used for camera frame capture/timestamping) with PTP time in order to reduce the timestamp jitter between sensors timestamped with PTP domain
Does anything need to be specified to ensure that the camera fsync trigger signals are PTP synchronized (ie: the fsync would operate at some multiple of the PPS signal in consistent phase) or is this default behaviour?
On my system there is a PTP synchronized GPS device, that elects itself as the best PTP master clock when it has GPS signal, however when the GPS signal is lost (ie: indoors) it enters a freerunning clock mode and no longer acts as the best time source, and the time source changes to another host’s clock.
Dear @ssimpson1,
This is unusual use case. Generally, switching the PTP master during the sync could cause a potential time jump (depending on the clock offset between the old and new master).
If the Slaves are sensitive of any time jump, it’s better to fix the Master and Slave role on each node.