OAK-D Lite connects at USB SuperSpeed but OAK Viewer reports “Not enough power”

AdamEhrlich

Hello,

I’m having trouble using my OAK-D Lite with OAK Viewer and would appreciate help determining whether this is a USB/power issue, an OAK Viewer issue, or a configuration problem.

System information:

Camera: OAK-D Lite, fixed-focus model
Computer: Alienware x15 R2
Operating system: Ubuntu 24.04.4 LTS
OAK Viewer version: 3.8.2, installed from the Linux .deb package
Connection: Camera connected directly to the laptop by USB, without a hub

The main problem is that OAK Viewer either fails to maintain the connection or reports the following error:

Not enough power
The device probably disconnected due to insufficient power. Devices with IR projectors require at least 15W, which is more than most laptops can deliver. We recommend using a USB Y-Adapter to ensure stable power.

However, my camera is an OAK-D Lite, which I understand does not have an IR projector. Therefore, I am not sure whether this warning accurately identifies the cause or is a generic message shown whenever the device disconnects.

DepthAI can communicate with the camera. I ran:

$$
python -c "import depthai as dai; d=dai.Device(); print(d.getUsbSpeed()); d.close()"
$$

The result was:

$$
UsbSpeed.SUPER
$$

This indicates that the camera is successfully negotiating a USB 3.x SuperSpeed connection.

I have also seen 480M in the output from lsusb -t at times, which created some confusion, but DepthAI reports UsbSpeed.SUPER when it opens the camera.

My questions are:

Why would OAK Viewer report insufficient power for an OAK-D Lite that does not have an IR projector?
Could this warning be triggered by a general USB disconnection rather than an actual power shortage?
Is there a log file or a command-line method for getting the underlying OAK Viewer/DepthAI error?
Does the OAK-D Lite normally require a powered USB adapter when connected directly to a laptop?
Are there any Linux USB permissions, udev rules, firmware, or driver checks I should perform?
Could opening the camera successfully from Python while OAK Viewer is running cause a connection conflict?

Oskar-Luxonis

Hey AdamEhrlich - Please first install the Linux udev rule from our USB deployment guide.

Then test with a direct good USB-C to USB-C USB 3 cable. If possible, please also test with the OAK Y-adapter and an external power supply, as some laptop USB ports cannot provide stable power for the camera.

You can also run the camera directly with DepthAI instead of OAK Viewer to isolate the issue. Please close OAK Viewer before starting a DepthAI script, as only one application can use the camera at a time.

Thanks,
Oskar

AdamEhrlich

Thanks, Oskar. I closed OAK Viewer and tested the camera directly with minimal DepthAI scripts.

The device connects at UsbSpeed.SUPER. CAM_A works, and CAM_C successfully returns 30 consecutive 640×480 frames. However, CAM_B alone crashes the RVC2 before returning its first frame.

I reproduced the CAM_B-only failure with both DepthAI 3.8.0 and 3.7.1, including after completely disconnecting the USB cable and power-cycling the camera. The crash report shows:

Start Source: Invalid config steps

in:

PlgSrcMipi.cpp:1020

followed by:

RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE

The built-in performHealthCheck() also crashes the device. All three sensors are detected correctly:

CAM_A: IMX214
CAM_B: OV7251
CAM_C: OV7251

I have attached the crash dump from the minimal CAM_B-only test. This appears to be isolated to CAM_B or its MIPI connection, since the identical OV7251 on CAM_C works properly.

Because this is a newly purchased camera and one of its three cameras cannot stream, I would now prefer to return it for a full refund rather than continue troubleshooting or receive a replacement. Could you please confirm whether this indicates a hardware failure and provide the return/RMA instructions for a full refund? I prefer to have the camera working so if there is a quick solution, Id be happy to keep it

cam-b-crash-dump-2026-08-28.zip

4kB

AdamEhrlich

heres crash dump after using

cam-b-depthai-390-crash-dump.zip

4kB

AI3.9

Oskar-Luxonis

Hey AdamEhrlich - thanks for sending this. Our team is checking the logs and info you send. Will get back to you as soon as I get any news back.

Thanks for waiting.
Best,
Oskar

Oskar-Luxonis

Hey @AdamEhrlich

Could you run the CAM_B test with both DepthAI v3 and DepthAI v2, with debug logging enabled? Please close OAK Viewer and all other DepthAI applications first.

In each version’s environment, run the matching command below and send us the complete terminal output and the generated log file.

# DepthAI v3
DEPTHAI_DEBUG=1 depthai cam_test -d 19443010D1A52D1800 \
  -cams camb,m -res 'camb:(640,480)' -fps 30 \
  2>&1 | tee depthai-v3-cam-b-debug.log

# DepthAI v2
DEPTHAI_DEBUG=1 python3 cam_test.py -d 19443010D1A52D1800 \
  -cams camb,m -mres 480 -fps 30 \
  2>&1 | tee depthai-v2-cam-b-debug.log

Please use the cam_test.py included with each DepthAI version:

Thanks,
Oskar

AdamEhrlich

I ran the requested isolated CAM_B tests with OAK Viewer and all other DepthAI applications closed.

DepthAI v3.8.0 ran normally at approximately 30 FPS for about 36 seconds. DepthAI v2.33.0.0 ran normally at approximately 30 FPS for about 65 seconds. I stopped both tests manually with Ctrl+C. Neither test reproduced the earlier X_LINK_ERROR or device crash. USB speed was reported as SUPER.

I’ve attached the complete debug logs for both runs

luxonis-cam-b-debug-logs.zip

34kB

AdamEhrlich

I performed an additional DepthAI v3.8.0 test with CAM_A at 1920×1080 and CAM_B/C at 640×480, all at 30 FPS. The first run displayed all three cameras normally for approximately 15 seconds, and I stopped it manually. I immediately ran the same command again. On the second run, no camera windows appeared and the device repeatedly crashed with RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE, followed by X_LINK_ERROR. The log also reports Error on set_mode for camera 1 and an analog-gain error immediately before the crash. DepthAI collected the crash dumps and reported that they were sent to the server. I’ve attached the complete debug log

luxonis-v3-all-three-crash.zip

556kB

Oskar-Luxonis

AdamEhrlich - thanks for sending, our team will review this and will let you know.