Stereo camera works for RGB but no depth: fix missing mono sensors

A stereo depth camera that shows a live color image but produces no depth output looks like a hardware failure, and it almost never is. The RGB sensor streams on its own, while the depth pipeline must open both mono sensors before it can compute anything. When one mono sensor fails to initialize, most software quietly disables depth and carries on with color, which is exactly the symptom you are seeing.

This guide walks through the diagnosis in the order that finds the fault fastest: confirm what the host actually detects, check the resolution the stereo pair is being asked to run, then align the host libraries with the device firmware. Most cases resolve in the software steps; you should not order a replacement until they are exhausted.

Why RGB works when depth does not

Inside a stereo depth camera sit three or more separate image sensors: two monochrome sensors with a fixed baseline for disparity, plus a color sensor for texture. The host talks to the device over one link, but each sensor is initialized separately by the on-device pipeline.

Depth requires both mono sensors to open, at resolutions they support, with calibrated data available. If either open fails, a well-behaved SDK drops the depth streams and keeps the color stream alive. That is why your log can show a perfectly good RGB preview next to an error naming a socket that holds a mono sensor. The error is real, but it describes one sensor, not the whole device.

The general failure modes for this symptom, in rough order of probability, are:

1. Host software older than the device revision.
2. A resolution requested from the mono pair that the sensors reject.
3. A mismatch between the flashed firmware and the host library version.
4. A marginal USB link that drops during sensor enumeration.
5. Genuine sensor or board failure, which is rare.

Step 1: read the enumeration and socket errors first

Start from the startup log, not from the symptom on screen. Two lines matter:

• The device enumeration line, which shows the device ID and whether it is booted, plus the negotiated USB speed.
• Per-sensor errors, which typically name a socket or port number for each mono sensor that failed to open.

If both mono sockets report a failure, suspect software: sensors rarely fail in pairs. If only one socket fails repeatedly after a software fix, that socket's sensor or flex cable becomes a candidate for hardware trouble. Note the exact wording and socket numbers before changing anything; you will compare against them later.

Also confirm the USB speed in the log. A device enumerating at USB 2 speed (480 Mbit/s) instead of USB 3 (5 Gbit/s) has roughly a tenth of the bandwidth and can starve the continuous stereo streams, which produce two frames for every depth frame. Swap in a known-good USB 3 cable, plug directly into a host port, and retest before drawing conclusions. Our article on USB bandwidth and power problems behind a black depth image covers that branch in detail.

Step 2: check the resolution the stereo pair is asked to run

Mono sensors in stereo modules support a fixed set of resolutions, and the common values are low vertical counts such as 720 or 800 lines. If your pipeline copies a 1080-line preset from the color camera, or a demo script picks a high default and silently falls back, the mono sensors can refuse to start. Look for a log line about a required resolution or a fallback, then set the mono resolution explicitly to a value from the sensor's supported list.

A practical habit: configure the stereo pair and the color sensor independently, every time. Let the mono pair run at its native stereo resolution and give the color stream its own setting. If your code creates a stereo node with inherited or default parameters, replace the defaults with explicit values and retry. Our guide on changing depth resolution and field of view at capture time shows how these settings interact with coverage, and why stereo depth coverage is smaller than the RGB view explains the geometry behind it.

Step 3: align SDK and firmware versions

The most common cause of a pair of healthy-looking sensors refusing to open is a version gap. Stereo modules get revisions: new sensor parts, new initialization sequences, new calibration layouts. A host library that predates the revision does not know how to bring the mono sensors up, and the failure surfaces as a per-socket detection error.

Fix it in this order:

1. Note the host library version your tool actually loads, from its startup line, not from what you believe is installed. Multiple versions can coexist in different environments.
2. Check the device's firmware version through the vendor's update or management utility.
3. Update the host library to a current release in the environment you actually run.
4. Use the matching firmware updater from the same release to flash the device.
5. Reboot the host so no old library stays loaded, then rerun your test.

Beware of half-updated stacks. A library updated while a demo tool pins its own older dependency can look correct and still fail, because the demo loads a different copy. Run your check inside the same interpreter or runtime that shows the fault, and confirm the loaded version there.

Step 4: try a second, minimal pipeline

Once versions match, isolate the demo tool from the problem. Demos and viewers age faster than the libraries under them, and a tool released before your device revision may construct its pipeline in a way the device rejects, even with a current SDK.

Write the shortest possible acquisition: open the device, create the stereo node with the explicit mono resolution from step 2, request the raw depth stream, and print whatever error appears. If the minimal pipeline produces depth, the fault is in the tool layer and you can simply move to a maintained viewer or update the demo. If it still fails at sensor open with matched software on a good link, collect the exact error text and contact the vendor through their support channel; keep the log from step 1 handy, because the socket numbers and versions are the first things support will ask for.

When the usual answer is wrong: hardware checks

If matched current software, an explicit supported resolution, and a verified USB 3 link still leave one mono socket dead, treat it as hardware. Power the device from a different port or powered hub, inspect the connector for damage, and try a different host computer. A sensor that is never enumerated on any host, while its partner works, points at the sensor, its flex connection, or the board.

At that point the decision is replacement, and it is also a moment to reconsider the camera class. If your task needs active depth regardless of ambient texture, a projected structured-light camera removes the dependence on scene detail.

For passive stereo in low texture, or for volume measurement in logistics, a multi-DOE speckle unit designed for measuring tends to hold depth where a plain stereo pair would drop out. Our article on close-range depth dropout on fuzzy surfaces and thin parts covers that failure mode, and the 3D sensors category lists laser profilers, structured-light cameras and ToF units side by side if you are comparing classes.

Prevention checklist

• Pin the host library version and firmware as a matched pair in your deployment notes, and re-verify after any environment rebuild.
• Set the mono resolution explicitly; never inherit it from the color stream.
• Assert the negotiated USB speed at startup and alarm if it drops below USB 3.
• Log the loaded library version from inside your process, not from the installation manifest.
• Keep one known-good cable and host port reserved for camera bring-up tests.

Run through this list whenever a new camera revision arrives on a line. It turns a mysterious missing depth stream into a two-minute check, and it separates software causes from the rare hardware one before you spend money on a replacement.

Where to go next

Browse the area scan cameras range or the 3D sensors category to compare stereo, structured-light and profiler options, or start the system configurator to match a camera to your host and lens. If depth quality rather than depth presence is the issue, the guides on depth and color synchronization and unknown pixel formats that hide depth streams cover the next layer of the stack. For anything not covered here, the contact page reaches the applications team.