Advice and clarifications regarding best practices for multiple ZED issues

Software
1

Hello Stereolabs Team,

I am writing to you in order to obtain advice and clarifications regarding best practices for multiple issues.

Context: We have 5+ ZED Box Orin NX 16gb (with ZED X cameras); 2 of them had just returned from warranty and the state appears as new (we didn’t note the old serials in order to compare them but this is probably not relevant); The image and version they come with is different from the latest flash image found in your docs: 36.4.4 vs 36.4.3;

I want to know if it’s a good idea to make a flash backup of the factory image since it is 36.4.4 and the L4T have correct priorities set and it’s upgrade safe, but I’ve also encountered the following issues and have specific questions as well:

  1. NEW ZED Boxes (36.4.4): ZED_Diagnostic reports that I have both SDK and GMSL driver installed but there’s no camera being detected, even after zed_x_daemon and nvargus restart + reboot (even tried all 4 camera cable splits); (No SDK / driver reinstall was done so far - wanted to clarify first what’s the actual issue, if any); The attached ZED_Diagnostic data is from here.

  2. Why does the official post flash procedure recommend apt upgrade (without any hold or priority set) when from my experience this breaks the system by upgrading to 36.4.7 - which is not supported! What’s the correct procedure to have a stable system and installation starting from a flash?

  3. See attached screenshot - it just happened after a reboot command on a new ZED Box - so far I’ve only installed epiphany-browser and anydesk!

  4. After flashing a ZED Box (with JetPack 6.2 and 36.4), I’m unable to use the WIFI and fixing it took long enough that I gave up trying and just used the wireless from my attached MikroTik - but the factory 36.4.4 image comes with a working WIFI. (I tried the usual recommended WIFI fixes after flashing but without success)

  5. One of the ZED Boxes (same version as others) has a non working reboot! Each reboot = shutdown; it’s not a first generation ZED Box - it doesn’t get fixed by flashing and the issue did not replicate on other ZED Boxes - any idea what’s the issue and how to fix it? (I even tried to flash the QSPI but the reboot was not fixed)

Thank you for your attention and we hope to solve and clarify all of the above!

All the best!

2

Hi @MichaelBox

You could try, but no one ever succeeded in restoring the backup image.

Please try to install the latest ZED X Driver v1.3.2 and the latest ZED SDK v5.1.1, then share the new diagnostic report (with sudo).

Because the ZED X Driver v1.3.2 fixed this issue.

One of the two packages that you installed broke the file system.
I recommend using NoMachine instead of Anydesk, we have no issues with it.

This is not expected. Are you using the latest version of the flash scripts from our documentation?

3

Hello,

Should I always run: “sudo apt update” + “sudo apt upgrade -y” right after flashing, before “sudo apt install nvidia-jetpack”? No need to lock packages or set priorities in any way? Why would I even keep Ubuntu Software Updater? We need a stable working environment that won’t brick itself at the next upgrade.

Please advice on the best and full correct flash + post flash procedure in order to run the latest stable, recommended versions. After reaching this step and having everything installed with the latest correct versions, is it recommended and possible to create a flash image in order to use it directly?

Regarding the reinstalling of the SDK and drivers on the factory images:
Even if the name of the pkg did autocomplete on TAB, there was an error when trying to uninstall it and reinstalling the SDK + driver did not fix anything; there’s also a bug with the nvargus service install - after each reinstall it triplicates a line in the service.

I have attached the relevant files.

Thank you!

(Again I have no other choice but to upload the media this way: Download STEREOLABS-Screenshot 2025-11-26 141419.png | LimeWire )

* P.S. Please advice regarding this issue as well as it happens randomly and reconnecting the camera is not a viable option - even more - it happened on the ZED Box that doesn’t have a working reboot so I can’t do much but restart services.. Download STEREOLABS-Screenshot 2025-11-26 145440.png | LimeWire

EDIT: The other returned ZED Box has ZED SDK 5.1 and the ZED X camera is working without any issues! One notable difference is a script on Desktop called - sdk_installer.run; Why are they different and should the working one be kept like this without flashing it?

4

Yes, this is required.

No, this is not required with the ZED X Driver v1.3.2.

This is not happening anymore with ZED X Driver v1.3.2… unless NVIDIA changes something we are not aware of.

The documentation contains the right procedure to follow.

You can create a backup copy, but it’s not possible to safely restore it. Unless you find a solution that no one has yet found.

What version of the driver?

5

Hi Myzhar,

Following up on the ZED Box with capture card issues (serial E17SO3J0, L4T 36.4.4).

Update on troubleshooting:
As you recommended, I installed driver v1.3.2 and SDK v5.1.1. Unfortunately, the issue persists because this is a hardware failure, not a software issue.

The diagnostic from Nov 25 (attached in my first post) already showed the root cause:

pca954x 2-0070: probe failed

The I2C multiplexer (PCA9546) on the capture card does not respond. I2C bus 2 scan shows no devices at all - the capture card is non-functional.

Even when reinstalling the driver, the setup correctly detects the configuration:

Detected DTB to update : tegra234-p3768
Detected capture card : zedbox-duo

Yet ZED_Diagnostic still reports “Capture card is not plugged or wrong driver installed” - because the hardware doesn’t respond, not because of driver/software issues.

I’ve attached a detailed technical report (CAPTURE_CARD_HARDWARE_FAILURE.md) confirming this.

CAPTURE_CARD_HARDWARE_FAILURE.md (7.3 KB)

Key facts:

  • i2cget -y 2 0x70 returns “Read failed” (on working ZED Box it returns “Device busy”)
  • I2C bus 2 scan shows all -- (no devices), while working unit shows devices at 0x20, 0x28, 0x29, 0x62, 0x70
  • Device tree overlay is correctly applied, driver is installed, kernel modules are loaded
  • This is a replacement unit - the second defective device we’ve received

No software update can fix hardware that doesn’t respond. We request a replacement unit shipped as soon as possible.

Note on the previous boot error:
Regarding the earlier boot screenshot showing the EFI partition timeout - this was unrelated to Anydesk or Epiphany. Both packages are still installed, yet the system boots and mounts the EFI partition fine now. A software package cannot “break the filesystem” and then have it fix itself while the package remains installed. It was simply a transient boot timing issue.

Additional request - factory flash procedure:
Could you provide the complete factory flash procedure and the L4T 36.4.4 image you use?

You mentioned that backup restoration hasn’t been successful for anyone. If only your factory flash produces working units, then users need access to that same procedure - otherwise we’re dependent on Stereolabs for every reflash, which isn’t practical for managing a fleet.

The public documentation at /docs/embedded/zed-box-orin/reset-update only covers the basic flash steps, but factory units clearly go through a more complete setup. Looking at the bash history on factory-flashed units, we can see additional scripts being run:

bash ~/Desktop/installer.sh --nvidia-device=ORIN_NX -jp=auto --zedbox-mini=0 \
    --sdk-version=v5 --driver-version=1.3.1 --capture-card=DUO

Plus cleaner.sh, extlinux.py configuration, and other steps not covered in the public docs.

For managing a fleet of ZED Boxes, having access to the same image and procedures you use at the factory would help us maintain consistency and avoid configuration issues. Currently the docs provide 36.4.3 while factory units arrive with 36.4.4.

Thank you.

6

The probability that you get two defective ZED Link Duo capture cards is extremely low, but not zero.
Please contact the support team by email (support@stereolabs.com) to request a new NDA. Please add a link to this discussion as a reference.

We do not provide this information, but you can directly obtain it by analysing the flash script.

In production, we use the same scripts as the ones that you can download from our website.
We are not hiding any miraculous flash process.

The options that you can see in the script are only there to install specific versions of the ZED X Driver or ZED SDK if required.

We will update the online script soon.