Thermal camera shows no connected cameras: diagnose the empty list

You run the first detection script on a new thermal camera and get half an answer: a device name, a bootloader version such as 0.0.28, then Usb speed: UNKNOWN and Connected cameras: [], and nothing after that. That combination is not a mystery. It is a two-stage enumeration in which the first stage succeeded and the second never ran: the interface controller came up on USB, but the camera module firmware never finished booting to report the sensor. On the bench, the cause sits in the cable and power path far more often than in the camera itself. This page takes the diagnosis in probability order: read the printout, fix the USB path, budget the power, reload the module firmware, then swap-test the hardware. The worked example carries the arithmetic, and each part named comes from our infrared range with a verdict for its case.

What the four lines tell you

A first-run script - camera_preview.py in one common SDK is the pattern - prints four facts in a fixed order: device name, bootloader version, negotiated USB speed, camera list. Each is a checkpoint, and each narrows the fault.

The device name plus the bootloader version prove the interface controller enumerated over USB. Enumeration needs usable power and usable data lines, so the cable already passes low-speed traffic and the port delivers enough current for one chip. A version such as 0.0.28 is the bootloader firmware answering, not the camera.

Usb speed: UNKNOWN is the failed checkpoint. The host attempted high-speed negotiation and never received a clean confirmation, so the software prints UNKNOWN instead of a rate. Worn data lines, a damaged cable, or a port behind an unpowered hub produce exactly this printout.

Connected cameras: [] is the second failed checkpoint. Camera modules register with the host only after the module firmware boots and reports them. With a valid bootloader readout above it, an empty list means the firmware never ran to completion - usually because the link or supply sagged during the module's power-hungry boot, less often because the firmware image is missing or mismatched.

The decision follows directly: treat the sensor as innocent until the USB path is proven, and prove the path before touching firmware.

Likely causes, in order of probability

Ranks 1 and 2 account for most empty lists on a first bring-up. A charge-only cable has no data conductors at all, so nothing enumerates; a worn or under-spec cable passes enumeration and then fails the high-speed signalling, which is precisely the UNKNOWN line. The same symptom family shows up when a camera has power but is not detected, and the cable-swap checks there transfer one to one.

Rank 4 applies to board-level builds: the board-to-board connector between sensor module and carrier can walk loose in transit, and a module that was fine yesterday can enumerate its controller while the sensor side sits unpowered. The sensor-side connection checks apply here unchanged.

Fix the USB path first

1. Move to a rear-panel or motherboard port and remove every hub. Front-panel case ports hang off thin internal extensions, and an unpowered hub splits one upstream budget across four downstream sockets.
2. Replace the cable with a data-rated USB3.0 cable of 3 m or less, for example the LS-CBL-0219, a 3 m USB3.0 camera cable built for high-flex and drag-chain service. Charge-only cables have no data conductors, and lengths beyond about 3 m invite both signalling errors and voltage drop; the practical length ceilings are the same ones that keep a 3D camera's USB link alive.
3. Confirm the negotiated speed from the host side. On Linux, lsusb -t prints the wire speed per port; on Windows, the USB device's properties page shows it. You want a 5 Gbps result, not a 480 Mbps fallback. A confirmed USB2 rate is a milder fault than UNKNOWN, and why a USB3 camera reads as 480M explains how to tell the two apart.
4. Re-run the detection script and read the two lines again. UNKNOWN should now be a confirmed rate and the camera list should name the module. If the speed confirms but the list stays empty, go to the firmware step.

The accessories finder filters camera cables by length and interface if the cable drawer has run out of candidates.

A cable built for camera data rather than phone charging, in the length range that survives this test:

Worked example: Vbus at the device end of a 3 m cable at the full 900 mA

The inputs, with their sources:

• Port budget: 900 mA at a nominal 5.0 V - the USB 3.0 allowance a host port must deliver, 4.5 W in total.
• Cable length: 3.0 m - the data-rated cable class from step 2.
• Conductor: 24 AWG copper on the power pair, the pessimistic case for a quality cable, giving 0.082 Ω per metre (copper at 1.7×10⁻⁸ Ω·m over a 0.51 mm conductor).
• Contacts: about 0.05 Ω per mated pair, two pairs in the power path (host receptacle and device plug) for clean contacts; oxide and dust only push this up.
• Current: 0.9 A - the module pulling its full allowance during boot.

The rule: the voltage the module sees equals the port voltage minus the loop drop, and the loop counts both conductors and both contact pairs.

The arithmetic:

• R_conductors = 2 × 3.0 m × 0.082 Ω/m = 0.49 Ω
• R_contacts = 2 × 0.05 Ω = 0.10 Ω
• R_loop = 0.49 Ω + 0.10 Ω = 0.59 Ω
• V_drop = 0.9 A × 0.59 Ω = 0.53 V
• V_device = 5.0 V − 0.53 V = 4.47 V

That 4.47 V sits about 0.02 V above the roughly 4.45 V floor the USB power rules leave a bus-powered device. At the full 900 mA this cable is already on the floor: one dusty receptacle, one extra metre, or one hub in the path pulls the module end below 4.45 V. The controller rides out the dip; the sensor board browns out mid-boot and never registers - the bootloader-visible, empty-list signature from the first section.

The decision: if the device-end voltage at your module's rated current computes under about 4.6 V, shorten the cable, clean or replace the connectors, or move the module to its own rated supply. Above 4.7 V you have real margin.

An unpowered hub makes this worse by division. One upstream budget of 0.9 A shared across four loaded downstream ports leaves 0.9 A ÷ 4 = 0.225 A each. A module that needs 0.9 A to boot cannot start from a 0.225 A slice - no cable quality rescues that, which is why step 1 removes the hub before anything else.

Then reload the module firmware

With the speed confirmed and the list still empty, the firmware image is the remaining software cause. Every thermal SDK ships a firmware-update utility for exactly this state - it reflashes the camera module's firmware over the same USB link - and the vendor documents the procedure. Run it from the proven port and cable, let it complete, read the firmware version back, then re-run the detection script. The discipline behind that sequence is the same one in the camera firmware update workflow from approval to readback, and the DFU update safety checks cover the power rules during the flash itself.

Version mismatch produces the same symptom from the other side: the bootloader answers, the camera never registers, because the host package expects a firmware release the module does not carry. Bring the host library and the module firmware to the same release before blaming hardware.

Swap test: separate the module from the host

With cable, power and firmware all proven, isolate the hardware. Put a second known-good camera on the same port and cable: if it enumerates and lists correctly, the port, cable and driver stack are fine and the first module is at fault. Then move the suspect module to a second computer: an empty list on every host, after a firmware reload, means the module or its carrier connection has failed and the unit needs service.

Board-level builds add one reseat before that verdict: power down, discharge yourself on a grounded surface - microbolometer modules are ESD-sensitive - reseat the module-to-carrier connector square, and re-run detection.

For the USB side of the swap, the LS-IRC-0016, a 640×512 LWIR module over USB3, slots into exactly this role:

If streaming work continues on this bench, taking USB out of the diagnosis entirely is often worth the change: GigE thermal cameras carry data over RJ45 and take power from a separate supply. Two GigE thermal cameras that replace the USB link with Ethernet and their own supply:

The LS-IRC-0044 streams 640 x 512 at 50 Hz over GigE and runs from a 9-24 V DC supply; the LS-IRC-0026 is a 0.5 MP thermal camera on the same interface. GigE brings its own failure modes under load, and streams that drop after the link comes up have their own fix plan for GigE dropouts.

Keep it from coming back

• One data-rated USB3.0 cable per module, fixed at 3 m or less, and never a phone-charger cable pressed into service.
• Direct motherboard ports; where distribution is unavoidable, a powered hub with per-port current budgets.
• Firmware version recorded next to each module and updated only alongside its matching host package.
• A spare known-good module on the shelf so the swap test takes minutes.
• A multimeter on Vbus at the module connector for stubborn cases: 4.45 V or more under load means the supply path is healthy.

Once the list fills, capture a first stream and record the firmware version and the port that worked - the next empty list then takes minutes instead of hours. If you are specifying hardware around this diagnosis, the infrared cameras category and the camera finder list the range, the camera cables page covers data-rated lengths, and the system configurator assembles the rest of the chain. In-stock items ship within one business day, and every camera carries a 3-year warranty minimum. The cameras topic page gathers the related guides, including exporting high-bitdepth grayscale images from thermal cameras for the step after frames flow.