Frames didn't arrive within 5 seconds: fix the stale USB session

Your depth camera node starts cleanly and then delivers nothing. The log prints the device name, serial number and firmware version, marks four streams as enabled, and five seconds later warns that no frames arrived. Two other warnings — failed busnum/devnum reads and a list of unregistered media formats — make the camera look broken. It almost never is. This page is for engineers bringing up a USB 3 depth camera on an embedded Linux host. You will learn which warnings to ignore, how to clear the stale USB session that actually blocks the frames, how to verify the stream with a rate check, and how to keep the fault from returning.

Why does my depth camera warn 'Failed to read busnum/devnum'?

Ignore it. That warning names the board's own IIO devices, not your camera: on the embedded modules this fault was first logged against, the entries /sys/bus/iio/devices/iio:device0 through iio:device3 belong to the ina3221x power monitor, which sits on an internal bus with no busnum or devnum attributes to read.

The camera SDK scans sysfs for every device it can attach and assumes each entry carries busnum and devnum files; the power monitor is on an internal I2C bus that advertises none, so the library warns and moves on. Your camera is not mentioned, keeps enumerating, and streams normally once the real fault is cleared. Expect the warning in every run, including the healthy ones, and spend no time on it.

What does 'frames didn't arrive within 5 seconds' mean for a depth camera?

The camera is present but silent: the host read its serial number and firmware over the control endpoint, so enumeration succeeded, yet no image frame crossed the data endpoints within the 5-second wait, which almost always means a previous session was never properly closed.

The SDK prints the warning as 'Frames didn't arrived within 5 seconds', and the API surfaces the same wait as 'Frame didn't arrived within 5000' — five thousand milliseconds, the same five seconds. Sort it from its neighbours before fixing anything. A camera that never enumerates at all is a detection fault; check the USB power budget first. A camera that enumerates and then goes quiet holds a stale session. In order of how often each turns out to be the cause:

1. A stale USB session from an earlier run that exited abnormally — cleared by a power cycle.
2. A host kernel or USB host-driver defect — fixed by updating the board support package.
3. A marginal link — cable length, a bus-powered hub, or a shared controller out of bandwidth.
4. A failed camera — the last suspicion, confirmed only by isolation on a second computer.

How do I get depth frames flowing again right now?

A full power cycle clears the stale session: unplug the camera's USB lead at either end, wait ten seconds, replug, and relaunch — it is the vendor's own workaround, and the first fix to try every time the timeout appears.

1. Stop the node and close any viewer or test program that holds the device.
2. Unplug the lead at the camera end or the host end — either breaks the electrical session.
3. Wait ten seconds so the supply capacitors discharge and the host controller retires the old device handle.
4. Replug and check the kernel log: a new SuperSpeed device means the link returned at 5 Gbit/s; a 480 Mbit/s entry means it fell back to USB 2.0.
5. Start the node and confirm the rate as in the next section.

When the camera is bolted inside a guarded cell, replug by proxy: the three ways to power cycle a USB camera remotely cover switched hubs and software resets, and the software reset that revives a depth camera after power loss needs no extra hardware. If neither is available, stop the node completely and relaunch — on many setups the second run publishes while the first starves, but treat the replug as the reliable fix.

How do I prove frames are arriving before I launch my application?

Check the message rate on the depth topic before you start your subscriber: a 640 x 480 stream configured at 30 fps must settle at about 30 Hz, and a rate near zero means the session is still stale.

On a headless host there is no viewer window, so the rate check is the proof. Start the node, then run:

rostopic hz /camera/depth/image_raw

Read the number like this:

• About 30 Hz: session cleared, link healthy — launch your application.
• Near 0 Hz: still stale; go back to the power cycle.
• Around half the target: frames are being dropped on the link; go to the bandwidth budget below.
• A rate that collapses under load: the controller cannot carry the stream set; see the worked example below before adding cameras.

Why does the camera work on the second run?

Because the first run died without releasing the USB interface, and stopping the node tears the stale handles down: a clean shutdown or your kill signal closes the endpoints the crashed session left reserved, so the second launch streams while the first one starves.

An abnormal exit — Ctrl-C mid-stream, a crashed subscriber, or the reconfigure exception that follows the timeout — leaves the interface claimed, and the cleanup that releases it often never runs. Two habits follow. Close nodes with a clean shutdown rather than killing the process group, and treat 'works on the second try' as the stale-session signature, not a quirk to live with. Watch also for the cousin symptom, frames that arrive on schedule but never change: the fixes for depth camera frames not updating cover the bandwidth side, and if your code reads seconds-old frames out of the SDK's queue, configure the queue-overwrite behaviour it exposes — this walkthrough of queue overwrite for stale frames shows the pattern end to end.

What stops the 5-second timeout from coming back?

Fix the two host-side weaknesses behind this fault: run the board's current kernel and USB host drivers, whose stability defects were fixed in the support-package release after the one your board shipped with, and give the camera its own root USB 3 port with a short, known-good cable.

Work down the list once; each item removes a condition the stale session needs.

• Update the board support package first. The timeout was first logged against a 2017-era kernel whose host controller dropped transfers under load; the next release fixed it. After any kernel update, re-run your camera SDK's kernel patch step so its stream modules match the new headers.
• Dedicate a root port. Plug the camera into the host directly, not into a bus-powered hub: a USB 3.0 port supplies up to 900 mA at 5 V (4.5 W) for the camera and its illuminator, and a hub splits that budget across every device on it.
• Keep the lead short. Passive copper USB 3 holds SuperSpeed reliably to about 3 m; beyond that, packet errors climb and the stream-stall behaviour returns.
• Isolate a weak root controller. Where the board's own controller drops packets under load, a PCIe USB 3.0 host controller card takes the camera off it — the change that made one stubborn install stable. Budget bandwidth before sharing a controller between cameras, as in multiple depth cameras on one host.

For a camera on a moving stage or in a drag chain, use a lead built for it:

A molded, high-flex USB 3 lead also survives the repeated replug cycles of bring-up better than a stiff patch cable.

Could the cable, power or bandwidth be to blame instead?

Only when a fresh session still cannot stream do the cable, the port's power and the bandwidth come into play, and the kernel log separates them: a 480 Mbit/s line rate condemns the link outright, while repeated 'Empty frame has arrived' warnings point at power or bandwidth.

Work the bandwidth budget once, for the stream set you actually run. The install this fault was logged with streamed four feeds at 640 x 480 and 30 fps, all 16 bits deep:

USB 3.0's 5 Gbit/s line carries 590 Mbit/s with roughly a five-fold margin even after protocol overhead, so a healthy SuperSpeed link is never the limit. A 480 Mbit/s USB 2.0 link cannot carry the set at all — if the kernel logged the camera at 480 Mbit/s, no session fix will help until the link is restored; start with the fixes for a camera enumerating as USB 2.0 on a USB 3.0 port. A marginal cable passes enumeration — its control traffic is tiny — and fails only under streaming load; the USB extension cable that fails only when the depth stream is recorded is that failure in its purest form, because recording pushes the total toward the line limit. Power behaves the same way: the illuminator's surge can brown out a port that idles happily, exactly the depth camera that disconnects when the IR stream starts.

When is the camera itself dead and due for replacement?

Suspect hardware only after a known-good cable, a root USB 3 port and a full power cycle on a second computer reproduce the same silence, or when the host cannot read the device descriptor at all — that combination marks an electrically failed camera, not a software fault.

The isolation takes ten minutes: short known-good lead, root port, power-cycle, then the same three on another computer. A camera that stays silent through all four steps, or one whose host logs device descriptor request failed, has failed electrically — replace it rather than fighting the session. The MV-DT01WMU ToF sensing camera from the 3D sensors range is a current depth camera to put in its place:

Which fix applies to which symptom?

Map the log line to the action: ignore the IIO warning, power-cycle on the first timeout, update the kernel and re-cable when the timeout repeats every boot, chase the link when empty frames survive a replug, and replace the camera only on descriptor failure after clean isolation.

• busnum/devnum warnings, frames flowing: nothing to do; the warning belongs to the board's power monitor.
• Timeout on the first run, frames on the second: stale session; power-cycle before launch and apply the prevention list.
• Timeout after every reboot: update the board support package, re-run the SDK kernel patches, then retest on a root port with a short lead.
• 480 Mbit/s or empty frames after a replug: physical link; replace the cable, move to a root port, check the bandwidth budget.
• Descriptor failure or silence on a second computer: the camera has failed; replace it.

If you are specifying parts for a new cell instead of rescuing this one, the camera data cables category pairs a lead with your camera, and the cable step of the vision system configurator walks the whole chain. The neighbouring fixes — detection, bandwidth, power, multi-camera bring-up — are collected on the 3D camera topic page, and for a stubborn install you can contact the applications team.