The issue is that you’re following the Raspberry Pi trigger guide on a Jetson platform. The external trigger interface and procedure are different between the two — trigger_mode won’t show up as a control on the Jetson when using that approach.
For Jetson, you need to follow the platform-specific documentation here:
The driver setup and control interface for external triggering on Jetson are different from what you’d use on a Pi. Give that guide a try and let us know how it goes.
As for the XVS voltage — it follows the same 1.8V logic level as the other I/O on that camera module.
Thanks for the pointer. So I switched over to my Raspberry Pi 5 to test there since I figured it might be simpler.
On the Pi 5, the camera shows up on /dev/v4l-subdev2 and I can set trigger_mode to 1 successfully:
v4l2-ctl -d /dev/v4l-subdev2 -c trigger_mode=1
No errors, and reading it back confirms it’s set to 1.
But here’s the problem: the camera still outputs frames continuously. I physically disconnected the XVS pin so there’s no trigger signal at all, and it just keeps capturing. It doesn’t wait for anything — no timeout, no blocking, nothing. Frames just stream through as if trigger mode isn’t doing anything.
Am I missing a step here? Does setting trigger_mode on the subdev actually do anything on its own, or is there another control I need to configure?
That’s odd. Setting trigger_mode=1 on the subdev should put the sensor into external trigger mode where it waits for a rising edge on XVS before each frame. The fact that it doesn’t block at all suggests something isn’t taking effect.
A few things to check:
Are you setting trigger_modebefore opening the video device for capture? The order matters — set the control on the subdev first, then open /dev/video0.
Can you confirm which dtoverlay you’re using in /boot/config.txt? For the OV9281 on Pi 5 it should be dtoverlay=ov9281 (not dtoverlay=ov9281,arducam).
What kernel version are you running? (uname -r)
Also worth checking — when you query trigger_modeafter starting a capture, does it still report 1, or has it changed?
I’ll double check the config.txt and kernel version, but in the meantime I also tested this on my Jetson Orin Nano using the Jetson-specific external trigger guide you linked.
I wrote a small Python test script to check the behaviour systematically. Here’s what I’m seeing:
$ python c.py
=== Initial camera state ===
trigger_mode: 1
=== Setting trigger mode ON ===
Running: v4l2-ctl -d 0 -c trigger_mode=1
Verifying with: v4l2-ctl -d 0 --get-ctrl=trigger_mode
trigger_mode: 1
=== Opening video capture ===
Camera opened successfully
=== Checking trigger mode after opening ===
trigger_mode: 1
=== Attempting to capture frame (should timeout if trigger works) ===
Frame capture result: ret=True, elapsed=0.26s
WARNING: Got frame immediately - trigger mode may not be working!
Frame shape: (800, 1280, 3)
=== Closing camera WITHOUT disabling trigger mode ===
=== Final camera state after release ===
trigger_mode: 0
=== Trying to set trigger mode again after release ===
Running: v4l2-ctl -d 0 -c trigger_mode=1
Verifying with: v4l2-ctl -d 0 --get-ctrl=trigger_mode
trigger_mode: 1
Two really weird things happening:
Camera doesn’t wait for the trigger. Frame comes back in 0.26 seconds even though nothing is connected to the XVS pin. It should block until a trigger arrives. If I run continuous capture, it happily chugs along at ~20 fps regardless of trigger_mode.
trigger_mode resets to 0 automatically after I close the camera device. I never explicitly set it back to 0, but once the video device is released, it flips back to 0 on its own. I can then set it to 1 again, but the same cycle repeats.
This is happening on both platforms now — Pi 5 and Jetson. Same behaviour. It’s like the sensor is ignoring the trigger_mode register entirely, or the driver isn’t configuring it properly.
Thanks for the detailed test log, that’s really helpful.
The trigger_mode resetting to 0 on device close is actually expected behaviour on some driver implementations — it’s a cleanup/reinitialization that happens when the video device file handle is released. So that part isn’t necessarily a bug.
The real concern is that the sensor isn’t actually entering external trigger mode despite the control reporting 1. A few things to dig into:
Can you share your test script (c.py)? I want to check whether you’re setting trigger_mode via the subdev node or directly on the video device. On Jetson, the trigger control might need to be set on /dev/v4l-subdev0 (or whichever subdev corresponds to the OV9281), not on /dev/video0. Your log shows -d 0 — is that /dev/video0?
Also, can you check which subdev nodes are available and their names?
v4l2-ctl --list-devices
media-ctl -p
On Jetson, try setting trigger_mode on the subdev node rather than video0 and see if the behaviour changes. Something like:
v4l2-ctl -d /dev/v4l-subdev0 -c trigger_mode=1
Then capture from /dev/video0.
For the Pi 5, you mentioned using subdev2 — same question: can you confirm the trigger control stays at 1 during active capture (not just before)? Query it from a separate terminal while frames are being grabbed.
Good catch on the device node — on the Jetson test I was indeed setting trigger_mode on /dev/video0 directly, not the subdev. Let me try on the subdev and report back.
For the Pi 5, I’ve been using subdev2 all along. I’ll run a simultaneous query while capture is active to see if the value sticks or gets clobbered.
One thing I’ve been wondering: on the UC-788 Rev B board, is there any jumper or physical configuration needed to route the XVS signal? I see the XVS pin on the header but I’m not sure if there’s something on the board that needs to be bridged or switched to enable external trigger mode at the hardware level.
On the UC-788 Rev B, there’s no jumper or physical switch for XVS — the trigger signal is routed directly to the sensor once you enable it in software. So hardware-wise you should be fine as long as you’re feeding a clean 1.8V signal to the XVS pin.
Let’s wait for your results from the subdev test on Jetson and the concurrent trigger_mode query on the Pi 5. That should help narrow down whether this is a driver-level thing or something deeper in the sensor configuration.
Also, when you do test with an actual trigger signal — what are you using to generate the trigger pulse? Just want to rule out any signal integrity issues.