UVC camera not detected: identify the device node first

Your capture program cannot see the camera, the viewer shows nothing, and the module is new out of the box — stop debugging the program and start at the operating system. A UVC camera, one that follows the USB Video Class, only becomes usable after the host has enumerated it and created a device node; every application sits on top of that node. This walkthrough runs that chain in order: find the node on Linux or Windows, read the formats and frame rates the camera really supports, then separate power, cable and bandwidth faults from a camera that is genuinely dead. Everything runs from a terminal or Device Manager, so you can work the whole sequence at the bench.

Which layer fails first when a UVC camera will not capture?

Work down the stack in order — USB link, operating-system node, camera format list, capture application — because software can only open a device node the kernel created, so a camera missing at the OS level is invisible to every program at once.

Test the four layers in this order:

1. Bus: is the camera listed by lsusb on Linux, or in Device Manager on Windows?
2. Driver and node: did the operating system create a /dev/video node, or a camera entry?
3. Formats: does the node list the resolution and frame rate your program asks for?
4. Application: does your program open that node with a format from the list?

A fault in the first three makes the camera fail identically in every program — that is the signature. If another viewer opens the same camera without trouble, layers one to three are healthy and the problem lives in your software's capture path; the UVC camera not detected by software: choose the right capture path guide walks that case on its own.

How do you find the camera's device node on Linux?

lsusb proves the camera reached the bus, and v4l2-ctl --list-devices proves the uvcvideo driver gave it a /dev/video node; check them in that order, and expect one capture node plus a second metadata node from most cameras.

1. Run lsusb and find the camera's line. Note the ID field — four hexadecimal digits for the vendor, four for the product. No line at all means the camera is not reaching the bus; jump to the power checks below.
2. Run v4l2-ctl --list-devices (install the v4l-utils package if the tool is missing). It prints every camera and the /dev/video nodes grouped under it.
3. Most cameras create two nodes: a capture node and a metadata node that carries frame timestamps. Only the capture node lists pixel formats, and that is the node your software must open.
4. Tell the two apart with v4l2-ctl -d /dev/video0 --list-formats-ext; the metadata node shows no formats at all.
5. If the node exists but opening fails with 'Permission denied', your user sits outside the group that owns video devices. The Linux camera device permissions: video and media node checks procedure clears that in a couple of minutes.

How do you list the resolutions and frame rates a UVC camera supports?

Run v4l2-ctl -d /dev/video0 --list-formats-ext and read the pixel formats, resolutions and frame intervals it prints: those discrete intervals are every frame rate the camera can deliver, and no software can combine a format with a rate the list does not show.

A shortened, typical listing for a 1080p-class module:

ioctl: VIDIOC_ENUM_FMT
[0]: 'MJPG' (Motion-JPEG, compressed)
    Size: Discrete 1920x1080
    Interval: 0.033s (30.000 fps)
[1]: 'YUYV' (YUYV 4:2:2)
    Size: Discrete 1280x720
    Interval: 0.033s (30.000 fps)
    Size: Discrete 640x480
    Interval: 0.033s (30.000 fps)

Read it as a menu of valid combinations. This camera delivers MJPEG at 1920 × 1080 at 30 fps, and uncompressed YUYV only up to 720p at 30 fps — and as the bandwidth arithmetic below shows, even that is too heavy for a USB 2.0 link, which is why the large frame sizes exist only as MJPEG. An interval of 0.033s is 30 fps; 0.040s is 25 fps. If your program asks for 30 fps at a size whose only interval is 0.040s, no setting will produce the missing frames.

Prove the node streams before blaming software:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=YUYV --stream-mmap --stream-count=30

The tool prints a running frame count and a measured frames-per-second figure, and any steady number confirms capture end to end. If that works but your viewer shows nothing, the decode side is missing plugins; the camera connected but viewer shows no video: GStreamer missing plugins guide covers that case. And if a capture library reports a frame rate of zero later on, the library's query is usually what failed — the video FPS returns zero in OpenCV: read frame rate reliably walkthrough shows a dependable way to read it.

Format lists also matter when you are buying rather than fixing. The LS-BCM-0003 is a 3.1 MP USB3 board-level camera rated at 120 fps with a 1/1.8" sensor and global shutter — check a line like that against your cycle time instead of trusting a driver to negotiate.

Where should a UVC camera appear in Windows Device Manager?

A healthy UVC camera appears under Cameras (Windows 10 and 11) or Imaging devices (older builds) with its own name or the generic label 'USB Video Device'; an entry under Other devices with a yellow mark means it enumerated but no class driver bound.

1. Open Device Manager: right-click the Start button and choose Device Manager.
2. Look under Cameras, or Imaging devices on older builds. The entry shows the camera's product name or the generic 'USB Video Device' label.
3. An entry under Other devices with a yellow mark means the camera enumerated but no driver bound to it. Note the code: code 10 (device cannot start) and code 28 (no driver installed) usually trace back to the link, so move the camera to a rear motherboard port before installing anything.
4. Prove capture with the built-in Camera app. A live picture there means enumeration, driver and streaming all work, and the fault is specific to your own program.

Windows ships a UVC class driver, so a compliant camera needs no vendor installation. If a standard UVC module only appears after you install a vendor package, suspect the port or the cable first, not the driver stack.

Why does the camera show in lsusb but create no /dev/video node?

That combination means the bus and the enumeration are fine but the kernel's UVC driver, uvcvideo, is not loaded or was never built into the kernel — common on slimmed-down embedded and industrial images that ship without USB Video Class support.

Three checks isolate it:

1. lsmod | grep uvcvideo — an empty result means the driver is not loaded.
2. sudo modprobe uvcvideo — 'module not found' here means the running kernel was built without USB Video Class support; the kernel switch is CONFIG_USB_VIDEO_CLASS. Slimmed-down embedded and industrial images leave it out.
3. sudo dmesg | grep -i uvc immediately after plugging in — a healthy probe prints a line like 'uvcvideo: Found UVC 1.00 device' followed by the camera's name. dmesg silent while lsusb still lists the device is the no-driver signature.

Loading the module solves the usual desktop case on the spot. On a custom or vendor-supplied embedded image the fix is a kernel rebuilt with the UVC class enabled; the walkthrough on fixing a UVC camera that is not recognized on a Linux CIP kernel shows the configuration path end to end.

How much USB power does a camera need, and when is the hub the fault?

A USB 2.0 port guarantees at most 2.5 W (500 mA at 5 V) and a USB 3.0 port 4.5 W (900 mA at 5 V); a camera that draws close to its port's limit on an unpowered hub browns out, drops off the bus and re-enumerates in a loop.

The arithmetic behind those budgets: 5 V × 0.5 A = 2.5 W on USB 2.0; 5 V × 0.9 A = 4.5 W on USB 3.0. An unpowered hub has nothing but its own upstream port to share — a 4.5 W USB 3.0 hub split across four downstream devices leaves about 1.1 W each, and many modules want more than that once the sensor streams.

Brown-out has a signature, and it differs from a dead camera: the device appears in lsusb and then vanishes, dmesg shows 'device descriptor read' errors, Windows plays connect chimes on a loop. Work cheapest first:

• Move the camera to a rear motherboard port, not a front-panel socket, a monitor passthrough or a keyboard port.
• Swap in a short, shielded cable.
• Put the camera on a powered hub, or give it a dedicated port.

Intermittent enumeration after a cable swap has its own deeper checklist in camera has power but not detected: USB link checks after a cable swap, and once several devices share a host, the multiple USB cameras on one host: bandwidth and power budget method keeps the totals in front of you.

How do you tell a bandwidth problem from a detection problem?

A detection fault leaves no device node at all; a bandwidth fault leaves a healthy node and format list but refuses to start the stream, usually with 'No space left on device' when VIDIOC_STREAMON cannot reserve isochronous bandwidth on the USB controller.

A USB 2.0 port reserves about 24 MB/s for isochronous video (protocol ceiling 24.6 MB/s); a USB 3.0 port carries roughly 400 MB/s in practice. Two computations from the format list earlier:

• YUYV, 1280 × 720 at 30 fps: 1280 × 720 × 2 = 1,843,200 bytes per frame; × 30 = 55.3 MB/s. That is more than double the USB 2.0 budget, so the host controller refuses the stream and the application sees 'No space left on device' (error ENOSPC) at VIDIOC_STREAMON.
• MJPEG, 1920 × 1080 at 30 fps, at a typical 8:1 compression: 1920 × 1080 × 2 = 4,147,200 bytes uncompressed; ÷ 8 ≈ 15.5 MB/s. That fits under 24 MB/s — which is why the large frame sizes only exist as MJPEG. If you want to know why a module is built that way, the sensor-and-bridge choices behind a format list are explained in this guide to building a USB UVC MJPEG camera.

On USB 3.0 the picture flips: uncompressed 1920 × 1080 at 30 fps needs 4,147,200 × 30 = 124 MB/s, comfortably inside 400 MB/s.

Decisions that follow:

• Camera stuck on a USB 2.0 port: select MJPEG, or drop to 640 × 480 YUYV (640 × 480 × 2 × 30 = 18.4 MB/s).
• You need uncompressed frames at full size: move the camera to a USB 3.0 port.
• Several cameras on one controller share that controller's budget; the USB hub drops camera frame rate: budget the bandwidth first guide shows how to add the numbers up before they fail on the floor.

When is the camera itself dead, and what do you fit instead?

A camera that fails to appear on a second cable, a second port and a second computer has a hardware fault — replace it; everything you can fix lives in the cable, the port, the hub, the driver or the format you asked for.

Run three swaps and log the result of each:

• Second cable — the first swap to try, and the most common cure for a 'dead' camera.
• Second port, ideally fed by a different controller: rules out the port rather than the camera.
• Second computer: rules out the host's driver stack completely.

If the conclusion is a replacement, USB board-level modules are what the inside of an enclosure wants: small, single cable, no frame grabber. The board level camera selection for embedded vision machines guide sorts the sensor and interface choices, and the board-level cameras category lists the current range.

Compact USB3 board-level cameras suited to small enclosures:

When the job needs uncompressed full-resolution frames, hardware triggering or longer runs, step up to the machine-vision class: area scan cameras speak vendor SDK protocols rather than the UVC class, so plan the software stack alongside the camera. The camera finder filters by interface, resolution and shutter, and the camera step of the configurator pairs the camera with a lens and light once the capture path is proven. The rest of the device-detection and USB checks sit on the systems topic page.