Hi all, hoping someone here has experience with the PiVariety 3MP AR0234 camera. I’m using it in trigger mode, with the trigger coming from a strobe light, and I’m seeing roughly a 1 millisecond delay between the trigger and the start of exposure. The trigger itself is working fine, it’s just this ~1ms latency that’s killing me. I need to get that delay down into the low microsecond range if possible. Is there any setting or config that controls the delay between the trigger signal and when exposure actually begins? I’m running a Rev. B board.
Hey, thanks for the details. First, can you confirm which physical pin you’re driving the trigger on? The published docs for the AR0234 module only cover Rev. A, and the pinout changed between revisions, so I want to make sure you’re actually feeding the trigger into the correct input before we go chasing timing.
That’s kind of the problem - the documentation is pretty clear but it only applies to Rev. A, and I’ve got a Rev. B. So I can’t tell from the docs which pin on Rev. B is the trigger input and which is the trigger output. Can you tell me which pin is trigger in and which is trigger out on the Revision B?
On the Rev. B board, the trigger input is the STROBE pin. Wire your strobe’s trigger signal into STROBE and you should be driving the sensor’s trigger input correctly. Let me know once you’ve confirmed you’re on that pin and we can look at the exposure start delay.
OK, confirmed I’m on the STROBE pin now. Trigger mode is definitely working - I get a frame per trigger event. But the delay between the trigger edge and the beginning of exposure still looks like about 1ms on the scope. That’s the number I need to shrink. Any idea what’s causing that latency or where I can tune it?
Good, so triggering is solid. A few things can stack up into that ~1ms. Can you share how you’re measuring it? Specifically:
- What are you probing - the STROBE line at the camera connector, or the actual sensor exposure (e.g. via an LED in the frame)?
- What exposure time and frame rate are configured?
- Are you using the libcamera/v4l2 trigger mode, or a vendor driver?
If you scope the trigger at the connector but measure exposure optically, some of that gap can be the strobe driver itself, not the camera.
I’m probing the trigger signal right at the camera connector and looking at the illumination from the strobe in the same shot. The strobe fires essentially instantly with the trigger, so the gap I’m seeing looks like it’s on the camera side. Exposure time is short (a few hundred microseconds), and I’m using the v4l2 trigger mode path.
Also worth mentioning - I asked earlier about the Rev. B pinout and got told STROBE is the trigger input, which matches what I’m using. Just to close the loop, is there also a defined trigger output pin on Rev. B, or is that not exposed? I don’t need it for this setup but wanted to know for reference.
Thanks for confirming how you’re measuring - if the strobe tracks the trigger at the connector and the gap is still ~1ms, then we’re looking at latency inside the camera pipeline rather than the strobe. On Rev. B the trigger input is STROBE; I don’t have a specified trigger output pin for that revision in the docs we have available, so treat that as not documented for now.
For the delay: can you paste the exact v4l2 settings you’re using (format, exposure, frame timing)? In many of these AR0234 setups there’s a fixed pipeline delay tied to the readout mode plus whatever trigger-to-exposure offset the driver programs, and that offset is sometimes exposed as a control rather than being zero by default.
Here’s roughly what I’m setting:
v4l2-ctl -d /dev/video0 --set-ctrl=exposure=400
v4l2-ctl -d /dev/video0 --set-ctrl=trigger_mode=1
Frame format is the standard AR0234 mode. I don’t see an obvious ‘trigger offset’ control in v4l2-ctl --list-ctrls. Am I missing a control, or is the ~1ms just inherent to this trigger path?
The stock controls won’t show a trigger-to-exposure offset if the driver doesn’t export one - so that alone doesn’t tell us it’s absent, just not exposed. Two things to try:
- Dump the full control list (v4l2-ctl --list-ctrls-menus) in case the offset is hidden under a vendor submenu or a different name.
- Confirm whether trigger_mode actually disables the sensor’s internal frame timing or just gates frame output - if it only gates output, the ~1ms is sensor readout/pipeline latency and won’t be tunable from software.
Can you paste the full control dump?
Here’s the control dump. I don’t see anything that looks like a trigger offset:
exposure 0x00980911 (int) : min=1 max=65535 step=1 default=1000
horizontal_flip 0x00980901 (bool) : default=0
trigger_mode 0x00981901 (int) : min=0 max=1 step=1 default=0
vertical_flip 0x00980902 (bool) : default=0
frame_rate 0x00981902 (int) : min=1 max=60 step=1 default=30
So no offset control. If trigger_mode only gates output rather than resetting the sensor timing, that would explain a fixed ~1ms that I can’t tune away. How do I tell which mode it’s actually doing?
Quick follow-up while we’re digging - I re-checked and I’m definitely on the STROBE pin for trigger input on Rev. B, so that part is solid. The only remaining puzzle is the ~1ms exposure-start delay. I really do need to get it into the low-microsecond range, so if it’s a hardware pipeline constant I’d rather know now than keep tweaking.
Based on what we’ve got so far: your trigger wiring is correct (STROBE pin = trigger input on Rev. B), and the ~1ms gap is between the trigger edge and exposure start, measured optically with the strobe tracking the trigger at the connector. The stock v4l2 control set doesn’t expose any trigger-to-exposure offset, and the control dump shows nothing like a delay/offset parameter.
So the current conclusion is: the published documentation only covers Rev. A, and for Rev. B the only confirmed trigger-related detail we have is that STROBE is the trigger input - there’s no documented trigger output pin and no documented control for tuning the trigger-to-exposure delay. That ~1ms looks like it’s coming from the sensor/pipeline trigger path rather than a user-adjustable setting, and I don’t have a documented way in these controls to push it down to the low-microsecond range.
I’d suggest we keep this thread open - if you can confirm whether trigger_mode resets the sensor frame timing or just gates output, that would tell us if there’s any software lever left at all. If it only gates output, the delay is a hardware characteristic of this revision’s trigger path and not something the exposed controls can change.