The camera enumerates, and that is the trap. The OS lists it, dmesg prints the product strings, a viewer may even show a color frame — and the depth SDK still refuses to open anything. One line up in the kernel log sits the cause in plain text: SerialNumber: FFFFFFFFFFFFFFFF. A serial made only of hex F is not a setting, not a driver problem and not a cable problem; it is the camera's factory identity data reading back erased. This page shows you how to read that line on Linux and Windows, how to separate the erased-identity fault from firmware-update mode, a failing link and a stale device entry, and what to do for each. The decision up front: an all-FF serial confirmed on a second host means replace the camera under warranty. No software fix exists.
What an all-FF serial number actually is
Every USB camera carries three string descriptors: manufacturer, product and serial. On plug-in, dmesg prints the string indices — the Mfr=1, Product=2, SerialNumber=3 line — and then the strings themselves. The manufacturer and product strings come from the running firmware, which is why they still print normally on a sick camera. The serial comes from somewhere else: an identity store programmed once at the factory, with a fixture, before the housing was closed.
Flash and EEPROM memory erases to all ones: every bit at 1, every byte at 0xFF. A serial of nothing but hex F is what erased storage reads back; it is not a value anyone set. When a camera that enumerated with its real serial last week now prints sixteen F characters, the identity store has lost its data. The descriptor table is intact, the firmware runs, the USB link is up — one component failed.
The log usually shows the firmware struggling as well. uvcvideo printing Failed to set UVC probe control : -32 (exp. 48) is errno 32, EPIPE: the device answered a control request with a STALL instead of the 48-byte negotiation structure a UVC 1.5 camera owes. Enumeration and streaming are separate stages, and on this camera the second stage is dead.
Four causes in order of probability
The signatures differ in one or two log lines, and the table reads them apart:
| What you see | Cause | Test | Outcome |
|---|---|---|---|
| Serial reads all F, product ID matches the model, same on every host | Erased identity store (hardware) | Re-read on a second host with a second cable | Replace the camera |
| Camera present but its USB product ID differs from the model's normal value | Stuck in firmware-update mode | Compare the reported ID with the known one | Recover with the vendor's update procedure |
| Device appears, resets and drops off the bus; no stable serial at all | Cable, power or link fault | Swap cable and port, watch the log for resets | Fix the link; the serial reads normally again |
| OS lists the camera, the SDK finds nothing | Stale device entry or driver state | Remove and reinstall the device entry, replug | Camera opens normally |
A changed product ID is the signature of update mode, not of identity loss: read the USB ID a stuck camera reports and compare it with the model's known value before condemning hardware. If the OS lists the camera and the SDK still finds nothing, work through the lsusb-but-not-detected checks first — a stale device entry imitates a dead camera down to the failed open call.
Worked example: FFFFFFFFFFFFFFFF in dmesg on Ubuntu 20.04
The inputs: a depth camera that captured for a couple of hours across three days, then never opened again; it was tried on three Ubuntu hosts, two Windows hosts and two known-good USB-C cables. On plug-in, dmesg prints:
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: SerialNumber: FFFFFFFFFFFFFFFF
The product and manufacturer lines still carry the model's normal strings. Only the serial reads back as sixteen hex F characters, identical on every host.
The rule, in words: erased flash reads all ones, and a factory serial is unique data written once. An all-ones string is therefore the erased state of the identity store, not a serial number.
Sixteen F characters are sixty-four set bits. Even if serial numbers were handed out at random, the chance of a genuine unit reading all ones is about 5.4 × 10^-20 — and serials are assigned values, not random ones. The string is the erased state of the memory.
Decision: replace the camera. A unit that ran for days, then lost its identity across five hosts and two cables with the product ID unchanged, is an electrical or wear-out failure of one memory component — the exact case a warranty claim exists for. There is no threshold to wait for and nothing further to run.
Confirm it in five steps
-
Read the serial at USB level. On Linux,
lsusblists the camera's vendor:product pair andlsusb -vprintsiSerialNumber; dmesg — the kernel ring buffer — prints theSerialNumberline at every plug-in. On Windows, open Device Manager, the camera's Properties, the Details tab, then Device instance path: its tail is the serial string the camera reported. - Check the product ID. It must still match the model's normal ID. An unchanged ID with an all-FF serial is identity loss; a changed ID is update mode, which is recoverable.
- Second host, second cable. A failing USB link produces resets and disconnects in the log, never a stable all-FF descriptor string. If the link enumerates at SuperSpeed and prints the same sixteen F characters again, the string came from the camera, not the wire. For how far a cable can run before the link itself becomes the suspect, see USB cable length limits for 3D cameras.
- Run the vendor viewer once. It fails to open the device even though the OS lists it. A generic UVC viewer may still render the color stream; that exercises one endpoint and does not contradict the diagnosis.
- Book the return with the readings attached. Record the product ID, the serial string and the two-host check, then start the return — through our contact page if the camera came from us, or your own vendor otherwise.
Why there is no software fix
The identity store is written once, at the end of the production line, by a fixture that talks to the memory directly. Over USB, the serial is a descriptor the host reads; nothing in the interface lets a host write it. Driver reinstalls, OS changes and cable swaps act on the link and the host side, none of which holds the missing data.
A firmware update does not reach it either. An update utility writes the application firmware image, and before it writes anything it must open the device — the step that fails, on Windows with 0x8007001f, "a device attached to the system is not functioning", and on Linux with the open error the SDK prints. Nothing is written, so repeated attempts only burn days inside the return window.
Replacing the camera
Order like for like: keep the interface, the depth principle and the working range your station was designed around, and let the finder do the filtering. The 3D sensors category splits into laser profilers, stereo and structured-light cameras, volume cameras and ToF, so the failed unit's type leads straight to a shortlist.
Laser profilers and stereo 3D cameras
170 models · from $699.00When the replacement arrives, read its serial before first power-on and file it with the station's records. Cameras we sell carry a 3-year warranty minimum, in-stock items ship within one business day, and returns stay open for 90 days — a fault like this, caught early in service, is a straightforward return rather than a project. If the failure is the prompt to re-spec the station anyway, start at the camera finder or the configurator.
Multi-camera cells need one more step: a serial-per-station register. Depth SDKs address cameras by serial number, and a cell that opens four cameras by recorded serial will not start while one unit answers with all F. Selecting each camera by serial number shows the mechanism the fault breaks. With the register, you pull the failed unit from the bus, confirm the rest enumerate with their recorded serials, and keep producing while the return runs.
Prevention: catch it at commissioning
- Record the serial on day one. Paste the dmesg line or photograph the label into the station file; it is the evidence a warranty claim turns on.
- Run a two-hour capture burn-in before acceptance. Memory faults of this kind surface in the first hours of real operation, while the unit is still inside the 90-day return window.
- Re-read the serial after every firmware update. An update must never change it; a changed or all-FF serial means the identity memory was already failing. When an update is due, follow the safe firmware update procedure.
- Check the register at every maintenance visit. One missing serial is a five-minute swap; an all-F serial found three months into a contract is a line stop.
The decision, once more: a normal product ID plus an all-FF serial on a second host is a hardware fault — replace the camera and move on. For the rest of depth-camera integration, the 3D topic page collects the guides.
Questions
Can a firmware update rewrite an all-FF serial number?
No. The update utility writes the application firmware image; the serial lives in a separate identity store programmed once at the factory, and the USB interface only reads it. With the identity unreadable, the update tool fails while opening the device and writes nothing, so repeated attempts cannot succeed. The only repair is a replacement unit.
Does an all-FF serial number mean the camera is counterfeit?
Usually not. A counterfeit unit would normally show a copied or plausible serial; an all-FF string is the erased state of the identity store, which genuine units reach through an electrical or wear-out failure of that one memory. Judge by the rest of the unit: a correct product ID and product strings on a camera from a legitimate channel point to failed memory, not a fake.
Why does the color stream still work in a generic viewer?
The color sensor hangs off a standard UVC interface that still runs from the camera's firmware, so a generic viewer can render it. The depth stack is different: the SDK opens the device by serial and reads vendor-specific interfaces that depend on the identity data, and those calls fail. A working preview tests one endpoint, not the camera; the all-FF serial still means replacement.
How do I read the serial on Windows without the SDK?
Open Device Manager, open the camera's Properties, then the Details tab, and select Device instance path. Windows builds that path from the vendor ID, the product ID and the serial string the device reported at enumeration, so the tail of the path is the serial at USB level. An all-F tail there matches the dmesg finding and confirms the diagnosis without the SDK.
One camera in a four-camera cell lost its serial — why do the others stop too?
Depth SDKs address cameras by serial number. When one unit reports an all-FF serial, serial-keyed enumeration can fail or collide, and the whole cell's start-up breaks even though the other units are healthy. Remove the failed camera from the bus, confirm the rest enumerate with their recorded serials, and send the failed unit back under warranty.