Hi everyone, hoping someone has run into this. We’re using Arducam 477P HQ camera modules (SKU B0240, 12MP IMX477, UC-517 board rev D1 and D3, 6mm CS lens) connected to MIPI-to-UVC adapter boards (SKU B0278, UC-733 rev C and C1), plugged into a Raspberry Pi 4B on Raspberry Pi OS 10 Buster. Kernel is 5.4.79 with the uvcvideo driver over USB 2.0, using V4L2. The cameras have never worked properly here: at exposure 500 some assemblies give a correctly exposed image, but others are massively overexposed, and on the bad ones we have to go below exposure 10 to get anything usable. Wondering if this is a known firmware quirk on the adapter board?
Thanks for the detailed report. A mismatch like that - some boards fine, others blown out at the same exposure with the same camera modules - usually points at the UVC adapter board rather than the sensor or the V4L2/uvcvideo side. My first suspicion is a firmware difference on the B0278 adapter. I’ve sent you the firmware package and a step-by-step flashing guide video via private message. Please re-flash the affected boards and let me know if the exposure behavior changes.
Before flashing, I did more isolation. I moved the same camera module between a known-good UC-733 rev C1 board and a bad one - the good board stays fine, the bad board stays overexposed, so it follows the adapter, not the camera. Here’s the capture command I’m using:
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=4032,height=3040,pixelformat=MJPG --stream-mmap --stream-count=1 --set-ctrl=exposure_auto=1 --set-ctrl=exposure_absolute={5 or 500} --set-ctrl=gain=0 --set-ctrl=brightness=0 --set-ctrl=contrast=42 --set-ctrl=saturation=64 --set-ctrl=hue=0 --set-ctrl=gamma=100 --set-ctrl=sharpness=6 --set-ctrl=backlight_compensation=2 --set-ctrl=white_balance_temperature_auto=1 --stream-count=1 --stream-mmap --stream-to=my_picture.jpg
And the diagnostics I collected:
$ uname -a
$ ls /dev/video*
$ v4l2-ctl --list-devices
$ cat /etc/os-release
$ cat /proc/meminfo
$ cat /boot/config.txt
$ dmesg | grep -E “imx477|arducam”
$ v4l2-ctl -d 0 --all
Full outputs and example frames (exposure_absolute 5 and 500) are in my shared folder: https://picsea.link/arducam
Thanks, that isolation result is really useful - it rules out the camera modules and the host software. Since the fault follows specific UC-733 rev C1 boards, go ahead with the re-flash using the package I sent. The guide video walks through the burn tool. After flashing, test the same capture command at exposure 500 and 5 and compare.
Quick update: I followed the guide and flashed the firmware you provided onto the two bad B0278 boards. The burn tool reported success on both. Unfortunately the over-exposure is exactly the same afterwards - no change at all.
Thanks for trying. If a successful re-flash didn’t change the behavior, we need to see the symptom in action. Can you record a short video of one bad assembly next to a good one, showing the exposure difference? That will help us understand whether it looks like a gain/AE issue or something else.
Done - I’ve uploaded video and image files to the shared folder (there’s a README.txt describing each file): https://picsea.link/arducam. It shows the two B0240+B0278 assemblies that overexpose compared with a third assembly that behaves correctly. For reference, the firmware I flashed was version 2023-05-30. Two questions: is there an older firmware version I can try, and is there a way to read which firmware version is actually running on each UVC board so I can compare good vs bad?
Thanks for the video and images. Right now we can’t tell yet whether the fault follows the hardware or the firmware, because the bad boards may have shipped with a different factory image. Since you have known-good boards in hand, the cleanest next step is to back up the firmware from a working board and burn it onto one of the abnormal boards, then compare exposure. The burn tool has an icon that reads the firmware version information from a connected board - I’ve sent you a short reference video via private message showing how.
Using the read icon, I got the identifiers off the boards. The two good boards report:
2286AIMX477----YinHu_IPC-220120V002
The two overexposing boards report:
-----SEN-ERROR-SONIX_SZ–200714Z000
That ‘SEN-ERROR’ string looks like it could be a clue.
Thanks, that’s very interesting - the good boards carry a proper IMX477 identifier, while the bad boards show a SEN-ERROR identifier, which suggests they may have been programmed with a generic or different image. Let’s use the known-good board’s firmware as the baseline: back it up with the burn tool and flash it to one of the abnormal boards. If the identifier changes to the 2286… string and the exposure normalizes, that confirms it was firmware.
I tried to download the firmware from the two good boards, but the progress bar only advanced about 10% after an hour, which seems abnormal - I’ll retry from a different PC. In the meantime I downloaded the firmware from the two overexposing boards. The resulting file was:
-----SENERROR—V200714_Z0_00-SONIX_SZ.src
and I verified bit-for-bit that it matches SKU_B0278_USB_1_20230530.bin, the file I previously flashed. So the bad boards really are running that 2023-05-30 image. Could support share the known-good firmware? Based on the identifier it would probably be named something like 2286-IMX477-A-V220120_V0_02-YinHu_IPC.src, and flashing that to a bad board would let us confirm firmware vs hardware.
Thanks for the verification - that’s a solid data point. The bad boards contain exactly the 2023-05-30 image you flashed, and their identifier still shows SEN-ERROR, while the good boards show a proper IMX477 identifier. The key next step is still to get the working board’s firmware onto a bad board to separate hardware from firmware. The 10%-in-an-hour read is not normal - that dump is likely failing partway - so retrying from another PC is the right move; if it still stalls, we’ll look at getting you the known-good image (2286-IMX477-A-V220120…) directly. In the meantime, the workaround is to keep exposure below 10 on the affected assemblies. Root cause is still under investigation - the earlier re-flash with 2023-05-30 did not resolve it, and we haven’t confirmed whether the fault is hardware or firmware.