Depth stream missing after firmware update: rebuild the driver stack

A legacy USB depth camera comes back from a firmware update streaming color and nothing else. lsusb still finds the device, the capture example still lists depth, color and two infrared streams, and not one depth frame arrives. In almost every case the camera is fine: three pieces of software that must agree no longer do. The firmware on the camera head moved; the patched UVC kernel driver and the SDK on the host stayed behind. This guide gives you the symptom signature, the causes ranked by probability, the two-part fix in the order that works, and the bandwidth arithmetic that tells you why the recovered streams need a direct USB 3.0 port.

The symptom: color alone, and warnings underneath

Right after the update, dmesg shows the camera bind three or four UVC interfaces, each bind followed by a line in this form: uvcvideo: No streaming interface found for terminal 3. The SDK's capture example still enumerates all four streams — DEPTH, COLOR, INFRARED and INFRARED2, at this camera class's defaults of 480×360 on depth and infrared and 640×480 on color — and may print one further warning: Camera head contents version != 12, data may be missing/incorrect. Then the log fills with Subdevice 0 bad magic number 0x0 while the color window renders normally.

Read that combination, not the color window. Color travels the standard USB Video Class path that any stock driver parses; depth and infrared are custom streams that only a patched driver plus a matching SDK can decode. Color alive while depth and infrared stay dead is the fingerprint of a version mismatch, not a cable, port or power fault.

Two neighbouring failures look similar and take different fixes. A stereo rig whose depth sensors are physically dead also shows RGB with no depth, for a hardware reason — that repair path is in stereo RGB with no depth: the sensor fix. A camera that delivers no streams at all, color included, sits further upstream of firmware versions; trace it stage by stage with where depth frames stop on a Linux host.

Likely causes, in order of probability

Rank the candidates before touching anything, because the top one accounts for most post-update failures and the others only matter once it is cleared.

The values on the magic-number warnings are diagnostic rather than noise, and the bad-magic-number decode for depth streams shows how to read those bit flags so you can tell a firmware-side marker from a driver-side one.

The fix: firmware first, then rebuild the host stack

Run the two halves in this order: flash first, rebuild second. Rebuilding the driver and SDK before the firmware just recreates the mismatch against whatever the camera becomes next. If the flash has already happened — and the color-only symptom says it has — start at step 3.

1. Record the current firmware release. Query it from the host: the SDK's device query or the vendor's update utility prints it as soon as the camera enumerates. Write the value into the machine file before anything else changes.
2. Flash the matched firmware on the supported platform. For this legacy class the supported tool is the vendor's Windows update utility; these cameras have no supported flash path from Linux. Run it on a bench machine with the camera straight into a USB 3.0 port on the host.

Stability during the write matters more than length or connector style, so keep one proven lead at the bench for flashes:

The LS-CBL-0219 is a 3 m USB3.0 camera cable, high-flex and drag-chain rated; any equivalent shielded USB 3.0 lead serves the same purpose, provided the write never drops mid-update. Some current cameras instead expose a DFU device-mode update from Linux — a different flow with its own safety rails, set out in a DFU firmware update done safely.

3. Rebuild the patched UVC driver for the running kernel. Unload the module, rebuild the patched driver from the SDK's source tree against the kernel you are actually running, then reload it. Legacy SDKs ship one patch script per kernel series — a 4.4-series kernel takes patch-uvcvideo-4.4.sh — and the script has to run against matching kernel sources. When the patch refuses to apply or the module misbehaves afterwards, the usual culprit is a source-tree mismatch, and matching the UVC patch to the kernel source tree walks through it.
4. Rebuild and install the SDK release matched to the new firmware. Compile library and headers from one release tagged for the firmware now on the camera, install, and let the device re-enumerate. What each side checks at handshake, and how to confirm the alignment held, is set out in the firmware and SDK alignment fix.
5. Replug and capture. Reconnect the camera, run the capture example for 60 seconds, and expect all four streams to render with an empty warning log. The checks and the arithmetic behind the USB 3.0 requirement follow below.

Verify the rebuild, then verify the link can carry it

The first verification is log-level. dmesg should bind the same terminals with no No streaming interface found lines, and the capture example should run 60 seconds with no bad magic number warnings while each stream's frame counter advances at its set rate. Color arriving alone after a rebuild means the host stack is still stale: repeat step 4 against the release matched to the firmware you flashed, not the one on the old install notes.

The second verification is capacity — confirm the link physically fits the streams you just recovered. At this camera class's default modes, 480×360 depth at 16 bit per pixel and 640×480 color at 24 bit, both at 30 fps, the demand is:

The total scales linearly with frame rate, and the depth share doubles again if you raise depth to 32 bit per pixel. Set that 304 Mbit/s against the two links. USB 2.0's raw 480 Mbit/s loses protocol overhead and lands near 300–320 Mbit/s in practice, so the demand saturates it — depth frames stall or drop while color alone just fits, which is exactly the pre-rebuild behaviour. USB 3.0 carries roughly 4 Gbit/s after 8b/10b encoding overhead, so the same load runs below a tenth of the link and leaves room for a second camera. Flash and capture both belong on a direct USB 3.0 port for precisely this reason.

When the usual answers are wrong

Three reflexes do not touch this fault. Re-plugging, swapping cables and reinstalling the operating system all leave the version triangle untouched, because the mismatch lives in build artefacts, not in runtime state.

Two cases call for a different tool. If the legacy SDK ships no patch script for the kernel you now run — support for these series ended years back — you cannot patch cleanly, so pin that machine to a supported kernel or retire the camera. If a failed flash leaves the camera enumerating with a changed or generic USB ID, stop re-flashing and read the ID first: reading the USB ID when a depth camera is stuck in firmware update mode separates recovery from replacement. And enumeration without any SDK visibility is a host-side fault of its own, covered in the lsusb-but-SDK-cannot-open-it checklist.

The decision rule for the bench: a single legacy camera on a kernel you can pin is worth the hour this fix takes. A fleet of legacy units, or a kernel you cannot downgrade, is not.

Retire the legacy unit into a current 3D sensor

A current sensor ends this maintenance class. Firmware, SDK and documentation arrive as one matched release, so the update-then-rebuild sequence above simply does not exist in its bring-up: enumerate, install the SDK, capture. It is the alignment you just rebuilt by hand, bought instead of maintained.

Pick by task. Projected structured light suits close-range surface, gap and defect geometry. A multi-DOE speckle structured-light head is built for parcel and pallet volume work. Time of flight wins where a wide depth field at moderate precision matters more than point-by-point detail. The 3D sensors category holds the current range and the camera finder filters it by type and series.

The models below cover two of those tasks:

To size the whole station — sensor, interface, cabling and controller — start the configurator at the camera step:

Prevention: pin the three versions together

• Record firmware release, driver patch and SDK package per unit in the machine file. The next mismatch becomes a 30-second lookup instead of an hour of archaeology.
• Rebuild driver and SDK in the same session as any firmware update. Benches left half-updated across days are where these mismatches breed.
• Accept a bring-up only on a 60-second, all-stream capture with an empty warning log. A color preview proves one path out of four.
• Flash from a direct host port with a known-good cable. A dropped write is the one failure here with no software fix.
• Keep one designated machine with the vendor's update utility installed. Updates happen from it deliberately, not from whichever laptop is nearest.

Spares belong in the same kit as the update tool: the camera data cables range covers the lengths and connector styles for fixed and drag-chain runs, and the accessories finder filters both by length and connector.

Work the five steps in order and the version triangle closes: firmware, driver and SDK all name the same release, all four streams render, and the warning log stays empty for a full minute. If a rebuild keeps failing, or you are speccing the replacement station, send the depth task, mounting and interface budget through the configuration service or reach the team on the contact page — include the firmware, driver and SDK versions from your machine file and the answer comes back concrete.