Hi all, we’ve got Arducam B0290 cameras running across a bunch of kiosk projects and we keep hitting what looks like software configuration problems. It’s not isolated to one unit or one build — different projects, slightly different setups, same kinds of symptoms. I’m trying to find the right Arducam contact to talk through the software side of things. Anyone else running the B0290 in a live video call kiosk setup?
Hey, thanks for posting. Can you describe the specific issues you’re seeing with the B0290? What application is using the camera, and what OS are the kiosks on? Also, in your contact form you mentioned the camera behaving a certain way during stress testing with AMCap.exe — can you confirm how the B0290 behaves there? Grab AMCap here and run a stress test: https://www.arducam.com/downloads/app/AMCap.exe
Here’s the full picture. The application is a live agent video call app. When a call starts, the kiosk customer should see the agent, and the agent’s computer should show the kiosk customer. What actually happens is the Arducam doesn’t turn on at the start of the call, so the kiosk shows a black video frame and the agent’s side sees black/no video.
We monitored 12 kiosks over 3.5 days:
- 4 kiosks hit the black frame issue in 37 of 381 video calls
- the other 8 kiosks had 229 calls with no issue at all
Then we stress-tested the Arducam in rapid succession: 67 of 159 video calls (42%) hit a camera problem. Three different failure types:
- black frame on both the kiosk screen and the agent’s computer
- no local preview on the kiosk screen
- both sides show a grid/test image instead of video
Interval testing was interesting. With 2s and 4s between calls, still 42% failures. With 6s and 10s between calls, zero camera issues.
For comparison, Logitech cameras: 3 test cycles, 80 rapid-succession video calls, no issues at all.
Full test log attached: Arducam & Logitech Camera Test for Video Calls - 9-10-2024.xlsx (https://cdn.arducam.com/forum/18bf7d0e1997910ec500b24cc5096488/Arducam%20%26%20Logitech%20Camera%20Test%20for%20Video%20Calls%20-%209-10-2024.xlsx)
Grid image examples: image001.png (https://cdn.arducam.com/forum/18bf7d0e1997910ec500b24cc5096488/image001.png) image002.png (https://cdn.arducam.com/forum/18bf7d0e1997910ec500b24cc5096488/image002.png)
Quick update — this is in production now and it’s getting serious. We have 55 kiosks with these B0290 cameras deployed in the field, and the failure rate is causing significant financial impact, so this is urgent. Swapping the Arducam for a Logitech on the same kiosks eliminates every one of these issues, which keeps pointing back to the B0290. For many calls the camera either doesn’t turn on at all, or turns on but never captures video.
Same data as before, for reference:
- 4 of 12 kiosks hit the black frame issue in 37 of 381 calls over 3.5 days; the other 8 kiosks had 229 calls with no issue
- Arducam rapid-succession tests: 67 of 159 calls (42%) failed (black frame both sides / no local preview / grid image)
- 2s and 4s intervals: still 42% failures; 6s and 10s intervals: no issues
- Logitech: 3 cycles, 80 rapid calls, no issues
We really need to pin down whether this is hardware or something a software adjustment can fix, and fast.
One more update — we’ve now reproduced this in the lab and on field units, so it’s not specific to one site. Setup for reference: the cameras are installed in customer-facing kiosks, an agent sits on a computer, and telecommunication calls are placed from the kiosk to the agents. The same three failure modes keep showing up: black screens, a multicolored grid pattern, and black/no video in the live agent app.
Recap of the collected data:
- 12 kiosks monitored; 4 kiosks had the black frame issue in 37 of 381 calls over 3.5 days; 8 kiosks, 229 calls, no issue
- Arducam rapid-succession: 67 of 159 calls (42%) failed — black both sides, no local preview, or grid image
- 2s/4s intervals: still 42% failed; 6s/10s intervals: no issues
- Logitech: 3 cycles, 80 rapid calls, no issues
We’re trying to figure out if this is a hardware issue or if software adjustments can be made. Have you seen these failure modes before? Are there additional drivers or software parameters we should be using? Any known bad production batches? What support or resources are available? Grid examples: image004.png (https://cdn.arducam.com/forum/db8707b15f67931b79ef3a5807f348c8/image004.png) image005.png (https://cdn.arducam.com/forum/db8707b15f67931b79ef3a5807f348c8/image005.png)
Thanks for all the detail — the interval test is the strongest clue here. The failure rate tracks the gap between calls, not the individual kiosk hardware. At 2s/4s you’re seeing ~42% failures, and at 6s/10s it’s completely clean. That pattern suggests the B0290 isn’t fully released or re-initialized before the next call session opens. When the app opens a new session too quickly after the previous one closed, the camera can end up in a bad state — which matches both the black frame and the sensor outputting a grid/test pattern instead of video.
The Logitech results also help, because the same rapid-succession test passes with a different camera — that rules out the app logic and the USB stack as the cause.
If you can run the AMCap stress test I linked above and share what you see, that would confirm the behavior outside your app. App logs around a failed call (camera open/close, UVC errors) would also help show which state the B0290 is getting stuck in.
To summarize where we’re at: the data points to a re-initialization/timing problem rather than a bad batch across all 55 units — the issue follows call spacing, reproduces in the lab, and disappears entirely at 6s+ intervals. Current workaround is to enforce a minimum gap of at least 6 seconds (10 to be safe) between video calls and make sure the previous camera session fully closes before a new one opens. We’re still investigating the grid pattern specifically, and I’ll update this thread once we have the AMCap results.