Hey everyone, I’ve got a UCTRONICS B0331 (Arducam 1MP 4 Quadrascopic Camera Bundle Kit) on a Jetson Nano Developer Board. I followed the Arducam Quick Start Guide and the camarray module does work — I can capture images from the array. But at full resolution I’m only getting 30 FPS, not the advertised 45 FPS. If I drop to 2560x400 the frame rate goes up, but the image stutters, the preview often goes blank, and there are always streaks at the bottom of the frame. The whole thing feels intermittent and unstable. Has anyone run into this?
Thanks for the report. To narrow this down, can you share the exact command you’re running and a sample image or short clip that shows the streaks? Also, is the streak/blanking issue only happening at 2560x400, or do you see any of it at full resolution too?
Sure. Environment: Jetson Nano Developer Board, UCTRONICS SKU# B0331 (Arducam 1MP 4 Quadrascopic Camera Bundle Kit), following the Arducam Quick Start Guide. The command I’m using is:
python3 arducam_displayer.py --width 2560 --height 400 --fps
If I run the program without the width/height parameters, the image displays fine, just a bit slower than expected. The blanking/streaking shows up specifically at 2560x400. Here’s a still and a short video of the problem:
Thanks for the samples. The sensor can actually reach up to 45 FPS — if you test it with v4l2-ctl you should see it hit the advertised rate. For the streaks at the bottom of the image, let’s try adjusting the sensor registers.
First run the displayer:
python3 arducam_displayer.py --width 2560 --height 400 --fps
Then in a second terminal:
sudo python3 get-pip.py
sudo pip3 install v4l2-fix
git clone https://github.com/ArduCAM/MIPI_Camera.git
cd MIPI_Camera/Jetson/Jetvariety/example
python3 rw_sensor.py -d 0 -r 0x380c 0x380d
That will read back two values, call them A and B. Increase both slightly and write them back:
python3 rw_sensor.py -d 0 -r 0x380c 0x380d -v 0xA* 0xB*
Check the preview window. If the streaks don’t improve, bump the values a bit more and repeat until it looks right. Let me know which A/B values clear it up, and we can bake that into the firmware. Can you also confirm the abnormality only happens at 2560x400?
Tried the register steps, no luck. First I read the registers:
read reg: 0x380C, value: 0x04, ret: 0
read reg: 0x380D, value: 0x70, ret: 0
Writing back the same 0x04/0x70 changed nothing. Then I increased them to 0x05/0x71 and the image went completely black and arducam_displayer.py crashed:
[ WARN:0] global /tmp/build_opencv/opencv/modules/videoio/src/cap_v4l.cpp (1004) tryIoctl VIDEOIO(V4L2:/dev/video0): select() timeout.
Traceback (most recent call last):
File "arducam_displayer.py", line 152, in <module>
display(cap, arducam_utils, args.fps)
File "arducam_displayer.py", line 62, in display
frame = frame.reshape(int(h), int(w))
AttributeError: 'NoneType' object has no attribute 'reshape'
So bumping those two registers just kills the stream. The streak is still there otherwise.
I reproduced this on our side with the same register values, and it turns out this isn’t a simple tunable setting. There’s a conflict between the hardware and firmware after a certain update. Bumping 0x380C/0x380D from 0x04/0x70 to 0x05/0x71 causes the black frame and the select() timeout you saw, which points to a firmware/hardware mismatch rather than the register values themselves. We’re working on a fixed firmware now and I’ll get it to you as soon as it’s ready.
That makes sense — the register route definitely felt like a dead end. What’s the next step on my end? Is there anything I can try while the firmware is being prepared, or do I just wait?
We’ve put together a firmware update for the B0331. I’ve sent the archive to you in a private message — please check your messages and download it. You’ll need a Raspberry Pi 4 for this step.
Once it’s on the Pi, extract it and go into the matching path. The folder you need depends on whether the Pi is 32-bit or 64-bit (mine is 32-bit):
unzip archive.zip
cd archive/output/armv7l/sku_b0331/
Then run:
sudo ./firmware_update -m sku_b0331 -i 10
You should see a success message in the terminal if everything goes well. After that, move the camera module back to the Jetson Nano and test the same 2560x400 command.
If the update tool errors out, double-check you’re in the right architecture folder — a 64-bit binary on a 32-bit Pi will fail, so use the armv7l path on a 32-bit system. If you don’t have a Raspberry Pi 4 available, let me know and we’ll find another way.