ZED Link Quad: ZED X One captures ~40 ms after ZED X Mini despite hardware sync

tomas.spurny · September 28, 2026, 12:39pm

Hi everyone,

I run two ZED X Mini and two ZED X One UHD on one ZED Link Quad (Jetson AGX Orin), configured for synchronized acquisition exactly as in the (ZED Link Quad on AGX Orin | StereoLabs): sync_mode=1 plus a wire from J17 pin 13 to pin 16. The two Minis are perfectly synchronized with each other. The ZED X One pair, however, captures about 40 ms after the Minis, every frame. I’d like to know whether this is expected and how to get all four sensors to expose together.

Setup
- Jetson AGX Orin 64 GB devkit, L4T R36.5.0, MAXN
- ZED Link Quad driver 1.4.3-SL-MAX96712-L4T36.5.0, ZED SDK 5.4.0 (Python)
- Deserializer 9-0029: 2× ZED X Mini (port-index 4 and 6), HD1200 @ 15 FPS
- Deserializer 13-0029: 2× ZED X One UHD (port-index 0 and 2), HD4K @ 15 FPS, opened as one virtual stereo camera
- sync_mode=1 in zed_x_daemon.service, J17 pin 13 ↔ pin 16 wired
- Depth mode NEURAL on all stereo cameras

Measurements
1. A stopwatch filmed by all cameras A phone showing a millisecond stopwatch lay in the common field of view. I saved 25 sets of frames paired by nearest image timestamp. Both Minis always show the same time; the ZED X One always shows a later time:

Set	ZED X Mini (both)	ZED X One	Difference
0	31.700	31.750	+50 ms
1	32.851	32.876	+25 ms
3	35.026	35.076	+50 ms
4	36.175	36.200	+25 ms
5	37.251	37.276	+25 ms
6	38.301	38.401	+100 ms
7	39.501	39.551	+50 ms
8	40.576	40.625	+49 ms
9	41.701	41.731	+30 ms
…	…	…	…

The display updates in ~25 ms steps, so readings snap to +25 or +50 ms. 14 of 24 readings were +50 ms, which puts the true offset at ≈ 40 ms.

2. Image timestamps Each camera grabs continuously in its own thread. For every frame we read get_timestamp(TIME_REFERENCE.IMAGE) and TIME_REFERENCE.CURRENT. The offset is taken against the nearest ZED X Mini frame and wrapped to ±half a frame period (10 s window, 151 frames each):

Camera	Opened as	Offset vs ZED X Mini 50976178	p5–p95 spread	Frame period
ZED X Mini 53172763	`sl.Camera`	+0.02 ms	0.10 ms	66.66 ms
ZED X One pair	`sl.Camera`, virtual stereo	+17.29 ms	0.08 ms	66.66 ms
ZED X One 312338504	`sl.CameraOne`	+17.29 ms	0.08 ms	66.66 ms
ZED X One 317792740	`sl.CameraOne`	+17.29 ms	0.08 ms	66.66 ms

The frame periods are identical and the offset did not drift between measurements 5 hours apart, so the two groups are frequency-locked, but with a 17.29 ms phase offset. That is close to the 16.67 ms trigger pulse width that the GPIO triggering documentation lists for 15 FPS.

3. A moving object. We aligned the 3D trajectory of detected object moving through the common view across cameras. The Mini-vs-Mini control comes out at ≈ 0 ms. The ZED X One positions correspond to ~37 ms after the paired Mini frames, which agrees with the stopwatch.

What I checked
- The wire of J17 pin 13 ↔ pin 16 is active: I tried to remove it (sync_mode=1 unchanged) → no camera opens at all, the Minis included. With the wire back, everything works again.

- Boot log: Sync mode configured - Deser set as Slave appears only for `9-0029`; there is no sync line for `13-0029`.

- Ruled out: exposure (0.9 / 1.8 / 4.4 ms), rolling shutter (the lag doesn’t depend on the image row), depth stabilization (same at 0 and 30), and the virtual stereo (same result as a single `CameraOne`).

- The “timestamps are assigned upon driver receipt” note from the setup guide and (Why frames from different ZED X GMSL2 cameras connected to the same capture card have different timestamps? | Help Center | StereoLabs): I understand the stamps can differ between camera models even when capture is synchronized. But in that case the ZED X One image would show the stopwatch at the same time as the Minis. It shows ~40 ms later, so the exposure itself happens later, not only the delivery.

Questions
1. The (ZED Link Quad GPIO Triggering | StereoLabs) says the trigger’s rising edges mark the end of exposure, with a 16.67 ms pulse width at 15 FPS. Our stamp offset is 17.29 ms. Could the second deserializer act on the other edge, and can this be configured?

2. With sync_mode=1 and the pin 13–16 wire, should ZED X Mini and ZED X One UHD on different deserializers expose within 15 µs? Is the missing Sync mode configured line for 13-0029 expected?

3. What instant does a ZED X One UHD image timestamp represent, and why would its frames be exposed ~20 ms after that stamp while the ZED X Mini’s are not?

4. Is there a supported configuration where ZED X Mini and ZED X One UHD on one ZED Link Quad expose simultaneously at 15 FPS?

I am happy to share the raw data and measurement scripts if needed. Thanks!

Myzhar · September 30, 2026, 3:34pm

Hi @tomas.spurny,

thank you for the very detailed report and for the measurements; the stopwatch and moving object tests together with the timestamp analysis are exactly what we need to investigate this behavior.

Your hypothesis is plausible, given how close the measured offset is to the 16.67 ms pulse width at 15 FPS. There is no user setting to select the trigger edge; the only exposed parameter is sync_mode in zed_x_daemon.service (GPIO Triggering). I have forwarded your data to the driver team to verify how the ZED X One 4K sensor reacts to the sync pulse.

The missing line is expected: with sync_mode=1, 13-0029 stays master and generates the trigger, while 9-0029 is configured as slave and receives it through the pin 13 ↔ pin 16 wire; this is also why the slave cameras do not open when the wire is removed (Enable full onboard synchronization). The 15 µs precision refers to the alignment of the sync signals between the two deserializers; your measurements suggest that the two sensor models respond to the same sync edge with a different latency, and this is what we must clarify.

The image timestamp is assigned when the driver receives the frame, not at exposure time (Help Center article), so it also includes readout and transfer time, which differ between a 4K frame and an HD1200 frame. I agree with your analysis that the stopwatch test shows a real exposure offset and not only a delivery offset.

I will confirm this as soon as the investigation is complete. In the meantime, these tests would help us isolate the cause:

swap the connections, with the ZED X One 4K pair on the slave deserializer (9-0029) and the ZED X Mini on the master (13-0029), to check whether the offset follows the camera model or the master/slave role;
repeat the stopwatch test with the ZED X One 4K in HD1200 @ 15 FPS, to check whether the offset depends on the resolution mode;
share the full output of sudo dmesg | grep -i max96712.

Please also share the raw data and the measurement scripts; they will allow us to reproduce your setup with the same ZED Link Quad and ZED X One 4K configuration.

Finally, we released the ZED X Driver v1.4.4 and ZED SDK v5.5. Can you please upgrade both and verify if the problem persists?

tomas.spurny · October 1, 2026, 12:43pm

Hi @Myzhar,

thank you for the detailed answer, that clears up the sync roles.
There is a link to a .zip file with attachements (as a new user I cannot upload files directly )

News since the first post: we replaced both ZED X One 4K cameras for ZED X One 4K without lens (new serials 319792229 & 316666986 now with custom narrower lenses). The new pair shows exactly the same stamp offset: +17.32 ms vs the ZED X Minis, jitter < 0.1 ms, a single regime over a 10-minute run. So it is not specific to one unit.

Test 1 - Swap the deserializers ZED X One 4K pair now on 9-0029 (slave, port-index 4 / 6), ZED X Mini on 13-0029 (master, port-index 0 / 1); dmesg attached. The stamp offset does not move: +17.29 ms at HD4K and +17.03 ms at HD1200 (before the swap +17.32 / +17.07 ms), Minis at 0.00 ms. So the stamp offset follows the camera model, not the master/slave role.

Test 2 - Stopwatch in the swapped layout (same phone stopwatch, 25 sets each, display steps 25 ms; readings in data/clock_pairs_20261001_*_swapped_*/readings.csv, images included). The two Minis show the same time in every set. The ZED X One still shows a later time:

ZED X One mode	readings (ZED X One − Mini)	mean offset
HD4K	11× +25ms, 9× +50ms, 1x 0ms, 1x +100, 3x N/A	≈ 36–38 ms
HD1200	1 × +24 ms, 21 × +25 ms, 1x 0ms, 1x +125ms 1x N/A	≈ 25–28 ms

Test 2 - Timestamps only: with the ZED X Ones opened in HD1200 @ 15 FPS instead of HD4K, the stamp offset goes from +17.32 to +17.07 ms, the same whether they are opened as virtual stereo or as two CameraOne; the Minis stay at 0.00 ms. A 4K frame has 3.6× the pixels of an HD1200 frame, yet the stamp offset changes by only 0.25 ms. Unless the sensor readout takes the same time in both modes, readout/transfer time does not explain the 17 ms in the stamps. The stopwatch results in `HD1200` are below.

So the exposure offset follows the ZED X One, not the master/slave role. It also depends on the resolution mode: about 12 ms smaller in HD1200, which on this camera is a central crop of the sensor (about 1200 rows read instead of 2160), while the timestamps move only 0.25 ms. That looks like an exposure timing tied to the sensor readout length, which the timestamps do not reflect.

Same tests after swapping back (ZED X One on 13-0029 master again, same pair, same phone, dmesg attached):

ZED X One mode	layout	stamp offset	stopwatch offset (mean of ~22 readings)
HD4K	One on master (original)	+17.32 ms	36.7 ms
HD4K	One on slave (swapped)	+17.29 ms	34.5–37.5 ms
HD1200	One on master (original)	+17.07 ms	19.6 ms
HD1200	One on slave (swapped)	+17.03 ms	23.9–28.1 ms

Test 3: sudo dmesg | grep -i max96712 is in the attached archive (data/dmesg_max96712.txt).

Raw data and scripts: attached. measure_camera_timestamps.py (stamp offsets, no motion needed) and capture_clock_pairs.py (the stopwatch test) run standalone with pyzed; the serial numbers are in scripts/config/camera_config.py, and both accept --one-resolution. The stopwatch data from the first post (old ZED X One pair) has all 25 image sets, the image stamps and our readings. The moving-object measurement runs inside our detection pipeline, so it is not included. The README in the archive lists every file.

(Ranges: with and without single outlier readings; each value is about ±2–3 ms given the 25 ms display steps.)

Summary: in both layouts the ZED X One 4K exposes ~36 ms after the ZED X Mini in `HD4K` and ~20–25 ms after in HD1200, while its image timestamps say +17.3 / +17.1 ms. The offset follows the camera model and changes with the resolution mode; the timestamps track neither the size of the offset nor its change with resolution. Is there a way to have the ZED X One 4K expose on the same sync edge as the ZED X Mini, or at least a documented, fixed latency per resolution mode that we could correct for?

I did not yet upgraded to Driver 1.4.4 / SDK 5.5: I will report back after upgrade.

Thanks!

tomas.spurny · October 14, 2026, 2:06pm

Hi @Myzhar ,
Sorry for long delay. I tried to update ZED SDK and ZED X Driver, but it still gives same result.

Myzhar · October 16, 2026, 7:43am

Hi @tomas.spurny,

thank you for the new round of tests.

Your tests are very useful: the offset follows the camera model, not the deserializer role, and it scales with the resolution mode. This matches the main hardware difference between the two cameras. The ZED X Mini uses a global shutter sensor, where the whole frame is exposed at once and the sync edge marks the end of exposure. The ZED X One 4K uses a rolling shutter sensor, where the frame sequence starts on the sync edge and the exposure timing depends on the row readout, which is longer in HD4K than in HD1200.

There is currently no user parameter to move the ZED X One 4K exposure relative to the sync edge. The driver team is now characterizing the exact delay for each resolution mode, and checking whether it can be compensated in the driver or in the timestamp. I will report the result here, including a per-mode latency value if a driver fix is not possible.

The near-constant +17 ms stamp offset across resolutions, while the exposure offset changes, also confirms your analysis: the image timestamp does not represent the exposure instant for this sensor. We are verifying which frame event it is tied to.

If your application needs exposure alignment with the ZED X Mini today, and does not strictly require 4K resolution, the ZED X One GS uses a 2.3 MP global shutter sensor like the ZED X Mini, with the same sync behavior, and supports multiple S-mount lens options for your custom narrow-FOV setup.

Best regards,
Walter

tomas.spurny · October 16, 2026, 9:12am

Hi @Myzhar,

Thank you for explanation. The global vs rolling shutter difference makes sense of everything we measured.

Thanks also for suggesting the ZED X One GS. Unfortunately we need the 4K resolution in our application. For now we correct for the offset in software and will keep doing so.

I’m looking forward to the per-mode delay values, or the driver fix if it’s possible. If the fix changes what the image timestamp represents, could you mention it in the release notes? Our correction is based on the current timestamps, so we would need to re-measure.

Thanks and have a nice weekend!

Best regards,
Tomas