Improved image timestamp accuracy on GMSL cameras (ZED X / ZED X One families): the frame timestamp is now captured in hardware instead of sampled in software, reducing timestamp jitter by ~10× and making it immune to CPU load. Enabled by default; set ZED_SDK_DISABLE_HW_TSC_SOF=1 to restore the previous software-sampled timestamps.
First of all, this is great news!
would it be possible to have a more in depth description of the changes and differences between the old and new timestamping mechanisms?
is a minimum version for the GMSL2 driver required?
Hi @beniaminopozzan
thank you, I am glad the change is useful for your pipeline.
would it be possible to have a more in depth description of the changes and differences between the old and new timestamping mechanisms?
What changed is where and when the timestamp is sampled, not the clock domain it is expressed in.
Old behavior (software sampling): the SDK capture thread read the selected clock at the moment the frame buffer was handed over to user space. That value therefore included the whole capture and delivery latency of the pipeline, plus the scheduling jitter of the capture thread itself; under heavy CPU load, thread wake-up delays translated directly into timestamp jitter.
New behavior (hardware Start of Frame): the SDK now uses the Start of Frame timestamp latched by the Tegra capture hardware (TSC counter) and propagated with the frame metadata by the GMSL2 driver, then converted into the active TIMESTAMP_CLOCK domain. The value is generated by hardware at the beginning of the frame, so it no longer depends on when the buffer reaches the application; this is where the ~10x jitter reduction and the immunity to CPU load come from.
Practical consequences worth checking in your application:
the absolute values are now earlier than before, and the residual offset with respect to the real acquisition instant is nearly constant; if you were compensating the old delay with a fixed offset, that offset must be re-tuned or removed;
inter-camera consistency improves in multi-camera rigs, because all the ports of the same capture card share the same hardware counter; this benefits Fusion and the association with external sensors (LiDAR, GNSS, robot IMU);
the clock selector is orthogonal to this change: SYSTEM_CLOCK is still the default. If you correlate the image timestamps with a free-running hardware counter, or with a device that is not time-disciplined by the host, consider sl::TIMESTAMP_CLOCK::MONOTONIC_RAW_CLOCK, introduced in v5.4: ZED SDK 5.4 - Download | Stereolabs
ZED_SDK_DISABLE_HW_TSC_SOF=1 restores exactly the previous software-sampled behavior, which makes an A/B comparison on your own setup easy.
is a minimum version for the GMSL2 driver required?