USB extension cable fails only when you record the depth stream

Your depth camera streams fine through the USB extension in the viewer, then the same link dies the moment you record the depth stream to disk — while the short, supplied cable runs the recorder without complaint. That pattern is not a software bug. It is a link that carries a best-effort viewer session but cannot sustain an every-frame recording run. This page gives you the bandwidth number the extension must carry, the three causes in order of probability, a swap test that isolates the fault in about ten minutes, and the fix: a short data-rated USB 3 cable, a USB 3-rated active extension for longer runs, or a different interface when the distance is fixed. The procedure applies to any USB3 depth or stereo camera on Ubuntu or Windows.

Why the viewer passes and the recorder fails

The extension is usually failing in both runs. Only one run makes it visible.

A viewer is best-effort: it renders whatever buffer arrives and quietly skips the ones that never do, so a link with occasional retries still shows a live image. A save-to-disk run must write every frame — the first lost buffer or bus reset becomes a timeout, and the run stops with an error. Three mechanisms produce the exact symptom you are seeing:

• Mode fallback. An extension wired for USB 2.0 (480 Mbit/s) can enumerate the camera and open a lighter depth mode for viewing, while a request for full-rate depth cannot fit and fails outright.
• Hidden drops. Signal-integrity retries and occasional port resets cost frames the viewer never reports and the recorder cannot survive.
• Sustained load. A recording session holds the link near 100% for minutes, which is when a marginal link accumulates errors; a short viewer session ends before it gets there.

You already hold the decisive evidence: the same recorder on the supplied cable passes. Hold the software, port and camera constant, and the extension is the variable.

The bandwidth the extension must carry

Compute the stream rate first; it decides everything that follows.

Worked example — a common depth mode of 1280 × 720 pixels, 16-bit (2 bytes per pixel) at 30 fps:

• 1280 × 720 = 921,600 pixels per frame
• 921,600 × 2 B = 1,843,200 B ≈ 1.84 MB per frame
• 1.84 MB × 30 fps = 55.3 MB/s, or 442 Mbit/s before packet overhead

Budget about 60 MB/s once protocol overhead is included.

Compare that with what each link sustains in practice — line rate minus encoding and protocol overhead:

The USB 2.0 row explains the failure: 480 Mbit/s is 60 MB/s in theory, 8b/10b encoding removes 20%, and handshake overhead takes most of the rest, leaving 35-40 MB/s for bulk data. A compressed color stream explains the other half: Motion JPEG typically moves 5-20× less data than the same video uncompressed, so color rides on a link that raw depth saturates.

Likely causes, in order of probability

Work them top to bottom. Each has a test that needs no tools beyond the terminal.

1. The extension is wired for USB 2.0 data

Cords marketed for charging often carry the USB 2.0 pairs only, whatever the connectors look like. The camera enumerates, the viewer opens a stream that fits, and full-rate depth does not. Read the negotiated speed: on Ubuntu, lsusb -t lists every device with its link speed, where 5000M is a USB 3 link and 480M is USB 2.0. Run it through the extension, then on the supplied cable. A different speed is the whole diagnosis. Check the host port too — a front-panel header or an unpowered hub can cap a capable camera at 480M on its own, which is why a real USB 3.0 port matters for depth cameras.

2. Marginal signal integrity under sustained load

A long passive run at the edge of the USB 3 signal eye works at first, then accumulates link errors under minutes of full-rate traffic until the host resets the port. The viewer shrugs off a reset; the recorder aborts on it. Check the kernel log (dmesg) at the failure timestamps: USB reset or device-descriptor-read error lines from usbcore are the signature. Then run the viewer through the extension for the same duration as a recording session and count dropped frames — any nonzero count disqualifies the cable for recording duty. On a USB-C camera the plug, the cable rating and the length interact; USB-C cable timeouts on a USB3 camera: length and data rate works through that pair.

3. Power droop on thin conductors

A depth camera's illuminator draws current peaks on top of the data load. Charge-oriented extensions use thin power conductors, so voltage at the camera sags when emitter and stream run at full duty, and the camera browns out mid-run. The signature is re-enumeration: the device disappears and returns — a new device entry, a disconnect message in the viewer — at the moment the recorder dies. If the direct cable never re-enumerates over the same run, the extension's power path is the problem. Camera has power but not detected: USB link checks after a cable swap gives the full check sequence for exactly this situation.

Isolate it in about ten minutes: the swap test

Change one variable at a time and keep the same host port throughout:

1. Run the recorder on the supplied short cable for ten minutes at full rate. This is the control; it should pass clean.
2. Read the negotiated speed on the direct link with lsusb -t and note it.
3. Move to the extension and repeat the ten-minute recorder run.
4. Read the negotiated speed again through the extension.
5. Run the viewer through the extension for the same ten minutes and count dropped frames or disconnects.

Decision rule: a speed change between steps 2 and 4 (5000M → 480M) means USB 2.0 wiring. Same speed with accumulating drops means signal integrity. A re-enumeration mid-run means power. You now know which fix to buy.

The fix: shorten, re-drive, or change interface

Shorten first. About 3 m is what passive copper USB 3 reliably guarantees, and a 55 MB/s stream sits comfortably inside a healthy link of that length, so treat 3 m as the limit that needs no test. Replace the extension with one data-rated USB 3 cable at the shortest length that reaches — the LS-CBL-0219 is a 3 m USB3.0 camera cable with a high-flex, drag-chain build for moving axes.

Re-drive for longer runs. Beyond 3 m passive, use an active extension explicitly rated for USB 3 data — a re-driver or optical design that restores the signal eye, not a charge-rated cord that repeats the same failure. Treat 5 m active as the working budget for a full-rate depth camera, soak-test anything longer at the installed length, and read the negotiated speed once it is plugged in. Stretched USB fails the same way at any scale; this 100-foot USB cable extension walkthrough covers those failure modes for measurement hardware.

Change the interface when the distance is fixed. If the camera must sit 10 m away or more, stop stretching USB and specify a GigE Vision camera for that station: GigE carries your 55 MB/s stream over 100 m of Cat 5e or better. The camera data cables range includes 15 m RJ45 builds with locking studs, such as the LS-CBL-0117, for exactly these runs — and when you specify the next station, the 3D sensors category covers laser profilers and stereo cameras built around fixed, longer links.

A powered hub only fixes the power cause. It re-drives the 5 V rail so the illuminator stops browning out, but it repairs neither USB 2.0 wiring nor a marginal data link — and it adds a hop you must budget. USB hub drops camera frame rate: budget the bandwidth first shows how to make that budget.

Prove it, then keep it fixed

Repeat the ten-minute soak on the new cable at full rate to disk: zero dropped frames, zero re-enumerations, negotiated speed unchanged. Write the numbers next to the station — stream rate, cable build, negotiated speed — so nobody rediscovers them mid-shift.

• One cable, one run: never daisy-chain two extensions.
• Buy data-rated cable at fixed lengths and label the drawer with the rating, not the length alone.
• On moving axes, use drag-chain builds and route clear of motor cables.
• Re-check lsusb -t after any replug or port change.
• Adding a second camera means re-budgeting: two 55 MB/s streams fit one USB 3 root port in theory but not through a shared hub. Depth and color stream timeouts: the USB bandwidth check walks the budget, and USB cable length limits for 3D cameras covers the length side.

Not sure which build fits your camera and run? The cables finder filters by interface and length, or start the system configurator at the cabling step.

If the direct cable fails too

Then the extension was never the variable — check the save path. A recording run needs the full 55 MB/s sustained at the disk: a network mount, a USB stick or a nearly full drive fails the same way the extension did. Move the target to a local SSD and rerun. If it still fails on the supplied cable, the camera's stream configuration is the next suspect, not the cabling.