Depth camera not detected: check the SDK version before the cable

A depth-camera viewer that opens cleanly and lists no device is usually not a cable fault. The most common cause of a depth camera not detected by its own software is a version mismatch: the viewer is built on one SDK generation and the camera belongs to another, and that generation supports only the devices on its own list. This guide gives you the triage in the right order — supported-device list first, then runtime build, USB link, power and permissions — so you can separate a version problem from a hardware problem in one pass and decide between a settings fix and a sensor replacement.

Three ways the symptom shows up

Sort the symptom before you touch hardware, because each version points at a different layer.

The viewer is empty and the operating system shows nothing. Plug the camera in and check the OS USB device list: if the camera is absent there too, the fault is at the link layer — cable, port or power. Start with Camera has power but not detected: USB link checks after a cable swap.

The viewer is empty but the OS shows the camera. Enumeration works, so the physical layer is fine. The fault sits above it: SDK generation, runtime build, permissions, or another application holding the device.

A viewer from the other generation sees the camera. This is the signature of a generation mismatch: the older SDK generation streams the camera normally while the newer one lists nothing. It is also the cheapest fault to confirm, because one list lookup settles it.

A near neighbour: the camera is detected but no image starts. That is capture configuration, not detection, and Depth camera detected but no image: check the USB power budget first covers its power side.

Likely causes, ranked

Work down this list and stop as soon as a test changes the picture.

1. SDK generation mismatch. Current depth-camera SDKs ship as two parallel major lines, a 1.x generation and a 2.x generation. The 2.x line supports only the devices on its published list; older-generation modules are not on it. Most likely when the camera predates the 2.x line, or when another generation's viewer streams it without complaint.
2. Runtime or build mismatch. The viewer was built against one SDK version but another version's runtime is installed, or the build does not match the host operating system. Camera not recognized by your SDK: check version support first covers this class.
3. USB link. A damaged cable, a charge-only port or a failing hub keeps the camera off the bus entirely.
4. Power budget. A port or unpowered hub that delivers less than the camera draws, so the device drops or half-enumerates. A USB 3.0 host port supplies up to 900 mA at 5 V (4.5 W); cameras that draw more need a powered hub.
5. Permissions or exclusive hold. On Linux the user account needs access rules for raw USB devices; on any operating system another viewer or service may hold the camera exclusively.
6. Bandwidth. Several cameras share one host controller — Multiple depth cameras on one host: fix enumeration and USB bandwidth.

Causes 3 to 6 are real, but a camera that appears in the OS device list has already passed most of them. That is why the list check comes before every cable swap.

The one-minute check: the supported-device list

1. Name the generation. The viewer's version information states the SDK line it was built on: 1.x or 2.x. A viewer that cannot state a version is too uncontrolled to debug — reinstall the viewer and SDK together from one release first.
2. Open that generation's list. Each SDK generation publishes a supported-device list naming the exact models it enumerates. Match the list to the generation: a 1.x list does not answer for a 2.x viewer.
3. Search the exact model string. Copy the model from the camera label. Support is per model; a series name in one generation's list proves nothing about a specific model in the other's.

Then apply the rule: a viewer enumerates only the devices its SDK generation lists, and the gate sits above the USB link. A perfect physical layer never pulls an unlisted camera through. Model on the list? Continue with the stack checks below. Model off the list? Stop — no cable, driver or permission change adds it, and the worked example below shows the decision.

Worked example: a 1.x-generation camera against a 2.x-generation viewer

The case: a depth camera several years in service, streaming normally on the older SDK generation, invisible to a viewer built on the 2.x line. Inputs, each with its source:

Rule in words: enumeration is gated by the supported-device list, so observations A and B cannot overrule C. The decision rule is AND, not majority: every check must pass, and C is the gate.

Arithmetic: score the checks. Power and link: pass, from observation A. Camera hardware: pass, because observation B proves the sensor and its processor stream depth. Port and cable: pass by swap test. Supported-device list: fail, from observation C. Tally: 4 passes, 1 gate failure. Under an AND rule the gate carries veto weight, so 4 passes plus 1 gate failure resolves to fail. Time cost: the four passing checks consume roughly 15 minutes of swapping and reinstalling; the list check takes 1 minute and decides the case on its own.

Result: an unsupported pairing, not a defect. The camera works; the viewer was never built to enumerate it.

Decision and threshold: to keep the camera, run it on the 1.x-generation SDK and its matching viewer, pin the versions, and treat the generation boundary as a wall. To bring the station onto the 2.x pipeline, replace the camera with a model on the 2.x list. The threshold is binary — on the list or off it — and there is no setting that crosses it.

On the list but still absent: work down the stack

A camera that is on the list but invisible has a fault below the SDK's device gate. Test in this order:

1. Align viewer and runtime to one release. Reinstall both from the same version, and align camera firmware where the SDK expects a minimum — 3D camera header version mismatch: fix firmware and SDK alignment.
2. Confirm the OS device list. If the camera is missing there too, move to a short cable on a host port before anything else — USB camera connects then disconnects: fix the cable and link.
3. Read the negotiated speed. A link that falls back from SuperSpeed (5 Gbit/s) to High Speed (480 Mbit/s) blames the cable or the port, not the camera — Camera enumerates as USB 2.0 on a USB 3.0 port: fix the link.
4. Budget the port power. Move the camera to a powered hub or a different host port; the power-budget article linked above gives the test.
5. Respect cable length. Passive USB 3.0 copper holds its speed to roughly 2-3 m; beyond that, use an active extension — USB cable length limits for 3D cameras: keeping the data link alive.
6. Clear permissions and holds. On Linux, install the access rules for raw USB devices and re-plug; on any operating system, close other viewers and background services first.
7. Separate detection from capture. If the viewer now lists the camera but no stream starts, the problem has moved to profile selection — 3D camera no matched video stream profile: set a listed depth mode.

Most on-the-list failures die at steps 1 and 6, and both cost minutes.

Keep one SDK generation per project

Prevention is cheaper than any fix above.

• Choose the generation from the camera list first. Write down every depth camera the station will run, find a generation whose list contains them all, and standardize the viewer, examples and build on that generation.
• Pin one version everywhere. A development machine, a build container and a deployed host must all carry the same SDK version — Docker build SDK version mismatch: pin one library version everywhere.
• Check SDK support before ordering. For any new depth camera, run the depth camera SDK support check before the purchase order, not after the first failed enumeration.
• Plan the end-of-life path early. A camera marked end of life soon will not gain support in newer generations — End of life camera SDK support: plan before you integrate.

When the right fix is a supported sensor

Replacement beats preservation when the camera is marked end of life soon and its SDK generation is frozen. The hours spent guarding a legacy stack grow with every host update, while the camera's capability stays still. A current sensor resets the problem and puts you back on a supported list.

The 3D sensors range covers the main depth technologies as in-production models:

The three cards span the spread: a projected structured-light camera, a laser galvanometer stereo camera, and a ToF sensing camera. The camera finder filters the full range by type — laser profiler, stereo and structured light, logistics and volume, ToF — and the configurator matches the sensor to the rest of the station.

If the choice between keeping a 1.x stack and replacing the camera is close, send the camera model, the SDK version and the station's cycle time through the contact page; the answer is usually a one-paragraph decision. The 3D topic page collects the rest of the detection, streaming and bandwidth fixes.