One 3D camera not detected while others work: isolate it

Seven of your eight identical 3D cameras enumerate and stream on one host. The eighth shows nothing: not in the device list, not in the SDK viewer. That asymmetry is the strongest clue you will get, because the seven working units prove the host, driver and SDK are sound. What remains is the camera itself, its cable, its port or its mounting, and a five-minute swap ladder separates them. This page gives the ladder in order, the arithmetic that keeps it to three tests, a table that maps what you saw to one verdict, and the mechanical questions asked before a return is accepted. Run it once: you either get the camera back, or you hold a return report that settles the case.

First move: the swap ladder

Leave the software alone. A driver fault hides all eight identical cameras, not seven of them. Work the ladder in cost order and log every line of it. On a single-camera bench with no sibling to compare against, start with USB link checks after a cable swap instead; the general isolation method for one bad unit is covered in camera fault isolation for repeatable unit-specific failures.

1. Re-seat and re-power. Unplug the suspect, wait 5 s, plug it back into the same port, and watch the port: an enumeration event means the port sees something, even if the SDK does not.
2. Flip the plug at the camera. Turn the USB-C plug 180° and retest; then flip the host end too. Two orientations, ten seconds.
3. Swap the cable. Take the complete cable from a working sibling and use it with the suspect, on the suspect's own port.
4. Swap the port. Move the suspect, with the sibling's cable, to the port a working sibling was using.
5. Swap the host. Repeat once on a second computer with its own power supply.
6. Log everything — camera, cable, port, plug orientation, outcome — in a table like the one below.

Not detected is not the same as no frames

Split the symptom before you touch hardware. Not detected means the unit never appears: not in the operating system's device list, not in the SDK's enumeration. That is a link-level defect — connector, cable, port, power or the camera itself — and the ladder above is the right tool. Detected but no frames means the unit enumerates and the stream dies; that is a bandwidth or data-stream problem, and the fix is in 3D camera frame rate low on software trigger: mode and data streams.

If the vendor's viewer lists the camera but your own application does not, look at configuration before silicon: 3D camera context creation crash: fix settings and path errors covers that failure. And with identical cameras, make sure you are testing the unit you think you are — identical units can report the same USB port ID, as USB port ID the same for all cameras shows, and GigE units can share a name until two identical cameras on one PC are separated.

Why the flip test comes first

A USB Type-C plug is reversible because the connector carries its high-speed contacts twice, once per orientation, and the port reads which set is active over its CC pins before it routes the link. That redundancy is also a diagnostic. One worn, bent or contaminated contact kills the link in one orientation and passes in the other, so flipping the plug routes the same signals through a second set of contacts — the fastest hardware test you own.

If the camera links one way only, clean the receptacle with a lint-free swab and electronics-grade isopropyl alcohol, let it dry, and retest both orientations with two different cables. Orientation behavior that follows the camera across cables points at the camera's receptacle; behavior that follows the cable points at the cable. Both findings go in the report.

Worked example: eight cameras, one dead

Name the fleet: cameras C1–C8, cables K1–K8, ports P1–P8, one host. C3 will not enumerate. The whole investigation is three tests:

Test 2 clears cable K3 and port P3: a healthy camera enumerates on them. Test 3 removes the last doubt — C3 is dead on a second, proven cable and port, in both orientations. Verdict: hardware fault in C3; file the return.

The arithmetic behind the order: a full sweep of camera-cable pairs is 8 × 8 = 64 combinations, and adding ports gives 8 × 8 × 8 = 512. Budget roughly 15 s per cycle for the swap, power-up and enumeration wait — time one cycle on your rig and redo the sum. The full sweep costs 512 × 15 s = 7,680 s, about 2 h 8 min of swapping; the ladder costs 3 × 15 s = 45 s. Each ladder test clears or condemns one variable, because the known-good sibling is the reference, not another combination.

Reading the outcome

Only the first row is a return. The most common wrong turn here is reinstalling the SDK on a host that enumerates seven identical units: the stack is exonerated the moment any sibling connects, so spend the afternoon on the row that matches your outcome instead.

When the host is the problem

Two host-side conditions imitate a dead camera when eight units share one machine.

Bandwidth first. One USB 3.2 Gen 1 controller carries 5 Gbit/s on the wire; the 8b/10b line coding leaves 5 × 8/10 = 4 Gbit/s of payload, which is 500 MB/s, and 400–450 MB/s in practice.

Say your SDK's frame metrics report 380 MB/s per camera (an example input — read your own figure from the same screen): two cameras on one controller want 2 × 380 = 760 MB/s against a 500 MB/s ceiling, so the second stream stutters or refuses to start. That camera is healthy; move it to another controller and the symptom disappears.

Power second. A USB 3 port supplies up to 900 mA at 5 V, which is 4.5 W, and an unpowered hub shares that across everything downstream. Two cameras drawing 2.5 W each (example figures — use each unit's own power spec) sum to 5.0 W and brown out, and a browned-out 3D camera looks exactly like a dead one. Re-run the ladder on rear-panel ports or a powered hub, and the unit you condemned comes back.

One shared-bus behavior worth knowing: a unit with an internal short can drag its whole hub down with it, so healthy siblings start dropping too. The same pattern — one failed device blocking its neighbors on a shared network — is familiar to anyone who has debugged an industrial scan list. Unplug the suspect, power-cycle the hub, and watch the rest recover: that is the confirmation, on both buses.

Cable length is the third factor. Passive USB 3 links lose margin with every meter, so run the ladder on the shortest cable that reaches; the distances that hold a link are in USB cable length limits for 3D cameras. For the bench and the spares drawer, two camera cables cover both worlds: the LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag-chain use, and the LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud.

Drag-chain rating belongs on anything that moves with a robot or a slide; a locking stud belongs on any RJ45 that lives with vibration.

Mechanical history and mounting

Every vendor asks the same four questions before accepting a 3D camera back, so answer them before you pack the box:

• Did it fail on its first connection, straight out of the box?
• How is it mounted — bracket, stand, tripod — and how stiff is the mount?
• Are you using the supplied cable and mount, or third-party parts?
• Was the unit dropped, knocked or banged against anything?

Solid-state 3D cameras carry the optics, projector and interface on one board. A knock that leaves no mark can still crack a solder joint or shift an optic enough to kill the link, and a straight account of an impact routes the case faster than a vague it-stopped-working report. Describe the handling honestly in the return request: every camera we ship carries a 3-year warranty minimum, and an honest history is what support needs to apply it.

Prevention is mostly mechanics. Clamp the cable about 100 mm behind the connector so the plug carries no load, and let the mount hold the camera's weight. On the bench, camera stands hold the unit at a fixed height while you swap cables underneath; the LS-MNT-0040 is a professional slide-table stand with a height of 700 mm and a 400 x 450 mm base.

Before you request the return

• The test table: camera, cable, port, plug orientation and outcome for every run.
• Serial numbers of the failed unit and of the two siblings used as references.
• Orientation behavior, if the link works one way only.
• The mechanical history: first connection or post-impact, mounting method, cable used.
• What the host shows — nothing at all, or an unknown-device entry.

Send that package through the contact page and the exchange is a formality: you have proved the unit dead on known-good everything. If the line cannot wait, a replacement from 3D sensors keeps it moving — in-stock items ship within one business day — and one spare unit per line turns the next dead camera into a swap instead of a shift. More depth-camera set-up and fault-finding is on the 3D vision topic page.