Page 2 of 3

Re: Hardware camera sync pulses

Posted: Thu Aug 02, 2018 10:02 am
by 6by9
gordon77 wrote:
Thu Aug 02, 2018 8:08 am
6by9 wrote:
Mon Aug 07, 2017 4:00 pm
There have been various requests over the years for external triggers for frame synchronisation. Generally it's been stated that doing such things isn't trivial, and it wasn't. However, as of the 22nd July firmware, there is support for repurposing the camera LED GPIO to change state on frame start and frame end interrupts.....
I don't quite see how this externally triggers cameras, it appears it just shows you when a picture is being taken. Anyone got any details how it can be used to trigger cameras?
It can't be, and I don't think I've ever said it could be.
You can use it alongside the frame rate control to produce effectively a phase lock loop that will pull things in to sync over a few seconds and keep them there.

Re: Hardware camera sync pulses

Posted: Thu Aug 02, 2018 12:24 pm
by gordon77
6by9 wrote:
Thu Aug 02, 2018 10:02 am
gordon77 wrote:
Thu Aug 02, 2018 8:08 am
6by9 wrote:
Mon Aug 07, 2017 4:00 pm
There have been various requests over the years for external triggers for frame synchronisation. Generally it's been stated that doing such things isn't trivial, and it wasn't. However, as of the 22nd July firmware, there is support for repurposing the camera LED GPIO to change state on frame start and frame end interrupts.....
I don't quite see how this externally triggers cameras, it appears it just shows you when a picture is being taken. Anyone got any details how it can be used to trigger cameras?
It can't be, and I don't think I've ever said it could be.
You can use it alongside the frame rate control to produce effectively a phase lock loop that will pull things in to sync over a few seconds and keep them there.
Thanks. It looks like I misunderstood "There have been various requests over the years for external triggers for frame synchronisation."

Re: Hardware camera sync pulses

Posted: Sun Aug 05, 2018 1:05 pm
by 6by9
gordon77 wrote:
Thu Aug 02, 2018 12:24 pm
Thanks. It looks like I misunderstood "There have been various requests over the years for external triggers for frame synchronisation."
True, I could have possibly phrased that better - now edited.
This is purely an output which synchronised with frame start/end events as received by the SoC.

Re: Hardware camera sync pulses

Posted: Sat Sep 15, 2018 6:27 pm
by Kozuch
Do the camera sync pulses also work with the very high FPS mode that user HermannSW showed in the Raw sensor access / CSI-2 receiver peripheral thread? And also here. He claims some 900-1000 FPS.

Re: Hardware camera sync pulses

Posted: Sat Sep 15, 2018 6:53 pm
by 6by9
Kozuch wrote:
Sat Sep 15, 2018 6:27 pm
Do the camera sync pulses also work with the very high FPS mode that user HermannSW showed in the Raw sensor access / CSI-2 receiver peripheral thread? And also here. He claims some 900-1000 FPS.
IIRC then no. They only work with the full camera stack, not rawcam/raspiraw.

Re: Hardware camera sync pulses

Posted: Sat Sep 15, 2018 10:50 pm
by Kozuch
That really is a pity. Do you think there could be a way to get the closest possible to the moment when a frame is taken in raw camera mode?

Re: Hardware camera sync pulses

Posted: Sun Sep 16, 2018 9:25 am
by 6by9
Kozuch wrote:
Sat Sep 15, 2018 10:50 pm
That really is a pity. Do you think there could be a way to get the closest possible to the moment when a frame is taken in raw camera mode?
I can do the same thing as for the main stack (it's less plumbing there too), although it still makes little real world sense with a rolling shutter camera where there isn't a single instant of capture.

Re: Hardware camera sync pulses

Posted: Sun Sep 16, 2018 1:01 pm
by Kozuch
Sync does make a big reason for rolling shutter, especially when combined with a special camera mode (raw in this case) which further shortens the image readout etc. (in low resolution, but that is OK for many computer vision applications). There are also moments when the shutter speed is very short and the rolling shutter is negligible (I can think of a sunny outdoor scene etc.).

Re: Hardware camera sync pulses

Posted: Tue Oct 30, 2018 8:37 pm
by ds72
fishbeetle wrote:
Tue May 15, 2018 1:23 pm
Hi There,
I'm trying to use the LED flash sync feature in continuous grab mode on a Pi3B with a v2 camera. I followed the instructions from above and was able to get the flash pulse(s) for single grabs but in continuous grab mode (with exposure_mode off) I get no pulses. Should this possible?
---
EDIT
Subsequently, I re-tried disable_camera_led=2 in config.txt & re-compiling an edited dt-blob file to map IO17 to camera-0-LED and it works
perfectly.
---
Thanks again.
Steve.
I'm a little confused here, maybe someone can clear up for me. I also have a V2 camera but there's no LED on V2. How is the signal for the LED captured if it's not on the board?

Re: Hardware camera sync pulses

Posted: Wed Oct 31, 2018 1:15 pm
by ethanol100
ds72 wrote: I'm a little confused here, maybe someone can clear up for me. I also have a V2 camera but there's no LED on V2. How is the signal for the LED captured if it's not on the board?
The LED is not captured, the camera module and the Raspberry Pi's Image Signal Processor(ISP) are communicating. The ISP now uses these information to toggle the previously defined GPIO for the camera LED. Basically when it starts receiving some data, it will say "Yes I'm getting some data lets turn on the GPIO" and when the last piece of data is received it says "This is finished now, I will turn off the GPIO again".

It was just convenient to already have defined one GPIO which is used for the LED on the camera module, which is just re-purposed for the trigger pulses. Just lighting up a LED is not very useful and you need to assign the "camera LED" pin to another GPIO, this is done using the dt-blob. Now an external thing can be connected to this newly configured GPIO and gets informed when the image is captured. This could be for example a motor which will need to move to the next frame of a film roll to digitalize the film frame by frame.

(This is simplified, as we can configure if the ISP turns the led on or off during capture...)

Re: Hardware camera sync pulses

Posted: Wed Nov 14, 2018 12:01 am
by jyviko
Hi All,
First of all, thank you for the effort making this happen!

I might have read this thread 100 times and I am still not able to get pulses from the camera. I have an RPI3+ and RPI3v1.2. I have added the following under pins_3bplus and pins_3b2, respectively, under pin_config:

Code: Select all

[email protected] { function = "output"; termination = "no_pulling"; }; // GPU WILL USE THIS PIN FOR CAMERA 0 LED
and under pin_defines:

Code: Select all

[email protected]_0_LED {
type = "internal";
number = <0x15>;
};
Should type be "external"? Moreover, should disable_camera_led in config.txt be 2 or 3? I would like to get a trigger using both the still and the video port mode.

Currently, I am planning to connect GPIO21 to GPIO20 and trigger an event once the state has changed. Is there a way to get the state of GPIO21 internally and attach a callback without connecting it to another pin?

Thank for your help and feedback
Jyviko

Re: Hardware camera sync pulses

Posted: Wed Nov 14, 2018 11:14 am
by gordon77
To use pin 18 I changed...

Lines 1226 to 1228 to

Code: Select all

   [email protected]_0_LED {
               type = "internal";
               number = <18>;
and LIne 1193 to

Code: Select all

[email protected] { function = "output"; termination = "no_pulling"; }; // Camera LED
whether you use 2 or 3 depends which way you want the pulse to go

If 2, the camera LED GPIO will go low on a frame start, and high on frame end.
If 3, the camera LED GPIO will go high on a frame start, and low on frame end.

Re: Hardware camera sync pulses

Posted: Wed Nov 14, 2018 12:25 pm
by 6by9
Don't forget to compile the dt-blob.dts file into a dt-blob.bin.

Code: Select all

sudo dtc -I dts -O dtb -o /boot/dt-blob.bin dt-blob.dts

Re: Hardware camera sync pulses

Posted: Sat Mar 09, 2019 1:12 pm
by HermannSW
First I started with GPIO21:

Code: Select all

[email protected]:~ $ diff dt-blob.dts dt-blob.21.dts 
1362a1363
>             [email protected] { function = "output"; termination = "no_pulling"; }; // Camera LED
1395,1396c1396,1397
<                type = "external";
<                number = <6>;
---
>                type = "internal";
>                number = "<21>";
[email protected]:~ $ 
Compiling into "/boot/dt-blob.bin" resulted in many warnings, and after reboot v1 camera was not detected (vcgencmd get_camera).

Then I tried with GPIO18:

Code: Select all

1362a1363
>             [email protected]  { function = "output"; termination = "no_pulling"; }; // Camera LED
1395,1396c1396,1397
<                type = "external";
<                number = <6>;
---
>                type = "internal";
>                number = <18>;
[email protected]:~ $ 
Again many warnings during compilation, this time camera was detected after reboot, but no changes on GPIO18 can be captured with logic analyzer, although I added this to config.txt as described:

Code: Select all

[email protected]:~ $ tail -1 /boot/config.txt 
disable_camera_led property=3
[email protected]:~ $ 
There are 760 warnings during compile, so I show the 66 warnings related to 3bplus only to fit into this posting -- what do I do wrong?

Code: Select all

[email protected]:~ $ sudo dtc -I dts -O dtb -o /boot/dt-blob.bin dt-blob.18.dts 2>&1 | grep 3bplus 
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_config/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_CONTROL_ATTACHED has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_CAMERAS has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_I2C_PORT has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_SDA_PIN has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_SCL_PIN has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_SHUTDOWN has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_UNICAM_PORT has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_LED has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_ENABLE has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_0_INDICATOR has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_1_ENABLE has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_1_INDICATOR has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_LOW has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_PWR_OK has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_DISK_ACTIVITY has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_RUN has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_RUN_BOOT has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_ON has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_ON has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_SDA has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_SCL has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_CLK has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_LPO_CLK has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_LIMIT_1A2 has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_1V8_SEL has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected] has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_MODE has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_CARD_DETECT has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_SDA has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_SCL has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_I2C_PORT has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/[email protected]_SDA has a unit name, but no reg property
/boot/dt-blob.bin: Warning (unit_address_vs_reg): Node /videocore/pins_3bplus/pin_defines/pin_defi[email protected]_SCL has a unit name, but no reg property
[email protected]:~ $ 

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 10:29 am
by HermannSW
Can anybody please help to get this working?
The description sofar seems to be incomplete, I followed the steps and ended with errors and non-function.

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 11:18 am
by gordon77
Have you modified the correct lines? As far as l can see your line numbers don't agree with the ones l have shown above.

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 11:30 am
by 6by9
The instructions were written against dtc version 1.4.0. Later versions add more error checking which is redundant in this case as we're not fully complying with DT as used by Linux.
Add -q to the dtc command line to shut up warnings.

The cleanup in https://github.com/Hexxeh/rpi-firmware/ ... 0ac3eaf2dc broke the hardware sync pulses - this is where I wish I hadn't taken the easy option out of reusing disable_camera_led.
Revert to an earlier firmware, and I'm sorting out a patch.

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 4:30 pm
by HermannSW
gordon77 wrote:
Wed Mar 13, 2019 11:18 am
Have you modified the correct lines? As far as l can see your line numbers don't agree with the ones l have shown above.
Because I had to do your edits for 3bplus section, you did for 3b section.

6by9 wrote:
Wed Mar 13, 2019 11:30 am
Add -q to the dtc command line to shut up warnings.
Now command runs without warnings.

But the change (Bump to 4.19.25) you suspect to have broken camera sync pulses is past my running version:

Code: Select all

[email protected]:/etc $ uname -a
Linux raspberrypi3BplusX 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
[email protected]:/etc $ 

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 4:58 pm
by 6by9
HermannSW wrote:
Wed Mar 13, 2019 4:30 pm
But the change (Bump to 4.19.25) you suspect to have broken camera sync pulses is past my running version:

Code: Select all

[email protected]:/etc $ uname -a
Linux raspberrypi3BplusX 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
[email protected]:/etc $ 
a) I'm not a mind reader and you hadn't provided that previously.
b) You want "vcgencmd version" to report the firmware version as it is a firmware change.
c) Regardless, if you haven't added disable_camera_led then it is correctly defined anyway and should turn your GPIO on/off on camera access.

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 10:25 pm
by HermannSW
a) sorry
b)

Code: Select all

[email protected]:~ $ vcgencmd version
Nov  4 2018 16:35:17 
Copyright (c) 2012 Broadcom
version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)
[email protected]:~ $ 
c) I will try again, since the LED before the changes was on, I know that I had not configured disable_camera_led before the changes.
After the changes I have this per the instructions:

Code: Select all

[email protected]:~ $ tail -1 /boot/config.txt 
disable_camera_led property=3
[email protected]:~ $ 

Re: Hardware camera sync pulses

Posted: Wed Mar 13, 2019 11:15 pm
by HermannSW
Thanks, my fault, I had to correct last line to:

Code: Select all

$ tail -1 /boot/config.txt 
disable_camera_led=3
$ 
There is a bug left, doing as shown before with GPIO21 leads again to camera not detected after reboot.

With GPIO18 all is fine and I could see camera sync signals on logic analyzer after executing this command:

Code: Select all

$ raspivid -md 7 -w 640 -h 480 -fps 200 -o tst.h264 -pts tst.pts
$ 
Image


The first 7 frames get captured at 40fps (preview?), then framerate is 1000/4.984=200.64fps.

I don't know whether it is a bug or feature, but without "-o" option capturing is done at 40fps the whole time.


One question to @6by9:
Length from frame start to frame end is 4.699ms, nearly the whole 4.984ms for 200fps.
Can it be that GPU has 202fps max issue because the 4.699ms do not fit into the whole frame length then anymore?
If I would provide register set for [email protected] mode for v2 camera, could you test whether GPU would work with 360fps as well?


P.S:
Maybe it is easier to use a mode similar to raspiraw 640x240 or 640x480_s tools for GPU test?
Capturing only 240 lines should tale half the 4.699ms time and easily allow for 360fps.

Re: Hardware camera sync pulses

Posted: Thu Mar 14, 2019 11:22 am
by 6by9
HermannSW wrote:
Wed Mar 13, 2019 11:15 pm
The first 7 frames get captured at 40fps (preview?), then framerate is 1000/4.984=200.64fps.

I don't know whether it is a bug or feature, but without "-o" option capturing is done at 40fps the whole time.
Yes, it's a quirkiness I know of (one of the many) in raspivid that preview isn't at the specified frame rate.
The diff

Code: Select all

diff --git a/host_applications/linux/apps/raspicam/RaspiVid.c b/host_applications/linux/apps/raspicam/RaspiVid.c
index f80ba85..5760c18 100644
--- a/host_applications/linux/apps/raspicam/RaspiVid.c
+++ b/host_applications/linux/apps/raspicam/RaspiVid.c
@@ -1631,8 +1631,8 @@ static MMAL_STATUS_T create_camera_component(RASPIVID_STATE *state)
    format->es->video.crop.y = 0;
    format->es->video.crop.width = state->common_settings.width;
    format->es->video.crop.height = state->common_settings.height;
-   format->es->video.frame_rate.num = PREVIEW_FRAME_RATE_NUM;
-   format->es->video.frame_rate.den = PREVIEW_FRAME_RATE_DEN;
+   format->es->video.frame_rate.num = state->framerate;
+   format->es->video.frame_rate.den = VIDEO_FRAME_RATE_DEN;
 
    status = mmal_port_format_commit(preview_port);
 
diff --git a/host_applications/linux/apps/raspicam/RaspiVidYUV.c b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
index 93ea8fc..22ceed4 100644
--- a/host_applications/linux/apps/raspicam/RaspiVidYUV.c
+++ b/host_applications/linux/apps/raspicam/RaspiVidYUV.c
@@ -941,8 +941,8 @@ static MMAL_STATUS_T create_camera_component(RASPIVIDYUV_STATE *state)
    format->es->video.crop.y = 0;
    format->es->video.crop.width = state->common_settings.width;
    format->es->video.crop.height = state->common_settings.height;
-   format->es->video.frame_rate.num = PREVIEW_FRAME_RATE_NUM;
-   format->es->video.frame_rate.den = PREVIEW_FRAME_RATE_DEN;
+   format->es->video.frame_rate.num = state->framerate;
+   format->es->video.frame_rate.den = VIDEO_FRAME_RATE_DEN;
 
    status = mmal_port_format_commit(preview_port);
should fix it. I'll check it and create a PR at some point.
40fps is the minimum frame rate that mode 7 is configured to run at.
HermannSW wrote:One question to @6by9:
Length from frame start to frame end is 4.699ms, nearly the whole 4.984ms for 200fps.
Can it be that GPU has 202fps max issue because the 4.699ms do not fit into the whole frame length then anymore?
I haven't measured with a scope as to exactly why we can't exceed 202fps in the firmware. The sensor will obviously have constraints of its own, and IIRC it just stopped sending data when I tried it.
HermannSW wrote:If I would provide register set for [email protected] mode for v2 camera, could you test whether GPU would work with 360fps as well?

P.S:
Maybe it is easier to use a mode similar to raspiraw 640x240 or 640x480_s tools for GPU test?
Capturing only 240 lines should tale half the 4.699ms time and easily allow for 360fps.
I could try a reduced resolution, higher frame rate mode in the firmware. It's not a priority though, although interesting things often get slotted into time when rebuilding kernels etc...

Re: Hardware camera sync pulses

Posted: Sat Apr 06, 2019 12:11 pm
by Kozuch
6by9 wrote:
Wed Mar 13, 2019 11:30 am
The instructions were written against dtc version 1.4.0.
Is the current firmware already patched now or do I still need to use 1.4.0 to get the camera sync pulses?

Re: Hardware camera sync pulses

Posted: Sat Apr 06, 2019 6:35 pm
by 6by9
Kozuch wrote:
Sat Apr 06, 2019 12:11 pm
6by9 wrote:
Wed Mar 13, 2019 11:30 am
The instructions were written against dtc version 1.4.0.
Is the current firmware already patched now or do I still need to use 1.4.0 to get the camera sync pulses?
The only issue of using a more recent version of dtc is that it reports a load of warnings. Add -q to silence those on any version of dtc.

Sync pulses should work with the current firmware.

Re: Hardware camera sync pulses

Posted: Sun Apr 28, 2019 2:58 pm
by PCHSwS
6by9 wrote:
Mon Aug 07, 2017 4:00 pm
The one major proviso is that the GPIO selected MUST be one of the directly connected GPIOs on the SoC, and that is not the default situation on a Pi3 (it connects to an I2C GPIO expander).
All is not lost though, as on any Pi you can reconfigure the GPIO used for the camera LED via the dt-blob.bin file as detailed in https://www.raspberrypi.org/documentati ... uration.md and https://www.raspberrypi.org/documentati ... -camera.md.
Hi there, first of all thank you very much for the implementation of this feature! This was a thing I whished for some months ago, and now I need it again, so that comes in very handy :)

One question though. I'm working with raspi Zero W atm. dt-blob source tells me camera LED is GPIO40, and internal, so no need for reconfiguring it, if I got this right.
However, I cant find GPIO40 anywhere in the schematics, neither on the camera connector, not the Pi Board itself. Can you tell me a point where to tap into it?

Best regards
PCHSwS