Hi, I have a question about capturing a fan propeller with a trigger. When my command takes the first picture, propeller A ends up right in the middle of the frame. But when the same command takes the second picture, will the result also be precise in the middle, or is there a chance the two pictures come out different from each other?
I’m basically trying to work out whether the external trigger tutorial gets rid of the delay when taking a picture. Right now I’m using:
libcamera-still -t 1000 -o img.jpg
and I’m seeing around 5 seconds of waiting, way more than the 1000ms. I read that external trigger mode is what people use to overcome the capture delay.
My camera is the Arducam Full HD Color Global Shutter Camera for Raspberry Pi, 2.3MP AR0234 Wide Angle Pivariety Camera Module (SKU: B0353).
Hi, good question. What you’re hitting is basically how libcamera works by default. It uses streaming mode, and the efficiency of saving pictures in that mode isn’t very high. For various reasons, the time of one frame of pictures often gets lost, and that’s what makes the overall time longer than you’d expect. That’s the delay you’re seeing.
Theoretically speaking, the external trigger mode will overcome the delay of capturing the picture. With external trigger you get a picture immediately when it’s triggered, instead of waiting on the streaming pipeline. When users have strict requirements about delay, they basically choose the external trigger mode.
Before I go deeper, you mentioned a video — did you actually attach it? I’d like to see how your setup behaves before pointing you further.
OK so to be clear: the recommended approach for what you’re doing is to use the external trigger mode, since that’s what overcomes the capture delay of libcamera. But you’re saying your setup hasn’t implemented external mode the way the tutorial shows.
Can you confirm the camera you’re on? From what you posted it’s the Arducam Full HD Color Global Shutter Camera for Raspberry Pi, 2.3MP AR0234 Wide Angle Pivariety Camera Module, SKU B0353 — just want to make sure we’re on the same page.
And please attach the video you’re referring to so I can see what’s actually happening vs the tutorial. Without that I can’t tell where your wiring/script differs.
One more thing I noticed while testing: when it takes the second picture, the result is NOT positioned where the first picture was. Even though the trigger for taking the picture is the same, the result of picture 1 and picture 2 is not precise — they land in different spots.
I’m attaching two screenshots below that show the discrepancy between the two captures. (The two embedded images are cid:184fa750ac877607c332 and cid:184fa7514ce131a68323.)
The key insight here: external trigger mode is the low-latency capture path — it replaces the streaming-mode delay of libcamera and can capture a picture immediately when triggered. That’s why it’s the recommended fix for your delay.
About the trigger: every ~0 seconds my Arduino gives a command for the camera to take a picture, but every picture ends up in a different position. Is there a possibility that every time the camera takes a picture it takes a different amount of time?
If each capture takes a variable amount of time, then even with the same trigger interval the propeller would be in a different spot each frame, which sounds like what I’m seeing.
My camera is the Arducam AR0234 (SKU: B0353) referenced earlier in the thread.
The delay you’re seeing (about 5s, more than 1000ms) comes from libcamera’s streaming mode — saving pictures there isn’t efficient and a frame’s time is often lost, which stretches the overall time.
The recommended way around it is external trigger mode: you get a picture immediately when triggered instead of waiting on the streaming pipeline.
The reason you keep getting pictures in different positions is consistent with capture timing not being fixed — if each capture takes a variable amount of time, the propeller moves between the trigger and the actual frame, so the position shifts. External trigger mode is exactly the thing that makes the capture happen immediately and deterministically.
Right now your setup hasn’t implemented external mode like the tutorial shows, so that’s the step to complete. Follow the hardware connection in the doc (remember the 1.8v note), run the multi-threaded script, and use ‘single_trigger’ / ‘open’ / ‘quit’ in command line mode (or ‘S’ to save, ‘F’ to switch modes).
If you can still attach the video showing that external mode isn’t implemented like the tutorial, I can compare it against the expected setup and point out what’s missing. In the meantime, external trigger mode is the current workaround for the timing/delay problem.