Depth camera not detected: wrong port, wrong cable or wrong power

A depth camera that never appears in the viewer is more often a port problem than a software one. The classic first-day failure: a USB 3 camera whose cable ends up in the laptop's Ethernet jack, or an Ethernet-only variant expected to appear on a USB port. No reinstall, driver update or longer wait will fix that, because the camera never reaches the electrical layer where detection happens. This guide gives you the one-minute check that identifies the interface your camera actually has, the arithmetic that shows which port your stream needs, and a test order that separates a wrong port from a bad cable, missing power or a network fault. The same logic covers hobby-class depth cameras and the industrial 3D sensors in our range alike.

Find the interface on the camera body first

The decision is physical, and it takes one minute: turn the camera over and look at the socket where the cable connects. The socket on the body is the interface, and the interface dictates the port, the cable and the power source.

If the body has no RJ45 socket, the camera is USB-only, and no Ethernet cable, switch or adapter will ever detect it. If the body has an RJ45 socket, it will never appear on a USB bus. Many depth camera lines sell both variants under near-identical model numbers: the sensor is shared, the interface is not. Read the suffix before you plug anything in — the guide to GigE PoE vs USB3 camera variants shows how. Our own 3D sensors range spans laser profilers, stereo cameras and ToF units, and the same rule picks the port for every one.

Why a USB camera never enumerates from an Ethernet jack

Detection is not a software search; it is two different buses that share nothing above the plug. Within milliseconds of a USB plug-in, the host controller senses the pull-up on the data lines and the camera answers with a hardware descriptor — that moment is enumeration, and it happens before any driver or viewer is involved. An Ethernet port works through a different controller, a different driver stack and a different protocol: the camera must boot, bring its link up and then answer on an IP address. A USB-only camera has no Ethernet stack to answer with, so the jack has nothing to talk to.

What you see matches that mechanism exactly. The viewer opens to an empty device list, replugging changes nothing, and no error appears because the system never saw an event. Nothing bridges the gap — not an adapter, not a driver, not patience. Move the plug to a USB 3 port on the machine itself and the device appears within a second; that instant appearance is the confirmation that the port was the fault.

Will the streams fit: a 1280 × 720 depth and IR pair at 30 fps

Once the plug sits in a port that can see the camera, the port also has to carry the stream. The case below is a typical mid-size mode for a USB depth camera; substitute your own mode and the arithmetic scales exactly.

Inputs: one depth image and its matching infrared image, each 1280 × 720 pixels at 16 bits (2 bytes per pixel) and 30 frames per second, on a host offering USB 2.0, Gigabit Ethernet and USB 3.0 ports. The line rates are the interface standards: 480 Mb/s for USB 2.0, 1000 Mb/s for Gigabit Ethernet, 5000 Mb/s for USB 3.0.

The rule in words: the payload a port must carry is pixels times bytes per pixel times frame rate, and the capacity a port offers is its line rate divided by 8 bits per byte.

One depth frame: 1280 px × 720 px × 2 B = 1,843,200 B ≈ 1.84 MB. One stream at 30 fps: 1.84 MB × 30 = 55.3 MB/s. Both streams: 55.3 MB/s × 2 = 110.6 MB/s. The capacities: USB 2.0 gives 480 ÷ 8 = 60 MB/s; Gigabit Ethernet gives 1000 ÷ 8 = 125 MB/s; USB 3.0 gives 5000 ÷ 8 = 625 MB/s on paper, near 400 MB/s in practice after encoding overhead.

Result: the pair needs 110.6 MB/s of sustained capacity, which is 1.8× the entire USB 2.0 line rate — a USB 2.0 port fails by construction and cannot stream the mode at all. A Gigabit Ethernet link leaves 125 − 110.6 = 14.4 MB/s of margin, about 11.5%, which protocol overhead consumes: it carries one full-rate stream comfortably, and the pair only at half rate, where 15 fps brings the pair down to 55.3 MB/s with room to spare. USB 3.0 holds the pair with at least 3.6× headroom even at the practical 400 MB/s.

Decision and threshold: above about 60 MB/s of sustained payload, plan on a USB 3 port; a Gigabit Ethernet variant is the right pick for one full-rate stream or a halved pair. What moves the number: an 8-bit depth mode halves the bytes per pixel and the payload with it, 60 fps doubles it, and an RGB stream adds its own pixels × bytes × rate on top.

The same arithmetic explains the failures these guides cover: a depth stream with no data on a USB 2.0 port, a camera stuck at low resolution for lack of a real USB 3.0 port, and what fits when you are streaming depth frames to a remote PC over gigabit ethernet.

Checks in order: port, cable, power, network

Run the tests in this order; each step either clears a layer or names the fault.

1. Read the socket on the camera body against the table above. RJ45 sends you to step 6; USB-C or micro-B keeps you on the USB path.
2. On Windows, open Device Manager and replug while you watch; on Linux, run lsusb before and after. An entry appearing means the OS enumerated a USB device and the port layer is good. Nothing at all means the fault sits below the software.
3. Move the plug to a USB 3 port on the machine itself — not a monitor passthrough, a keyboard port or an unpowered hub. USB 3 ports usually carry an SS marking or a blue tongue.
4. Swap in a cable known to carry data. Charge-only and data leads look identical, and a known-good cable convicts or clears the layer in two minutes; the cable-first isolation checks show the sequence.
5. Check the USB power budget: a USB 3 port supplies 900 mA at 5 V, which is 4.5 W for the camera alone, and a hub divides that between devices. A camera that blacks out or vanishes when the infrared stream starts is the under-power signature; the power-budget checks and the disconnect fix cover it.
6. For the Ethernet path, confirm PoE at the switch first (next section), then the network: link LEDs on, then a ping to the camera's address. The subnet and link-local fixes apply once the link is up.

If every layer above passes and the viewer still lists nothing, the port was never the problem. The fault has moved into software, and the SDK-version check is the next stop.

PoE variants: power comes before discovery

A depth camera sold as the PoE variant draws all of its power over the Ethernet cable — data and power in the same jacket. That makes power the first layer to confirm, because a camera that never boots cannot announce itself on the network, and the symptom matches the wrong-port case exactly: no status light, no link, an empty device list.

IEEE 802.3af delivers up to 12.95 W at the camera, and PoE+ under IEEE 802.3at raises that to 25.5 W. Match the switch port or injector class to the class the camera asks for; an af-only port feeding an at-class camera leaves it under-powered and silent. A mid-span injector solves the non-PoE switch case: one port, one camera, no rewiring.

Cables that mimic a wrong port

A cable with no data pairs — the charge-only lead bundled with phones — leaves the bus nothing to enumerate, and it fails exactly like a wrong port: silent, on every machine, every time. A lead damaged at the strain relief fails the same way, sometimes only in one plug orientation. The swap test with one known-good data cable clears or convicts the layer in two minutes.

Passive USB 3 copper is dependable to about 3 m; beyond that, expect intermittent enumeration and dropped frames rather than a clean failure. Ethernet runs much further on ordinary network cabling, which is one reason the PoE variant earns its keep on longer runs. The camera cables range covers both worlds, from under-1-m stubs to runs over 20 m — pick by interface first, then by length and flex rating.

The LS-CBL-0219 is a 3 m USB 3.0 camera cable in high-flex, drag-chain construction, suited to a depth camera on a moving axis.

On the Ethernet side, the LS-CBL-0199 is a 3 m GigE camera cable with screw locks, in the same high-flex construction.

When the usual answer is wrong

Sometimes the plug is right and the camera still misbehaves; those failures have their own guides:

• A camera that enumerates as USB 2.0 on a USB 3.0 port has a port, cable or controller problem one layer below the viewer — detection succeeded, the link speed did not.
• A black image with the camera detected points at bandwidth or power, not at the port.
• Two cameras fighting over one host is a controller and bandwidth question, not a cable one; the multi-camera bandwidth and sync guide plans that set-up.

Prevention takes a minute: label both ends of every camera cable, keep the PoE variant on a dedicated PoE port, and never route a streaming depth camera through an unpowered hub. More depth-camera fixes are collected on the 3D vision topic page.

Choosing parts when the interface decides the set-up

If you are specifying an industrial depth camera rather than debugging a hobby-class one, read the interface off the model before anything else, because it decides the cable, the switch and the power budget in one stroke. The depth range here includes ToF sensing models such as the MV-DT01WMU and laser galvanometer stereo cameras such as the MV-DLS300P-04, and every one obeys the same rule: the connector on the body picks the port.

To pick the rest of the chain, filter the 3D camera finder by interface and resolution, match the cable in the accessories finder, or let the system configurator step through camera, cable and power together. If the checks above leave your camera silent on every port you own, the hardware is the suspect — contact us with the model and the ports you tried, and we will help you choose the replacement or the interface variant that fits.