ZED SDK 5.4.1 — two ZED X Mini on GMSL: one camera's IMU drops to ~0.6 Hz while the kernel driver delivers ~206 Hz for both

ShashankVSS · September 16, 2026, 5:50pm

Hi,

We’re testing two ZED X Mini cameras simultaneously on a Jetson Orin NX with a Connect Tech Hadron-GMSL carrier, using ZED SDK 5.4.1 and ZED X driver 1.4.3.

We’ve found an issue where both cameras work correctly individually, with each delivering approximately 200 Hz of distinct IMU samples. However, when both cameras are running simultaneously, one continues at approximately 200 Hz while the other drops to around 0.3–2.3 Hz. Video from both cameras remains completely unaffected.

We’ve tested different resolutions and frame rates, with and without image retrieval and SVO recording, reversed the camera open order, and physically swapped the cameras between GMSL ports. The issue does not follow the physical camera or open order. We also reproduced the same behavior using the sl::Sensors API, so it does not appear specific to our sl::Camera acquisition implementation.

The most interesting result is from comparing the Stereolabs kernel driver counters against what the ZED SDK delivers during the same dual-camera run. bmi_spsc reports approximately 206 Hz and 209 Hz for the two IMUs, with zero I2C errors and both ring buffers fully drained. At the application level, however, we measured approximately 0.6 Hz and 200.6 Hz of distinct IMU samples.

Across all of our dual-camera configurations, the combined application-visible IMU rate remains almost exactly 201 Hz, despite the kernel acquiring approximately 415 Hz in total. getSensorsDataBatch() also returns SUCCESS with an empty vector on 98.8% of calls for the starved camera rather than reporting an error.

Based on these measurements, the sample loss appears to occur somewhere in the Stereolabs userspace/ZED SDK path between the working kernel acquisition layer and the public API. We don’t have visibility into the SDK internals, so we haven’t tried to attribute it to a specific component. GMSL port 0 and SDK device index 0 also remain confounded in our setup.

Is this a known issue with multi-camera IMU acquisition in ZED SDK 5.4.1? Is there a newer SDK build or patch we should test, or a supported method for receiving the full ~200 Hz IMU stream from both cameras simultaneously?

I’ve attached a detailed engineering report containing the full test matrix, kernel counters, reproduction procedure, environment details, and additional measurements. We can also provide the diagnostic application and raw test data if useful.

STEREOLABS_IMU_STARVATION_ESCALATION.md (22.9 KB)

Thanks!

Myzhar · September 17, 2026, 1:45pm

Hi @ShashankVSS
I recommend you contact ConnectTech to report this problem because I suspect it’s an issue with the driver and they developed it to use our cameras with our devices.

ShashankVSS · September 17, 2026, 2:08pm

Hi Myzhar,

Thanks for the response. We already have an open case with Connect Tech and will send them these results as well.

One reason we suspected the SDK/userspace path rather than the kernel acquisition layer is that the bmi_spsc counters continue to show approximately 206 Hz and 209 Hz simultaneously during the affected dual-camera run, with zero I2C errors, while the SDK exposes approximately 0.6 Hz and 200.6 Hz during that same interval.

We’ve also done some additional SDK version testing since making this post. On the same hardware:

SDK 5.1.2: ~190.5 Hz + ~185.2 Hz application-visible IMU rate
SDK 5.2.3: ~0.7 Hz + ~199.0 Hz
SDK 5.4.1: ~0.5–2 Hz + ~200 Hz

So the severe asymmetry and ~200 Hz aggregate application-visible ceiling appear between 5.1.2 and 5.2.3 in our testing.

Does that change your assessment of where the issue may be occurring? In particular, were there changes to the multi-camera sensor/IMU userspace path between SDK 5.1.2 and 5.2.3 that could explain this behavior?

I’m happy to provide the diagnostic logs if useful.

Myzhar · September 17, 2026, 5:04pm

Hi @ShashankVSS
Thank you for the details.

This changed my mind because this is not expected.

I will try to replicate this behavior on a Jetson devkit and I will eventually forward all the details to the ZED SDK team in case it’s a validated bug.

Do you have a code snippet to use to replicate the issue?

ShashankVSS · September 17, 2026, 6:32pm

Absolutely. I’ve packaged the reproducer into a small standalone diagnostic application. It opens both cameras concurrently, measures the distinct SDK-visible IMU delivery rate for each camera, and records the relevant video/timestamp/sensor statistics.

The basic reproduction is:

./build.sh

sudo ./zed_x_diag --qualify

It runs for 60 seconds by default and produces a timestamped evidence bundle containing a human-readable summary, JSON, per-sample CSV, and system information.

I’ve also included the quantitative investigation report with the 5.1.2 / 5.2.3 / 5.4.1 results.

I’m sending the same reproducer to Connect Tech so both teams can test against the same workload and measurements.

zed_x_diag.zip (67.0 KB)

Myzhar · September 18, 2026, 3:44pm

Hi @ShashankVSS
Thank you for the code.

We will analyze this problem next week and we will keep you posted with the results as soon as we have something important to share.

Myzhar · September 29, 2026, 1:52pm

Hi @ShashankVSS
can you please run this script and send us the output?

i2c_bus_freq.sh (930 Bytes)

We tried to replicate the problem with our boards, and standard Jetson devkits, but we could not; so we suspect that it’s caused by an I²C setting in the BSP of the ConnectTech board.

ShashankVSS · September 30, 2026, 1:42pm

Hi @Myzhar ,

I’ve run the script with sudo and here is the output:

i2c-0 i2c@3160000 400000 3160000.i2c
i2c-1 i2c@c240000 100000 c240000.i2c
i2c-2 i2c@3180000 400000 3180000.i2c
i2c-5 i2c@31b0000 100000 31b0000.i2c
i2c-7 i2c@c250000 400000 c250000.i2c

Myzhar · September 30, 2026, 7:24pm

Hi @ShashankVSS
this is interesting.

Can you also share the output of the command sudo ZED_Diagnotic --dmesg.
It allows us to check the I2C bus mapping.

ShashankVSS · October 1, 2026, 4:09pm

@Myzhar I’ve attached the resulting log file to this comment.

dmesg.log (11.3 KB)

Myzhar · October 5, 2026, 8:33am

Hi @ShashankVSS
Thank you for sharing the diagnostic output.

The I2C bus frequency is correctly set to 400 kHz, but the IMU addresses reported in the log (0x18, 0x19, 0x68, 0x69) look unusual. With the StereoLabs driver configuration, the IMU addresses are normally translated to 0x3c, 0x3b, 0x4c, 0x4b, so that each camera has unique addresses on the bus.

If the address translation is applied to only one of the two cameras, the two IMUs will conflict on the bus. This would explain why the kernel counters look healthy while the SDK receives data for only one camera.

To confirm this, can you please run the following test:

Open both cameras at the same time with ZED Sensor Viewer.
Move only the first camera and check which camera’s IMU data changes.
Move only the second camera and check again.

Please let us know if the IMU data of one camera appears on the other camera, or if the data are mixed up between the two.

Can you also ask Connect Tech for the device tree used in their BSP for the Hadron-GMSL carrier and share it with us? It will allow us to verify how the IMU address translation is configured for each GMSL port.

ShashankVSS · October 6, 2026, 1:54pm

Hi @Myzhar,

I followed up with Connect Tech regarding the IMU address translation.

They confirmed that their current device tree is using the default BMI088 addresses you identified (0x18, 0x19, 0x68, and 0x69). They also noted that if the IMUs need to be translated to unique addresses as you described, they should be able to provide us with an updated DTB.

I’ve attached the current Connect Tech DTB for our Orin NX / Hadron-GMSL configuration:

tegra234-orin-nx-cti-NGX018-SL-ZEDX.dtb (255.4 KB)

I also decompiled it and confirmed that the two BMI088 nodes are configured as:

bmi088_a@69:
    reg = <0x69>
    accel_i2c_addr = <0x19>
    phandle = <0xf4>

bmi088_a@68:
    reg = <0x68>
    accel_i2c_addr = <0x18>
    phandle = <0xf5>

Both ZED X serializer nodes reference those same IMU phandles:

zedx_ser_0@40:
    zedx-id = "0"
    imu = <0xf4 0xf5>

zedx_ser_1@42:
    zedx-id = "1"
    imu = <0xf4 0xf5>

Could you take a look and confirm whether the DTB should instead be configuring the translated addresses (0x3c, 0x3b, 0x4c, and 0x4b) for our dual-camera configuration? If so, I can have Connect Tech provide us with an updated DTB.

Thanks,
Shashank

Myzhar · October 7, 2026, 12:19pm

Hi @ShashankVSS
Thank you for following up with Connect Tech and for sharing the decompiled DTB.

Yes, please ask Connect Tech for an updated DTB.

The current configuration confirms the root cause: both zedx_ser_0@40 and zedx_ser_1@42 reference the same two BMI088 nodes (0xf4 and 0xf5) at the default addresses (0x18/0x68 and 0x19/0x69). In a dual-camera setup, the two IMUs therefore share the same addresses on the deserializer I2C bus, so the readings collide and only one camera’s IMU data reaches the ZED SDK reliably, even if the kernel counters look healthy.

In the updated DTB, each serializer node must reference its own dedicated BMI088 nodes, with the serializer I2C address translation enabled, so that each IMU (accelerometer and gyroscope) is exposed at unique translated addresses (0x3b, 0x3c, 0x4b, 0x4c) instead of the default ones.

Once you receive the new DTB, please run your zed_x_diag test again and let us know the results; both cameras should deliver about 200 Hz of IMU data simultaneously.

Best regards,
Walter

ShashankVSS · October 7, 2026, 4:38pm

Hi @Myzhar,

Connect Tech provided us with the updated DTB implementing the I2C address translation, and I tested it today with both ZED X Mini cameras connected simultaneously.

The issue is resolved. Both cameras opened successfully and streamed IMU data concurrently for the full 30-second diagnostic:

Camera 1: 6,029 IMU samples, measured at 200.9 Hz
Camera 2: 6,007 IMU samples, measured at 200.2 Hz
Both cameras maintained ~60 FPS with no grab failures
Both SVO2 recordings completed successfully and were verified on playback

We did observe a small number of non-monotonic IMU timestamps (7 and 6 respectively out of ~6,000 samples), but this does not appear related to the original issue. Both IMUs are now providing valid data simultaneously at the expected ~200 Hz rate.

Thanks for helping identify the root cause. We can consider the original dual-camera IMU issue resolved.

Best regards,
Shashank

Myzhar · October 7, 2026, 5:54pm

This is great news!!! I’m glad they solved the problem so quickly, they confirmed to be a reliable partner.

Do you have more information concerning this?

ShashankVSS · October 7, 2026, 8:10pm

Hi,

Yes. During the 30-second zed_x_diag run, we received 6,029 IMU samples from one camera and 6,007 from the other. The diagnostic detected 7 and 6 non-monotonic timestamps respectively. There were no IMU API errors, NaNs/Infs, or sensor railing, and both IMUs otherwise maintained approximately 200 Hz throughout the test.

I also mentioned this to Connect Tech. Their engineer suggested that, if the SDK timestamps IMU packets using the host system’s wall clock (CLOCK_REALTIME) rather than a monotonic clock, NTP adjustments on the Jetson could potentially account for occasional backwards timestamps. They emphasized that this was only speculation since the SDK implementation is closed source.

Do you know which clock source getSensorsDataBatch() uses for the IMU timestamps, and whether occasional non-monotonic timestamps are expected?

Best regards,
Shashank