Depth camera blank frame on one sensor: isolate the cause

A multi-sensor 3D camera that delivers a live image from one head and a black, frozen or absent frame from another needs a per-stream diagnosis. Working streams show that shared resources function at least partly; they do not rule out bandwidth limits, power instability or driver faults. This guide walks through the tests in order of cost, from a headless frame count that takes two minutes to documented external connection checks. It ends with the point at which you stop and request service instead of opening the housing. It applies to stereo depth rigs, structured-light cameras and other multi-head units in the 3D sensors range, where the SDK exposes individual streams.

Start by ruling out the viewer

The cheapest mistake to make is replacing hardware over a windowing problem. GUI toolkits fail on a per-window basis: a missing display backend, a headless session over SSH without X forwarding, or a pixel format the viewer cannot convert can blank one preview while others, built on a different code path, still draw.

Run the failing stream headless. Request frames from the suspect sensor only, with no window, and count them:

1. Open the vendor SDK in a plain script or command-line tool, not the GUI example.
2. Request a stream from the failing sensor and request nothing else. Use the documented free-running mode or supply the required trigger.
3. Print a running frame count every 1 s for 60 s.
4. Save a handful of frames to disk as raw or losslessly encoded files and inspect the pixel statistics, not just the picture.

At a requested 30 fps, an uninterrupted 60 s capture would produce approximately 1,800 frames: 30 × 60 = 1,800. Allow for startup delay, and compare delivered frame timestamps rather than expecting an exact count. The nominal frame interval is 1,000 ms / 30 = 33.3 ms.

If the counter climbs and saved frames contain changing scene detail, acquisition is working during that test. Investigate the display conversion and GUI layer. A non-zero mean alone is insufficient: a repeated stale frame can also contain plausible pixel values. Check the guide on controlling vision display window size and screen position for common window-creation pitfalls. If the counter stays at zero, continue below.

Read the driver log before touching anything

A missing sensor may announce itself during startup. Watch the SDK's own log output while the device starts, at debug or info level. Look for three patterns:

• A sensor-detection error naming a socket: the device did not enumerate that sensor. Check supported configuration, firmware compatibility and documented connections before concluding that hardware failed.
• Streams appear, then the error repeats: investigate intermittent power or connections, startup sequencing and firmware compatibility.
• No mention of the failing sensor at all: verify that your pipeline requested the correct sensor and that logging includes enumeration events.

Distinguish these carefully. A silent stream can result from configuration, an absent trigger, a transport failure or hardware. The absence of a log message does not establish which one applies. Record the exact error text and SDK and firmware versions before changing settings.

Check the pixel format on that one stream

Each sensor on a multi-head camera may expose different formats. One head failing to negotiate a format can produce a rejected or absent stream while the others run. Unsupported requests may generate errors, timeouts or no frames, depending on the SDK.

The article on unknown pixel formats and missing depth streams covers the negotiation side. Request a documented supported mode first, without optional cropping or binning, then add options back one at a time. For preview problems, also check the guide to gray images caused by format mismatches.

Compare the working sensors against the failing one

With a stereo or multi-camera depth unit, compatible healthy heads provide useful references. Compare configurations between a working head and the failing one:

1. Point both sensors at the same evenly lit, textured target at the same distance.
2. Match exposure, gain and format where both sensors support equivalent settings.
3. Compare mean pixel value, changing scene detail and delivered frame rate.

For a controlled comparison, a supported exposure of 8 ms can be a starting point, not a universal setting. If frames remain dark, test a supported 16 ms exposure while holding illumination constant. Increased signal suggests an exposure-related issue, but saturation, automatic controls and different spectral responses can complicate the comparison.

A head that begins tracking its neighbour after a configuration change points toward a settings problem. A head that stays dark needs further investigation; it does not by itself prove hardware failure. Check for a lens cap, obstruction or unsuitable illumination. This is the same class of mistake discussed in stereo infrared camera black images, where depth can disappear while acquisition still works.

Swap the socket, not the camera

Some modular multi-sensor rigs expose separate, user-serviceable sensor connections. Others are sealed assemblies with no permitted socket-swap procedure. Follow the device documentation; the diagnostic logic does not authorize opening a housing:

• If the device reports a sensor-detection error after a clean restart, record the physical connection, logical sensor identifier and requested stream. A socket label alone cannot distinguish the sensor from its cable or board channel.
• Perform a full power cycle using the documented shutdown and restart procedure. If no waiting interval is specified, a 30 s unpowered pause is a practical diagnostic interval, not a guaranteed reset method. Disconnect every documented power source, including power carried over the data connection.
• Where the manufacturer explicitly permits swapping compatible external sensors or cables, stop acquisition and de-energize the equipment as instructed before changing connections. If the error follows the moved assembly, investigate that assembly and its cable. If it stays on the socket, investigate the socket, board channel and socket-specific configuration.

When it is genuinely a hardware fault

If the same detection error survives documented restart procedures, compatible external cable checks and a suitable host connection, hardware becomes more likely. Possible causes include a failed image sensor, damaged connector or bridge-channel fault. Firmware incompatibility and configuration still need to be excluded before declaring a component defective.

For sealed, factory-calibrated assemblies, request an RMA through the vendor's documented service path rather than attempting internal repair. Supply the logs, configuration, device identifiers and results of each controlled test.

For context on the kinds of hardware involved, the MV-DPS200P-02 is a projected structured-light 3D camera. The MV-DLS300P-04 is a laser galvanometer stereo camera. These catalog descriptions identify different architectures; they do not establish which internal component causes a blank stream or whether individual sensor streams are accessible. Check each device's documentation before applying a socket-level test.

A worked example

Consider a hypothetical four-head rig with two live mono streams, one live colour stream and one absent stream. Triage in numbers:

1. Headless capture on the suspect head delivers 0 frames in 60 s, despite a supported configuration and verified triggering. A viewer-only fault cannot explain the missing acquisition buffers.
2. The startup log reports a sensor-detection error for that head. This points toward enumeration or initialization, rather than just preview conversion.
3. Three documented power cycles reproduce the same error. Repetition establishes consistency, not proof of a failed sensor.
4. A compatible working head captures at 640 × 480 pixels with an 8 ms exposure. The suspect head delivers no frame, so its mean pixel value is unavailable—not zero.

The result is a repeatable failure in that sensor's acquisition path. The next step is a documented external connection test, if permitted, or a service request. Do not infer a dark image from an absent buffer, and do not reinstall unrelated software without evidence.

Quick checklist

• Frame count headless for 60 s: does the failing stream deliver at all?
• Saved frames and timestamps: is the scene changing, or is a stale frame being repeated?
• Startup log at info or debug level: any per-socket error, and does it repeat?
• Pixel format and resolution set to a documented supported combination?
• Required trigger present, or documented free-running mode selected?
• Exposure and gain compared with a compatible working head viewing the same target?
• Lens and optical paths unobstructed, including the projector path where applicable?
• Full shutdown and restart performed according to the device documentation?
• If an external swap is permitted, does the error follow the moved assembly or stay on the socket?

Record the results before requesting service; the checklist doubles as evidence for support. You do not need to perform a prohibited or inaccessible swap to justify a service request.

When the usual answer is wrong

Two situations break the pattern above. First, bandwidth: a camera that streams two heads successfully can starve another when aggregate traffic exceeds available capacity. If the failing head is the highest-resolution one, check the depth camera frame drops on embedded boards guide.

For an illustrative uncompressed mono stream, 640 × 480 pixels × 1 byte per pixel × 30 fps = 9,216,000 bytes/s, or about 9.22 MB/s. Four such streams require about 36.9 MB/s of image payload before transport overhead. Colour formats, metadata and additional depth outputs change that total. Compare the actual formats and measured traffic with the documented usable link capacity, not just its headline rate.

Second, a black depth output with all raw streams healthy can indicate invalid depth values, unsuitable scene conditions, processing configuration or display scaling. It does not establish sensor failure. Walk through the depth camera black image guide for that branch, and the stereo camera that works for RGB but delivers no depth for the case where the mono pair specifically is not contributing.

Next step: if triage identifies a configuration issue, correct it and repeat the capture test before considering replacement. If replacement or a different architecture is warranted, use the area scan camera finder or the system configurator. If you are still unsure after the checklist, share the log output and frame counts through our contact page and we will help you interpret them.