Depth camera stuck at low resolution: check for a real USB 3.0 port

A depth camera that streams happily at 640 × 480 but refuses every higher mode is not a broken camera; it is a camera on the wrong bus. USB 2.0's 480 Mbit/s cannot carry a modern stereo pair at full rate, so the firmware quietly restricts you to the modes that fit. The symptom looks like a software fault, and it burns commissioning days on settings, SDK versions and GPU drivers before anyone checks the port. This guide is for anyone commissioning or rescuing a USB depth camera on a production line or test bench. You will compute the bandwidth your mode needs, prove which link the camera is actually on, fix the port and cable path, and set acceptance checks so the fallback cannot return. Every check takes minutes and needs nothing but the SDK you already have.

Why does a depth camera only offer VGA on one computer and 1080p on another?

Because that computer connects the camera over USB 2.0: a 480 Mbit/s bus cannot carry a 1080p stereo pair at 30 fps, which needs about 995 Mbit/s, so the camera's firmware never opens the higher modes.

The mode list is settled when the camera enumerates, not when you change a setting. A host controller that reports a high-speed device tells the SDK the bus budget, and the SDK then greys out, downgrades or refuses every mode that does not fit — which is why the menu stops around VGA. The camera itself is fine. Move the same unit to a machine with a true SuperSpeed port and the full mode list appears, because the fault follows the port, not the camera. That split test is the fastest diagnostic in the whole problem.

The resolution modes themselves — why a sensor lists a few fixed sizes instead of arbitrary ones — are covered separately in why a USB camera gets stuck at 4K.

How much USB bandwidth does a stereo depth camera actually need?

Multiply width × height × bits per pixel × streams × fps: a 1080p mono pair at 30 fps needs 995 Mbit/s, a VGA pair needs 147 Mbit/s, and a USB 2.0 link pays at most about 384 Mbit/s.

USB 2.0 (High-Speed) signals at 480 Mbit/s, and the protocol reserves a fifth of the bus for control traffic, capping isochronous video at 384 Mbit/s; a practical stack delivers 320 Mbit/s or a little more. USB 3.0 (SuperSpeed) signals at 5 Gbit/s, and its 8b/10b encoding leaves 4 Gbit/s of payload, roughly 3.2–3.8 Gbit/s once link overhead is paid.

Add depth and color and the bill roughly triples: 56 bits per pixel across two images, the depth map and the color frame costs 116.1 Mbit per 1080p frame, or 3.48 Gbit/s at 30 fps — right at the practical USB 3.0 ceiling. Halve the frame rate and you halve the bill: the full mix at 15 fps is 1.74 Gbit/s and fits with margin. These figures assume uncompressed streaming, which is how depth SDKs move live frames; a compressed recording format changes the numbers on disk, not on the wire.

A link that opens a mode but cannot sustain it shows up later as falling frame rates: why camera fps drops suddenly ties that symptom to link bandwidth and exposure.

Is your blue USB port actually USB 3.0?

Not always: blue is a color the connector maker chose, while a genuine USB 3.0 port carries the SuperSpeed logo — the letters SS — beside the receptacle, and a port without that mark may be USB 2.0 wiring in a blue shell.

The USB 3.0 specification recommends a blue tongue for SuperSpeed receptacles but does not require it, and vendors have shipped blue USB 2.0 ports for years. Two traps cover most cases. On laptops, a blue port can predate the controller that funds SuperSpeed and be wired for high speed only. On desktops, the front-panel receptacle sits on the case while its speed is set by the internal header someone connected to the motherboard: a USB 3.0 receptacle on a USB 2.0 header enumerates at 480 Mbit/s without complaint.

On a desktop with no SuperSpeed ports at all, a PCIe USB 3.0 add-in card is a permanent fix that takes minutes to fit.

Does the cable matter, or only the port?

Both: a USB 2.0 cable physically lacks the extra twisted pairs that carry SuperSpeed data, so plugging the camera in through one caps the link at 480 Mbit/s even from a genuine USB 3.0 port.

SuperSpeed lives in the cable as much as in the port, and it is easy to lose: a phone charge cable, a spare from a drawer, or a run past its length limit all drag the link down. Look for the SS marking printed on the connector molding. Length is the second limit — about 3 m is the working figure for passive copper, beyond which you move to active or optical cable. USB-C systems add their own cable lottery, and USB-C cable timeouts on a USB3 camera covers the length and data-rate traps, while the USB cable length limits for 3D cameras gives working distances per cable type.

The quickest cable test is a swap for one known to carry SuperSpeed, then read the negotiated speed again; a camera that still misbehaves after the swap has deeper link checks waiting in the USB fault-finding checklist after a cable swap. Marked, machine-vision-grade cables live in the camera cables category, filterable by length in the accessories finder.

For a camera bolted to a bracket or riding a moving axis, fit a cable built for the job:

The 3 m USB3.0 high-flex camera cable is drag-chain rated, which is exactly what a cable on a moving axis needs.

How do you confirm the negotiated speed before blaming the camera?

Read the speed from the host, not the sticker: on Linux, lsusb -t prints each device's negotiated speed (480 M for USB 2.0, 5000 M for USB 3.0), and most depth SDKs report the active resolution or link speed in their status line.

That readout is the whole diagnosis. If the camera enumerates at 480 M on a port you believe is SuperSpeed, the port, the header behind it or the cable is lying. Why a USB3 camera negotiates USB2 speed walks the Linux check line by line. Then run the five-minute pass:

1. Plug the camera into an SS-marked port directly on the host, with no hub in between.
2. Request the target mode in the SDK and read back the resolution and frame rate the camera actually reports; a downgrade to VGA here is the bus talking, not the sensor.
3. Cross-check the speed with lsusb -t on Linux.
4. Swap in an SS-marked cable and read again.
5. Try a second port or a second computer; a camera that offers 1080p elsewhere is exonerated.

Virtual machines deserve their own suspicion: USB passthrough often re-enumerates a device at the wrong speed or starves isochronous streams, and the fix for a depth camera color stream timeout in a VM starts by testing the same camera on the bare host.

Are the viewer's rendering errors a separate fault?

Yes: errors about shader source code, unsupported GLSL versions, inverted colors or a corrupted preview come from the viewer drawing on your GPU, and they do not limit which resolutions the camera can stream.

Keep the two faults apart, because they are fixed in different places. A viewer that renders through OpenGL needs a graphics stack recent enough for its shaders; an older integrated GPU or a stale driver fails with shader compile errors while the camera stream itself is perfectly healthy. Update the graphics driver, or run the capture headless through the SDK's API and skip the preview — recording proceeds regardless of what the window shows. Meanwhile, a resolution cap points at the bus, and no GPU driver will lift it. Fixing one never fixes the other, and chasing the wrong one is how a five-minute port check turns into a week of reinstalls.

What can you do if the port really is USB 2.0?

Either give the camera a SuperSpeed path or give it less data to carry: move to a root port with the SS mark, add a PCIe USB 3.0 card, or drop fps, resolution or ROI until the bill fits the 320–384 Mbit/s a USB 2.0 link can pay.

Match the response to the mode, using the table above. If the task runs at VGA 30 fps or 720p 15 fps, a USB 2.0 link carries it with margin — reduce the mode and move on; running a depth camera at low fps to cut CPU load shows how little many applications actually lose. If the task needs 1080p at 30 fps, no tuning fits 995 Mbit/s into 384 Mbit/s, so change the path: a rear port with the SS mark, a PCIe USB 3.0 add-in card, or a powered SuperSpeed hub — remembering that one upstream link still sets the ceiling for everything downstream.

ROI is the other reducer. Streaming a sub-window or a narrow depth band cuts pixels before they become bits, and configuring a one-inch z-layer scan on a depth camera is a worked example of paying only for the depth you inspect.

Two or more cameras on one controller share its bus, so two 1080p pairs double a bill that was already too big; why three depth cameras drop to low FPS shows the one-stream-at-a-time method for proving which camera overruns. When distance or data volume outgrows USB entirely, the standard answer is a different interface class: industrial 3D sensors commonly speak GigE, which sustains 1 Gbit/s over 100 m of one cable, and 5GBASE-T camera interfaces extend that idea where 4K or high frame rates are involved. Shortlist by interface and working distance in the 3D sensors category, not by resolution alone.

The 3 m GigE high-flex camera cable is the drag-chain counterpart once a camera moves to a GigE interface.

Choosing the camera and the host together beats rescuing them later:

How do you stop this fallback coming back on the next station?

Make the link part of the commissioning checklist: specify SS-marked ports on the host, SS-marked cables in the bill of materials, and record the negotiated speed in the acceptance test so a swapped hub or cable shows up at hand-over.

• Specify the port, not just the PC: the words USB 3.0 on a purchase line are only proven by the speed readout at commissioning.
• Put SS-marked cables in the bill of materials and secure the run; a drawer cable will find its way back.
• Keep cameras off hubs and front-panel headers unless each path has passed the speed readout.
• Keep 20% headroom under the link's payload: a mode that needs 3.48 Gbit/s on a link delivering 3.2 Gbit/s passes the demo and fails the shift.

The whole diagnosis is one line long: read the negotiated speed. 480 M means a USB 2.0 path, and the mode list stays short until the path changes; 5000 M means the higher modes open and any remaining problem lives elsewhere. If you are specifying a new station, pick the camera and the link together in the camera finder, or send the setup through the contact page and we will run the bandwidth budget with you. More fault-finding in this series is filed on the 3D imaging topic page.