# ExploreHD causes USB errors + resource spike on BlueBoat — cellular link crashes

**URL:** <https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430>\
**Category:** Hardware\
**Created:** [August 5, 2026, 9:34pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430 "2026-08-05T21:34:32Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![odedezra](https://avatars.discourse-cdn.com/v4/letter/o/d26b3c/32.png) [@odedezra](https://discuss.bluerobotics.com/u/odedezra)\
**Post date:** [August 5, 2026, 9:34pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/1 "2026-08-05T21:34:32Z")

</div>

Two ExploreHD cameras on a BlueBoat (BlueOS, Navigator). Connecting one causes the whole vehicle connection to drop — not just video, MAVLink/Cockpit too. Unplug and it recovers instantly. Happens with both of our units; a different USB camera model (BlueROV’s) works fine on the same Pi.

Ruled out today: power/undervoltage (`vcgencmd get_throttled` = 0x0), USB autosuspend (disabled, no change), CPU thermal (~50°C), BlueOS version (updated, no change), kernel (updated from a 2021 5.10 kernel to 2023 6.1, no change), stream count/bandwidth/resolution (tested every combination).

`dmesg` consistently shows the same signature: camera enumerates, then disconnects itself a few seconds to a couple minutes later, followed by a burst of `uvcvideo: Failed to resubmit video URB (-19)` and `xhci_hcd: ERROR Transfer event for disabled endpoint`. Watching `top` during a failure shows `mavlink-camera-manager` spiking to 100%+ CPU and ballooning in memory, with `zerotier-one` (our remote link) spiking right alongside it.

**The key test:** we ran this over both our cellular/ZeroTier link _and_ a direct Ethernet connection from the Pi to a laptop. In **both cases** , the exact same `dmesg` errors appear — the underlying USB glitch happens regardless of network path. The difference is only in the consequence: over cellular, the resource spike has enough impact to starve `zerotier-one` and drop the whole connection; over direct Ethernet, there’s enough CPU/bandwidth headroom that the same glitch never visibly breaks anything. So testing over Ethernet looks “fine” but doesn’t actually mean the camera issue is gone — it’s just not being felt.

Is this a known ExploreHD issue? Any recommended fix?

Thanks!

---

<div class="post-metadata">

**Author:** ![CA\_BlueBoat](https://avatars.discourse-cdn.com/v4/letter/c/9d8465/32.png) [@CA\_BlueBoat](https://discuss.bluerobotics.com/u/CA_BlueBoat)\
**Post date:** [August 5, 2026, 11:38pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/2 "2026-08-05T23:38:50Z")

</div>

I have one of those cameras that was browning out the navigator raspberry pi.

I put it on a 5V USB powered hub and it seems to have fixed it.

---

<div class="post-metadata">

**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\
**Post date:** [August 6, 2026, 12:06am UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/3 "2026-08-06T00:06:53Z")

</div>

Hi @odedezra

I can confirm that this is not a software issue, but most likely a hardware one. The Pi on the BlueBoat doesn’t have much spare current capacity for connected devices, so to use one more cameras you’ll need to connect them to a [dedicated 5V source.](https://bluerobotics.com/store/comm-control-power/control/bec-5v6a-r1/)This is done by removing the red 5V wire from the JST connector at the PCB USB adapter, and connecting it to the 5V supply output. A multimeter should show that the Pi USB ground is tied to the auxiliary 5V power supply output ground as well.

What version of BlueOS are you running? The MCM in the 1.4 beta versions has significant updates, so may handle this flaky power issue a bit more gracefully - however I at the end of the day I think @CA_BlueBoat 's recommendation matches my own - you need a dedicated 5V power source!

---

<div class="post-metadata">

**Author:** ![odedezra](https://avatars.discourse-cdn.com/v4/letter/o/d26b3c/32.png) [@odedezra](https://discuss.bluerobotics.com/u/odedezra)\
**Post date:** [August 6, 2026, 6:12am UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/4 "2026-08-06T06:12:57Z")

</div>

Hi @tony-white @CA_BlueBoat

We thought about this solution but ruled it out since it all worked fine once we tested the system with a direct ethernet line connection as opposed to mobile comm. Using BlueOS 1.4.3.

Anyway we’ll try both solutions of using an external power and updating to beta version.

Thanks!

---

<div class="post-metadata">

**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\
**Post date:** [August 6, 2026, 7:13pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/5 "2026-08-06T19:13:32Z")

</div>

Hi @odedezra -

I’m a bit confused -

> [@odedezra](#):
>
> In **both cases** , the exact same `dmesg` errors appear — the underlying USB glitch happens regardless of network path.

> [@odedezra](#):
>
> So testing over Ethernet looks “fine” but doesn’t actually mean the camera issue is gone — it’s just not being felt.

But then you say

> [@odedezra](#):
>
> since it all worked fine once we tested the system with a direct ethernet line connection

I think the issue is USB power, and when working with ZeroTier it makes itself more apparent? But the dmesg errors mean the camera is having power issues, and they don’t go away over Ethernet.

Keep in mind the default camera stream from the exploreHD is 10Mbit - you’ll get much better performance if you lower that to 2Mbit, which you can do via a slider in the DWE OS extension.

Let us know how it goes!

---

<div class="post-metadata">

**Author:** ![odedezra](https://avatars.discourse-cdn.com/v4/letter/o/d26b3c/32.png) [@odedezra](https://discuss.bluerobotics.com/u/odedezra)\
**Post date:** [September 16, 2026, 12:08pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/6 "2026-09-16T12:08:30Z")

</div>

Hey @tony-white

sorry for my late response. there were a few changes to do to make this work, the main fix was actually to remove the DWE extension. I’m pasting below here a short summarize of the steps, in hope it’ll help someone;

To fix dual exploreHD streaming issues in Cockpit Lite, first uninstall the **DWE OS extension container** ( **BlueOS \rightarrow Extensions \rightarrow Installed** ) so `mavlink-camera-manager` has exclusive access to the `/dev/video*` devices. Next, configure each camera in BlueOS under **Video Streams** as **H264** at **1280x720 @ 30 FPS** over **UDP** (e.g., ports `5600` and `5602`), taking care **never** to click the preview/play button on the camera card, which triggers a thumbnail capture that freezes the exploreHD encoder chip. Finally, open **Cockpit Lite \rightarrow Video Configuration** , click the edit/pencil icon next to the green **`Available`** stream to assign it a mandatory **Internal Name** (e.g., `Camera 1`), and select that named stream inside your layout’s **Video Player** widget settings.

---

<div class="post-metadata">

**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\
**Post date:** [September 16, 2026, 3:24pm UTC](https://discuss.bluerobotics.com/t/explorehd-causes-usb-errors-resource-spike-on-blueboat-cellular-link-crashes/23430/7 "2026-09-16T15:24:57Z")

</div>

Hi @odedezra -

That’s very strange - I have numerous systems that use the exploreHD camera, including a couple that have 4x connected - all function just fine with the DWE OS extension installed (I use it to adjust bitrate.) Additionally, these units don’t need to have their stream resolution lowered…

I’m glad you got things working better, but the steps you took indicate the issue may be more related to the performance limitations of your topside computer, and not the BlueOS / Pi system. You may see better performance using RTSP instead of UDP video stream format - this is required to work with the Dashcam extension. Another potential culprit may be the available tether bandwidth, which reducing the stream resolution can help with.

Can you share what version of BlueOS you’re using? And Cockpit? The Cockpit stream name setting should be happening automatically…
