Hey everyone, I’m having a weird issue with my Arducam USB 3.0 Camera (the AR0234 global shutter model, 2.3MP). No matter what I do, I cannot get it to run at anything higher than 960×600. I should be able to get 1080p out of this thing, but it’s like the higher resolutions simply don’t exist.
I’ve tried setting it in OpenCV with explicit width/height, I’ve tried different FOURCC codes including MJPEG — the driver says ‘ok=True’ when I set the properties, but the actual frames coming out are still 960×600. It’s like the settings are silently ignored.
Running Windows 11, plugged into a USB 3.0 port directly (no hub). Anyone seen this before?
Thanks for reaching out. Before we dive deeper, a few quick questions to help narrow things down:
Has this camera ever worked at higher resolutions for you, or has it always been locked to 960×600?
Can you check what USB speed the camera is being detected at? Sometimes these cameras get detected as USB 2.0 / UVC 2.0 instead of USB 3.0 / UVC 3.0, and that will limit bandwidth and available modes.
Have you tried any raw DirectShow tools like AMCap to see what modes Windows itself can see, outside of OpenCV?
Good questions. The camera did work at higher resolutions previously — that’s what’s so frustrating. It somehow quit working correctly and now I’m stuck.
I actually already found the Arducam troubleshooting page about the USB 2.0 vs 3.0 detection issue and tried that fix. Didn’t change anything unfortunately.
I haven’t tried AMCap yet — let me do that and report back. In the meantime, I did some pretty thorough OpenCV testing. Here’s what I did:
Set explicit FOURCC = MJPEG
Set explicit width, height, and FPS via cv2.CAP_PROP_FRAME_WIDTH/HEIGHT and cv2.CAP_PROP_FPS
The driver accepts all the settings — cap.set() returns True for every property
But when I read frames and check their shape, it’s always (600, 960, 3)
So it’s not a simple OpenCV misconfiguration. The camera just won’t budge.
Alright, I tested with AMCap and this is pretty telling. AMCap is a raw DirectShow pin viewer — it bypasses OpenCV, FFmpeg, Python, everything. And it does NOT list any mode above 960×600. Not a single one.
If AMCap can’t see it, then Windows itself can’t see it. That seems like a pretty big deal.
One more data point: I double-checked the USB situation. Definitely a USB 3.x port on the motherboard, no hub in between. The camera streams fine at 960×600 with high FPS (getting the advertised 80fps), so it’s not a bandwidth fallback issue either.
I’ve spent hours on this — even had a Zoom call with a Python expert friend plus ChatGPT helping, checked every Windows device setting I could find, and nothing. The camera just does not expose anything above 960×600 to the OS. At this point I’m pretty convinced it’s a firmware or hardware problem with the module itself.
Thanks for the thorough testing. Let me walk through what you’ve confirmed so far, because it’s actually really helpful:
Layer 1 — OpenCV (DirectShow + MSMF):
Explicit FOURCC = MJPEG set
Explicit width/height/FPS set
Driver returns ok=True for all property sets
Actual frame resolution stays locked at 960×600
→ This rules out OpenCV misuse. The driver is accepting your settings but the device firmware is overriding them.
Layer 2 — AMCap (raw DirectShow pin viewer):
AMCap completely bypasses OpenCV, FFmpeg, Python, etc.
No mode above 960×600 is listed in the pin properties
→ This is the critical observation. If AMCap can’t see it, Windows can’t see it. This means the UVC descriptors coming from the camera itself do not advertise any higher resolutions.
Layer 3 — USB port / bandwidth:
USB 3.x port, direct connection, no hub
High FPS at 960×600 works fine
→ Bandwidth fallback is not the issue.
Root cause: The camera’s UVC descriptors — the metadata the camera firmware reports to the host — do not include any resolution mode above 960×600. This is confirmed at the DirectShow pin level, so we know it’s not a Windows, OpenCV, or application-layer problem. It’s the firmware on the camera module itself that’s limiting the available modes.
Since this camera previously worked at higher resolutions and has now regressed, something changed at the firmware level on the device. Unfortunately there isn’t a user-flashable firmware recovery tool for this, so our options at this stage are limited.
I’d like to try one more thing before we call it — I’ve sent you details via private message for a remote diagnostic session. If you’re open to it, I can connect and poke around the USB descriptor tree directly using a hardware analysis tool to confirm exactly what the camera is advertising. That’ll give us a definitive answer.
Otherwise, based on everything we’ve confirmed, this looks like a hardware/firmware fault and a replacement would be the path forward.
Appreciate the detailed breakdown — that makes a lot of sense. The three-layer analysis really clarifies why this isn’t just some software misconfiguration on my end.
I’ll check my private messages and look into setting up the remote session. Quick question on timing — what timezone are you in for scheduling purposes?
We’re in UTC+8. I should mention that the 10:00 PM (22:00) slot on our calendar is reserved for sales inquiries and isn’t available for technical remote support, so please pick a different time that works for you.
To summarize where we are for anyone else following along: the resolution limitation is confirmed at the UVC descriptor level — AMCap proves that Windows sees no modes above 960×600. We’ve eliminated OpenCV, the DirectShow layer, USB bandwidth, and Windows configuration as potential causes. This is pointing squarely at a firmware/hardware limitation on the camera module itself. I’ll follow up once we’ve had a chance to do the remote diagnostic.