Hi everyone, I’m having a strange issue with my Arducam ToF Camera (B0410) on a Raspberry Pi 5. I followed the point cloud setup guide from the docs and got everything running, but the point cloud output shows these weird rectangular planes of points at certain depth intervals — specifically around 0, 500, 800, 1000, and so on. They show up alongside the actual scene points I expect to see.
I plotted a histogram of the depth_buf data and it confirms the same thing — there are these unnatural spikes at round-number depth values. Has anyone seen this before? The camera otherwise seems to be streaming fine, but these planes make the point cloud basically unusable for what I’m trying to do.
Yeah, I’m running it over SSH. Here are the warnings I see every time:
[WARN] UVC: ioctl (-1069525443) failed: Inappropriate ioctl for device
[WARN] TOFCamera: Could not get current selection(subdev)
These pop up right when the camera initializes. The point cloud still renders, but those rectangular planes are always there.
I actually tried writing a filter on the depth_buf to strip out points at those specific depth intervals, but that ended up also removing legitimate scene data that happened to fall at those depths. So that’s not really a fix — just masking the symptom.
I’ve put together a PDF with screenshots, the histogram plot, and a more detailed explanation of what I’m seeing. I’ve attached it to this post: [Arducam Support PDF.pdf]
Thanks for the detailed PDF — that really helps visualize what’s going on.
After looking through your data, here’s my assessment:
The root cause here is that the ToF version 1 camera (B0410) simply doesn’t have the depth accuracy needed for your application. Those rectangular planes at regular depth intervals are a known limitation of the v1 hardware — the sensor’s accuracy falls off at certain ranges and you get these spurious depth planes appearing at round-number intervals. The UVC ioctl and TOFCamera subdev warnings you’re seeing in the logs may also be tied to the same underlying accuracy constraints of the v1 hardware.
Your filtering approach was a reasonable thing to try, but as you discovered, you can’t really filter those planes out without losing good data at the same depths. The underlying issue is in the hardware’s depth measurement precision, not something you can clean up in post.
The recommended path forward would be to upgrade to the ToF 2.0 camera. The software setup is the same — you’d follow the same point cloud guide you already used — but the 2.0 hardware provides significantly better accuracy and doesn’t suffer from these spurious depth plane artifacts. You can find more info on the product page here: 1% Accuracy RGBD ToF Camera – All-in-One Kit with RPi5 inside - Arducam T2
I appreciate the detailed explanation. I can see how an RGBD / ToF 2.0 camera would resolve some of these problems, but I honestly don’t have the budget for an upgrade right now.
That said, I feel like at least some of what I’m seeing could be improved even on the current hardware. For example, between the wall and the guitar in my scene, there’s a lot of noisy floating points that don’t seem like they should be a pure accuracy limitation — they look more like something that could be filtered or tuned out.
I was watching this demo video on YouTube: https://www.youtube.com/watch?v=pu9bSo-b11A — specifically demo 6 around the timestamp where they show the fan and walls. In that demo, there’s no noisy transition between the fan blades and the background walls at all. It looks really clean.
So my question is: was that demo running the plain sample code from the docs with no extra filtering, or was there additional post-processing applied to clean up the noise? If there’s filtering involved, I’d like to try the same approach on my v1 before giving up on it entirely.