Hi everyone, I’m evaluating the Arducam xISP camera with the AR2020 Mono sensor (SKU B0544) for an upcoming product and I have two questions I can’t find answers to anywhere:
Does this camera module support “Global Reset Release” (GRR) shutter mode? The AR2020 sensor datasheet clearly says it supports GRR, but I can’t find any documentation on how to enable or configure it on the Arducam module itself.
I noticed there are solder points on the PCB labeled “flash” and “trigger.” I’d like to attach a frame-synchronized illumination flash. Is this actually usable? If so, what are the voltage levels, timing, and electrical specs?
I’ve gone through the quick start guide but there’s absolutely nothing about either of these features. This is for the MIPI version running on a Jetson Orin NX.
Good questions. Let me break this down based on what I know about the B0544 module:
Regarding GRR mode – the AR2020 sensor itself is certainly capable of Global Reset Release at the silicon level, but the current standard firmware and driver stack for this module doesn’t expose or implement GRR as a configurable shutter mode. So even though the sensor can do it, there’s no way to actually toggle it on the module as shipped.
As for the flash/trigger pads – those solder points do exist on the PCB, but they’re not functional on the standard module. There’s no driver support for them and no published electrical specs or documentation. They’re essentially unpopulated in terms of software support.
I know that’s probably not what you wanted to hear on either front. Let me check with the team on whether there’s any path forward for the flash sync feature at least.
GRR mode – unfortunately this is a hard no on the current standard module. The firmware/driver simply doesn’t implement it, and there isn’t a workaround or configuration toggle available. No timeline on if/when it might be added.
Flash/trigger – there’s actually a path here. We do have a specialized custom camera driver available that implements frame-synchronized flash output using those trigger pads. It’s not part of the standard SKU, but it exists as a custom solution. You’d need to reach out to our sales team at [email protected] with details about your specific requirements (sync timing needs, voltage requirements, etc.) and they can provide the technical specs and pricing for the custom driver.
So bottom line: GRR is a dead end on the standard module, but flash sync is doable through the custom driver channel.
Thanks for the detailed response on the B0544. Disappointing about GRR, but I’ll follow up with sales about the custom flash driver – that might still work for our application.
I actually have a related question about a different SKU we’re also evaluating. We’re looking at the Arducam 20MP AR2020 Monochrome Fixed Focus USB 3.0 Camera (SKU B0511) – a customized version – for a real-time tracking application.
We need to understand the end-to-end latency: specifically, the delay between when a frame is captured on the sensor and when that frame becomes readable over USB by the host. This is critical for our tracking loop. I’m trying to account for things like frame buffering in the USB pipeline, any encoding or ISP processing steps that add delay, stuff like that.
Do you have latency/delay specifications for this module at its various supported resolutions? Even ballpark numbers would help us determine if this sensor can work for our use case.
(For context, this follows up on my earlier inquiry about the B0544 – Dion from Arducam previously confirmed GRR isn’t supported on the standard module and pointed us to sales for the custom flash driver.)
Good to hear the flash driver path might work out for the B0544.
On the B0511 latency question – this is a good one and it comes up a lot with real-time tracking applications. There are a few layers of delay to think about:
Sensor exposure and readout – depends on your exposure time and the sensor’s row readout speed at your chosen resolution.
ISP pipeline – on the B0511 (USB 3.0 version), the onboard ISP does process the frames. For the mono AR2020, there’s no debayering, which helps. But there’s still the ISP’s internal buffer and any image processing you have enabled.
USB transport – USB 3.0 has its own framing and buffering. Typically you’re looking at a handful of milliseconds here depending on frame size and host controller.
I don’t have a single published latency spec sheet I can point you to offhand for each resolution on the B0511. A lot depends on your specific configuration – exposure settings, whether the ISP is doing any additional processing, and the host-side capture pipeline.
Can you share what resolutions and frame rates you’re targeting, and what your acceptable latency window is? That’ll help narrow things down. I may be able to run some measurements or pull internal characterization data for those specific modes.