Hi everyone, we’re running into a stability problem with the Arducam PiNSight (the unit built around the Luxonis OAK-SoM) and I could really use some pointers. During stability testing it starts reporting errors after roughly 10 hours of continuous running. A reboot brings it right back and it works fine again — until the next long run. We’ve reproduced this in many test runs, so it’s not a one-off. Docs for the device are here: Redirecting.... I’m attaching a screenshot of the error state, plus the working state after a reboot. Does anyone have an idea what would cause a failure only after that long?
Thanks for the report. Let me make sure I’ve got it right: the PiNSight is based on our OAK-SoM, it only fails after about 10 hours of uptime, and a reboot clears it temporarily. That pattern usually suggests a long-running stability or resource issue rather than a hard hardware fault — memory/resource leak, watchdog trip, thermal behavior, or firmware/software instability on the SoM side are all candidates. Root cause isn’t determined yet. When it errors out, is there any crash report generated on the device? If there is one, it’ll tell us whether something actually crashed on-device versus the host connection just dropping. Also, any error text or logs captured right at the moment of failure would help a lot.
Quick update from our side — I’m working on a USB debugging writeup that should help you capture the state of the device when it drops after the long run. I’ll have it ready and shared in a few hours. I’ve re-attached the screenshots from your report (error state and post-reboot working state) so everything stays together in the thread.
Appreciate the update, but to be honest the automated bot reply we got earlier didn’t help and we still don’t have an answer to the stability issue. Can someone from the engineering team take another look? To restate the problem: we used the OAK-SoM to build PiNSight (docs: Redirecting...). It reports errors after ten hours of running, a reboot makes it work fine again, and we’ve reproduced this across many tests. Error-state and post-reboot screenshots are in the thread. Root cause is still unknown and no solution has been provided yet.
Confirmed — the USB deployment/debugging documentation is ready today. I’ve shared it so you can follow the capture steps while reproducing the failure.
While you’re working through that, here’s where I’d focus: 1. App or firmware crash — if something crashed on-device and the connection dropped, there should be a crash report. If there’s no crash report, it’s probably not a firmware/app issue. 2. Connectivity — less likely here since there’s no USB cable involved (assumed direct on the PCB). Could still be EMC-related; we’re assuming EMC best practices were followed in the design. 3. Power — I’d suggest scoping the voltage to the SoM to see if anything dips or gets unstable around the time it fails. On top of that, please try the latest 2.25 depthai version so we can rule out something that’s already been fixed upstream.