HQ Camera external sync signals support added

[naushir]

The newest firmware (obtained via rpi-update) adds support for external pulse/sync signals that can be probed at the test points on the HQ Camera PCB. The signals available and their usage are described below:

Horizontal and Vertical Sync
H and V sync signals can be enabled by adding

Code: Select all

imx477_hv_sync_enable=1

to the bottom of /boot/config.txt. The imx477 sensor generates these sync pulses on readout start of the line and frame. Horizontal sync pulse can be probed on the GPO test point, and vertical sync pulse can be probed on the XVS test point.

The following settings for these pulses can be changed by adding the appropriate parameters to config.txt:

Code: Select all

# H/V sync polarity.  Set to 0 for active low, 1 for active high.
imx477_hsync_polarity
imx477_vsync_polarity

# Pulse width, proportional to the pixel clock frequency. 
# Valid values are 0 (smallest width) to 7 (largest width)
imx477_hsync_width
imx477_vsync_width

Flash strobe
A flash strobe signal can be enabled by adding

Code: Select all

imx477_fstrobe_enable=1

to the bottom of /boot/config.txt. With this enabled, a pulse is generated at the start of frame exposure, typically uses to strobe an external flash device. This pulse can be probed on the FSTROBE test point.

The following settings for flash strobe can be changed by adding the appropriate parameters to config.txt:

Code: Select all

# Set to 0 for single strobe pulse, or 1 for continuous pulses every frame.
imx477_fstrobe_cont_trig

# Number of lines to delay before triggering the pulse.
# Set this to the frame height if you want all lines to be exposing for the flash strobe.
imx477_fstrobe_delay

# Set to 1 to only trigger the pulse in stills capture mode.
imx477_fstrobe_stills_only

# Width of the pulse, in units of the INCLK period.
imx477_fstrobe_width

Trigger Mode Sync
It is possible to synchronise the readouts of two or more imx477 sensors by wiring their XVS test points together. These devices can be on separate Pi boards, or can be on a Compute Module (CM) board with two sensors attached.

One camera must act as a trigger source, and the others act as trigger sinks. To set this up, the following parameter must be set in config.txt:

Code: Select all

# Set to 0 to disable.
# Set to 1 to act as a trigger source device on a non-CM board.
# Set to 2 to act as a trigger sync device on a non-CM board.
#
# For a CM board, use imx477_trigger_mode:0=1 to set camera 0 as trigger source, or imx477_trigger_mode:0=2 to set camera 0 as trigger sync.
# Similarly, use imx477_trigger_mode:1=1 to set camera 1 as trigger source, or imx477_trigger_mode:1=2 to set camera 1 as trigger sync.
imx477_trigger_mode

[HermannSW]

Naushir,

that sounds fantastic !!

Trigger Mode sync with one source and one or more sync HQ cameras is probably the best of all the new features you added.

Before playing with that, few questions upfront:

1. I think this is important enough information, can you pin this thread in Camera forum?
2. On horizontal/vertical sync:
   1. sync pulse widths 0..7 are "proportional to pixel clock frequency"; how long is 0, how long is 7?
   2. how is imx477_vsync related to "normal" Hardware Camera Sync pulses?
      viewtopic.php?f=43&t=190314
3. On Flash strobe:
   Width of the pulse is in units of pixel clock cycles.
   How does pixel clock relate to raspiraw line_time_ns?
   Or can the pixel clock values for the modes be found somewhere else?

   Code: Select all

   🍓 egrep "(\.regs|line_time_ns)" raspiraw/imx477_modes.h 
         .regs          = imx477_4056x3040_regs,
         .line_time_ns  = 28571,
         .regs          = imx477_2028x1080_regs,
         .line_time_ns  = 0x31c4,
         .regs          = imx477_2028x1520_regs,
         .line_time_ns  = 0x31c4,
         .regs          = imx477_4056x3040_regs,
         .line_time_ns  = 28571,
         .regs          = imx477_1012x760_regs,
         .line_time_ns  = 0x1460,
   🍓 
   

[naushir]

sync pulse widths 0..7 are "proportional to pixel clock frequency"; how long is 0, how long is 7?

I do not have the measurements to hand, and am not able to do this again just yet (working from home, and do not have the logic analyser connected up). Perhaps somebody in the community could do the measurements.

how is imx477_vsync related to "normal" Hardware Camera Sync pulses?
viewtopic.php?f=43&t=190314

This is entirely different mechanism. Here, all signals are generated by the sensor device itself.

On Flash strobe:
How does pixel clock relate to raspiraw line_time_ns?

Sorry, this is an error on my part. Flash strobe pulse width is in units of the INCLK period (1/INCLK frequency). Edited the original post to reflect this.

[HermannSW]

sync pulse widths 0..7 are "proportional to pixel clock frequency"; how long is 0, how long is 7?

I do not have the measurements to hand, and am not able to do this again just yet (working from home, and do not have the logic analyser connected up). Perhaps somebody in the community could do the measurements.

Thank you, I did the measurements, for "raspivid -t 0" with the different config.txt settings:

Code: Select all

pi@raspberrypi4B2:~ $ tail /boot/config.txt 
imx477_hv_sync_enable=1

# H/V sync polarity.  Set to 0 for active low, 1 for active high.
imx477_hsync_polarity=1
imx477_vsync_polarity=1

# Pulse width, proportional to the pixel clock frequency. 
# Valid values are 0 (smallest width) to 7 (largest width)
imx477_hsync_width=6
imx477_vsync_width=7
pi@raspberrypi4B2:~ $ 

I only have one Raspberry HQ camera, and want to test source/sync camera as well. But I do have an Arducam imx477 camera prototype as well:
viewtopic.php?f=43&t=249483&p=1679997&h ... 2#p1674141

Raspberry HQ camera has only test points exposed on the module. Before I really need to solder, I did the measurements with the Arducam imx477 camera, because there the contacts are exposed as holes, and the logic analyzer probes fit there much more easily. 16MP smartphone photo here:
https://stamm-wilbrandt.de/en/forum/20200804_210157.jpg
Scaled to 15%:

20200804_210157.15%.jpg

20200804_210157.15%.jpg (69.67 KiB) Viewed 32053 times

I used my DSView 400Msps logic analyzer, software installed on my 4GB Pi4B:

snapshot.png.jpg

snapshot.png.jpg (92.59 KiB) Viewed 32053 times

These are the puls widths measured:

Code: Select all

0: 45/47.5ns
1: 92.5/95ns
2: 237.5ns
3: 475ns
4: 950ns
5: 2.38µs
6: 4.76/4.7625µs
7: 9.5225µs

P.S:
The widths are proportional to: 1, 2, 5, 10, 20, 50, 100, 200

[plugwash]

Rather than triggering one HQ camera from another, is it possible to trigger a HQ camera from some other source? if so what are the electrical characteristics and are there any caveats to be aware of?

[naushir]

Rather than triggering one HQ camera from another, is it possible to trigger a HQ camera from some other source? if so what are the electrical characteristics and are there any caveats to be aware of?

Sadly that is unsupported as we don't have any details on the electrical characteristics of the sync pulse. However, if you can capture a trigger source pulse and recreate it externally to feed a sink, I see no reason why it should not work.

[6by9]

Rather than triggering one HQ camera from another, is it possible to trigger a HQ camera from some other source? if so what are the electrical characteristics and are there any caveats to be aware of?

Sadly that is unsupported as we don't have any details on the electrical characteristics of the sync pulse. However, if you can capture a trigger source pulse and recreate it externally to feed a sink, I see no reason why it should not work.

I don't know how this integrate with exposure time, which seems very weird.

The XVS signal triggers/denotes the start of readout. Exposure started a configured number of lines before that, and so exposure for the next frame starts a configured number of lines after XVS. If the rate of trigger pulses coming in on XVS isn't very close to that expected, then the exposure is going to be far longer than intended, as the exposure started at the expected point, but readout was delayed for an undefined amount of time.

All a bit weird and unclear in the datasheet, so it's likely to need a bit of experimentation.

[naushir]

The XVS signal triggers/denotes the start of readout. Exposure started a configured number of lines before that, and so exposure for the next frame starts a configured number of lines after XVS. If the rate of trigger pulses coming in on XVS isn't very close to that expected, then the exposure is going to be far longer than intended, as the exposure started at the expected point, but readout was delayed for an undefined amount of time.

All a bit weird and unclear in the datasheet, so it's likely to need a bit of experimentation.

Yes, it is all a bit confusing. Having un-matched shutter speeds is not really something that is likely to play very nicely here. I would probably recommend fixed (same) shutter speeds between all sensors to start with.

[6by9]

Yes, it is all a bit confusing. Having un-matched shutter speeds is not really something that is likely to play very nicely here. I would probably recommend fixed (same) shutter speeds between all sensors to start with.

Fixed frame rates is probably more likely to be the requirement. I'd expect shutter speeds to be triggered off that framing, but it's all a little undefined.

[HermannSW]

For source/sync camera capturing I need to solder cables to HQ camera anyway, so I did today for the three pins of interest. My DSView 400Msps logic analyzer has cable pairs, with seperate GND for each line. So I did superglue the 3 male headers for cables soldered to XVS, FSTROBE and GPO together. And I did superglue a 3x1 male header on top, glued the 3 together and glued HQ camera GND cable to that as well. All three pairs of logic analyzer cables can be connected to HQ camera easily that way, 16MP smartphone photo here:
https://stamm-wilbrandt.de/en/forum/20200805_195216.jpg
Scaled to 15%:

20200805_195216.15%.jpg

20200805_195216.15%.jpg (47.95 KiB) Viewed 31886 times

I did redo the puls width measurements from yesterday. raspivid does not work with mode 3 because >1920 lines. mode 2 2028x1520 did not work either. Pulse width for mode 1 2028x1080 and mode 4 1012x760 were the same, and the same as measured yesterday with Arducam imx477 camera prototype. I used this command to capture mode 4 at 80fps framerate:

Code: Select all

pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts
pi@raspberrypi4B2:~ $

No frameskips happened:
https://github.com/Hermann-SW/userland/ ... ptsanalyze

Code: Select all

pi@raspberrypi4B2:~ $ ptsanalyze tst.pts 
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
creating tstamps.csv
389 frames were captured
majority framerate 80fps
  frame delta time[us] distribution
      1 12481
      2 12489
     13 12490
     39 12491
     94 12492
    118 12493
     78 12494
     28 12495
      9 12496
      2 12497
      1 12498
      1 12505
> after skip frame indices (middle column)
0 frame skips (0%)
average framerate 80fps
pi@raspberrypi4B2:~ $ 

This is DSView snapshot showing 80Hz for vertical sync (horizontal sync 108.28KHz) and the known longest puls width 9.5225µs:

snapshot.png.jpg

snapshot.png.jpg (93.64 KiB) Viewed 31886 times

Horizontal sync was 65.94KHz for mode 1 2028x1080.

[ethanol100]

Thank you very much for releasing this feature.

I connected the XVS and ground of two imx477 modules, each module is connected to a different pi.
Which is now the recommended procedure to capture?

If I first start the sync and then start the source, the sync will not show any images and complains about not receiving data.
If I first start the source and then the sync it works as expected, but now I don't know which images belong together(I have a different number of frames in each videos).

Will this also work for still images? It kind of does, but I have no clue how...

I did not want to solder on the camera, therefore, I create a 3D printed connector:

connector.jpg (59.46 KiB) Viewed 31843 times

[HermannSW]

Will this also work for still images?

I think it will.

I test the new features one by one in order to use strobe later to correlate frames between two cameras until I know what is going on.

Last night I did capture (5s) videos with 33fps framerate with this command:

Code: Select all

pi@raspberrypi4B2:~ $ raspivid -md 1 -w 2028 -h 1080 -fps 33 -o tst.h264 -pts tst.pts
Too many macroblocks/s: Increasing H264 Level to 4.2
pi@raspberrypi4B2:~ $ 

I added these settings to bottom of /boot/config.txt:

Code: Select all

pi@raspberrypi4B2:~ $ tail -14 /boot/config.txt 
imx477_fstrobe_enable=1

# Set to 0 for single strobe pulse, or 1 for continuous pulses every frame.
imx477_fstrobe_cont_trig=1

# Number of lines to delay before triggering the pulse.
# Set this to the frame height if you want all lines to be exposing for the flash strobe.
imx477_fstrobe_delay=5

# Set to 1 to only trigger the pulse in stills capture mode.
imx477_fstrobe_stills_only=0

# Width of the pulse, in units of the INCLK period.
imx477_fstrobe_width=10000
pi@raspberrypi4B2:~ $ 

I varied imx477_fstrobe_delay and tested with 5 and 10:

DSLogic-la-200805-21.zip

DSLogic-la-200805-21.zip

(192.62 KiB) Downloaded 151 times

First on a new frame column labled 2 goes to 1.
Later, after strobe delay, column 1 goes to 1.
I used libreoffice calc to determine time delta between the associated timestamps and determined overall min and max.
These are the min and max values, in microseconds:

Code: Select all

 5: 920.35   920.3925
10: 996.1725 996.2

The values are not 0 based, and from my previous posting we know horizontal sync was 65.94KHz for mode 1 2028x1080.

One unit of strobe delay is ((996.2+996.1725)/2-(920.3925+920.35)/2)/5 = 15.163µs.
Which matches horizontal sync quite well:

Code: Select all

1000000/65.94 = 15165.30

In the evening I will trigger my diy highpeed flash
https://github.com/Hermann-SW/Raspberry ... ed-flashes
with FSTROBE signal and experiment with imx477_fstrobe_cont_trig=0 in order to get a single flash only. Hopefully that will be triggered for the final image of raspistill. In dark room I will take image with flash duration being a small part of overall frame time, and determine the minimal and maximal line numbers of frame that will be not dark, and compare to strobe delay and strobe width settings in config.txt.


P.S:
Forgot to mention that I measured the length for imx477_fstrobe_width being 1000 and 10000 as well:

Code: Select all

 1000:  41.6725µs
10000: 416,7325µs

So a unit is 41.67325ns.

P.P.S:
INCLK runs at 24MHz:

Code: Select all

1000000000/41.67325 = 23996208.6

[6by9]

I connected the XVS and ground of two imx477 modules, each module is connected to a different pi.
Which is now the recommended procedure to capture?

If I first start the sync and then start the source, the sync will not show any images and complains about not receiving data.
If I first start the source and then the sync it works as expected, but now I don't know which images belong together(I have a different number of frames in each videos).

Will this also work for still images? It kind of does, but I have no clue how...

There is no synchronisation between the sensors and when they switch modes, so it'll be a bit hit and miss except in stereo mode on a Compute Module. The best option is probably to set both systems to "signal" trigger mode, and then have an external app to receive a broadcast and send the signal. Those should be close enough together to trigger the mode switches at the same point.

As commented earlier, it'll also need fixed exposure times (and hence frame rates) to work sensibly.

The "not receiving data" error should be after several seconds with raspistill - it's something like 5 frames at the slowest framerate that is permitted, which is 1fps there. Raspivid may be a bit too swift on that. I seem to recall it tries a reset process a couple of times first, which probably isn't ideal either.
It seems like it'd be sensible to remove the timeout if being a slave on external syncs. That may be easier said than done, but we can have a look.

[naushir]

The "not receiving data" error should be after several seconds with raspistill - it's something like 5 frames at the slowest framerate that is permitted, which is 1fps there. Raspivid may be a bit too swift on that. I seem to recall it tries a reset process a couple of times first, which probably isn't ideal either.
It seems like it'd be sensible to remove the timeout if being a slave on external syncs. That may be easier said than done, but we can have a look.

Ah that does explain things. In my brief testing, I was using raspistill, so did not see any timeouts (knew they might occur, but thought they were effectively ignored). Will have to think about how to disable (or extend?) timeouts in the trigger sink cases.

[HermannSW]

I did want to capture with HQ camera FSTROBE triggered flashes of diy highspeed flash today.

First I had to realize today that FSTROBE cable was disconnected. I do need 3.3V pin for the MOSFET GND/3.3V/SIG lines, so I soldered that in addition to yesterday. I wanted to superglue the headers on HQ camera connector, but then it would be difficult to connect female headers to the male pins because they would be too close to tripod screw. So I did superglue a 2x1 Lego piece onto the camera connector, and the headers from yesterday as well as the new 3.3V header onto that Lego piece as strain relieve. Here is 16MP smartphone photo:
https://stamm-wilbrandt.de/en/forum/20200806_211312.jpg
Here scaled to 15% for forum attachment:

20200806_211312.15%.jpg

20200806_211312.15%.jpg (41.74 KiB) Viewed 31695 times

I wanted to capture with same command as yesterday, but with 30fps framerate for easy upload of video to youtube. I wanted the flash to start at line 270 and light for 540 lines. That way top and bottom quarter of each frame would be black (dark room) and only the middle 50% would show for each frame. So I did set in /boot/config.txt

Code: Select all

imx477_fstrobe_delay=270

and calculated strobe duration units as 540*15.163µs/41.67325ns = 196481.4 (slightly more than 8ms):

Code: Select all

# Width of the pulse, in units of the INCLK period.
imx477_fstrobe_width=196481

All looks good on 400Msps logic analyzer:

snapshot.png.jpg

snapshot.png.jpg (97.91 KiB) Viewed 31695 times

Then I did run raspivid command with 30fps framerate and got flashes, but they are really dim.

So I connected Mosfet to GDN/3.3V/GPIO4 of Raspberry and used shots program to trigger 8ms flashes 30 times per second:
https://github.com/Hermann-SW/Raspberry ... ools/shots

Code: Select all

$ shots 30 8000 25333 4

The result was ultra bright lighted scene.
Even when I reduce flash on time from 8000µs to only 100µs, the results is way brighter than when Mosfet was connected to HQ camera.

So definitely the FSTROBE pins triggers correctly per the logic analyzer, but definitely it cannot control the Mosfet SIG pin like Pi's GPIO4 pin.
Must be something electrical, maybe current?
What current can HQ camera FSTROBE pin deliver?
What can I put between HQ camera FSTROBE pin and Mosfet SIG pin to make flashes as bright as when triggered by GPIO4?


The only difference to this photo today is, that I do use a single 100V IRF520 Mosfet instead of two 24V IRF520 Mosfets in series on the photo (50W led driver delivers 38V/1.5A DC to 5000lm led):
https://github.com/Hermann-SW/Raspberry ... -capturing

diy.highspeed.flash.jpg

diy.highspeed.flash.jpg (75.51 KiB) Viewed 31695 times

[naushir]

Then I did run raspivid command with 30fps framerate and got flashes, but they are really dim.

Just to clarify, do you mean that the images coming out of raspivid are dark? Or is the flash lamp intensity is low? Or the Mosfet cannot trigger with the FSTROBE pulse?

[HermannSW]

Then I did run raspivid command with 30fps framerate and got flashes, but they are really dim.

Just to clarify, do you mean that the images coming out of raspivid are dark? Or is the flash lamp intensity is low? Or the Mosfet cannot trigger with the FSTROBE pulse?

Sorry that I was unclear.
The flashes were triggered by the MOSFET, but the flash light on the scene was too dim.
As I said, when triggering MOSFET with only 100µs 30 times in a second from GPIO4 scene looks much brighter than triggering MOSFET SIG line from HQ camera FSTROBE pin for 8ms 30 times a second.
Do you have any information on the current FSTROBE can deliver?
In case that is same or more GPIO4 can deliver, what else can make the difference?

P.S:
The 5000lm led is so bright that I got clear images of pellet inflight (97m/s) with only 9µs flash duration multiple exposures:
https://github.com/Hermann-SW/Raspberry ... nt-9000eps

[naushir]

Sorry that I was unclear.
The flashes were triggered by the MOSFET, but the flash light on the scene was too dim.
As I said, when triggering MOSFET with only 100µs 30 times in a second from GPIO4 scene looks much brighter than triggering MOSFET SIG line from HQ camera FSTROBE pin for 8ms 30 times a second.
Do you have any information on the current FSTROBE can deliver?
In case that is same or more GPIO4 can deliver, what else can make the difference?

I'm afraid I cannot seem to find much in the way of electrical characteristics for the FSTROBE output that could help. The current draw when compared to GPIO4 will almost certainly be significantly smaller. Without knowing more details on you actual circuitry and components, there is not much I could suggest on how to get it working.

[HermannSW]

I wanted to follow up on this during Denmark vacation.
Yesterday I brought up two PIs, networking, displays, 5000lm highspeed flash and logic analyzer:
https://twitter.com/HermannSW/status/12 ... 0753953793

Today I saw that two of the three connections did not work.
Only vertical sync did work.
So I tried to fix with soldering iron, but I forgot a multimeter.
And there is too much flux.
Will have to fix when back home in 3 weeks;
Luckily my soldering attempts did not break HQ camera.

[HermannSW]

OK, I will not have access to HQ camera FSTROBE for the next 3 weeks.
But VSYNC should be good enough for 5000lm flash experiments.

I had workaround ideas for HQ camera signals not powerful enough to drive MOSFET:

1. software, continously read one GPIO with pigpio C interface, and copy to GPIO connected to MOSFET SIG
2. use two 74xxx NOTs in series to amplify HQ camera signal for MOSFET

Today I verified that (a) will work.
This is simple GPIO counting code:

Code: Select all

🍓 cat rd.c 
/*
   $ gcc -O6 -o rd rd.c -lpigpio -lrt -lpthread
   $
   
   $ sudo killall pigpiod
   $ sudo ./rd N
   $
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>

#include <pigpio.h>

#define gpioDin 4

int N=1, s=0;

int main(int argc, char *argv[])
{
   assert(argc == 1+1);
   assert(0 < (N = atoi(argv[1])));
       
   assert(gpioInitialise()>=0);

   gpioSetMode(gpioDin, PI_INPUT);

   for(int i=1; i<=N; ++i)
   {
     s += gpioRead(gpioDin);
   }

   gpioTerminate();

   printf("%d(%d) %.2lf‰\n", s, N, 1000.0*s/N);

   return 0;
}
🍓 

For "raspivid -t 0" against HQ camera it reports 1.25% duty of VSYNC signal.
100 million readings on Pi4B in roughly 8 seconds is nice:

Code: Select all

🍓 gcc -O6 -o rd rd.c -lpigpio -lrt -lpthread
🍓 time sudo ./rd 100000000
1249517(100000000) 12.50‰

real	0m7.882s
user	0m7.811s
sys	0m0.417s
🍓

For "raspistill -t 0" against HQ camera it reports 0.661% duty of VSYNC signal.

Code: Select all

🍓 time sudo ./rd 100000000
661317(100000000) 6.61‰

real	0m7.875s
user	0m7.828s
sys	0m0.407s
🍓

P.S:
Played with 1012x760@80fps, some observations with 100µs duration flashes do not match my expectations; more tests tomorrow:

smartphone photo of dark room with two PIs, HQ camera and 5000lm led

EgI3CyMWoAA6_xd.jpeg (216.98 KiB) Viewed 31237 times

[HermannSW]

I successfully did short flashes lighting only part of frames captured with raspivid.
This is tonight's test setup:

Left Pi3B+ has HQ camera connected.
Right Pi4B uses HQ camera VSYNC to trigger 5000lm LED flashes via MOSFET (behind 9" LCD).
Camera with 35mm C-mount lens captures Pi pinout printout on the left.


I used this code to trigger flashes. It is called with two µs numbers, offset after VSYNC rising edge detected, and flash duration. Later, when I will have access to FSTROBE again, /boot/config.txt settings allow to trigger MOSFET directly (via two NOTs in series as signal amplifier):

Code: Select all

🍓 cat fl.c
/*
   $ gcc -O6 -o fl fl.c -lpigpio -lrt -lpthread
   $
   
   $ sudo killall pigpiod
   $ sudo ./fl o d
   $
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>

#include <pigpio.h>

#define gpioDin 4
#define gpioDout 17

int d=0, o=0;

int main(int argc, char *argv[])
{
   assert(argc == 1+2);
   assert(0 <= (o = atoi(argv[1])));
   assert(0 <= (d = atoi(argv[2])));
       
   assert(gpioInitialise()>=0);

   gpioSetMode(gpioDin, PI_INPUT);
   gpioSetMode(gpioDout, PI_OUTPUT);
   gpioWrite(gpioDout, 0);

   for(;;)
   {
     while (!gpioRead(gpioDin))  {}
     assert(0 == usleep(o));
     gpioWrite(gpioDout, 1);
     assert(0 == usleep(d));
     gpioWrite(gpioDout, 0);
   }

   gpioTerminate();

   return 0;
}
🍓 

I did run "sudo ./fl 1500 4000" and got these partially lighted scenes. They stay at same position of 1012x760 preview displayed top right at 50% in both directions. As can be seen at bottom, raspivid captures mode4 at 80fps:

vsync.1500.4000.png.jpg

vsync.1500.4000.png.jpg (87.93 KiB) Viewed 31221 times

Next I reduced flash duration to 1000µs, with smaller lighted area:

vsync.1500.1000.png.jpg

vsync.1500.1000.png.jpg (76.72 KiB) Viewed 31221 times

Finally I reduced flash duration to 1µs. I was surprised that several lines show lighted. line_time_ns is <1,000,000,000/80/760=16447ns:

vsync.1500.1.png

vsync.1500.1.png (200.28 KiB) Viewed 31221 times

[HermannSW]

I wanted to determine how long green laser needs to light so that HQ camera can record it, with laser directed into (35mm C mount) lens. For that I wanted to use demo nanopulse.c pigpio example:
viewtopic.php?f=33&t=270197&p=1641091#p1641091

That demo needs hardware PWM in order to produce nanosecond precision pulses. Yesterday I had problems to run fl.c from previous posting for GPIO18, so I used GPIO17.
This was test setup as described. Differnt to trigger 38V/1.5A for 5000lm led before, this time MOSFET controls 3.3V for green laser only:

20200825_224717.15%.jpg

20200825_224717.15%.jpg (52.46 KiB) Viewed 31142 times

First I captured with offset 0µs after VSYNC risig edge, and 1µs duration:

vsync.0.1.png

vsync.0.1.png (216.73 KiB) Viewed 31142 times

Since green laser is active for 1µs only, the lines showing laser dot have already started integration?

Next I did 1µs duration 1620µs offset flashes (at 80fps, "sudo ./fl 1620 1"):

x.anim.gif

x.anim.gif (30.81 KiB) Viewed 31142 times

Since shape remains same in animation, what we see is green laser light.
What is below black bar in middle of dot is light from current frame (I increased offset until black bar was in middle).
Since there was no light from current frame, light above black bar seems to be from previous frame flash.
Is that correct explanation?
[There was no shutter time specified in raspivid command)]

[RichShumaker]

I understand about 42% of this sync discussion. I have read it, I just don't fully understand everything yet.
With that said I am an intermediate camera and RasPi Camera user.
I just got my first HQ Camera and am thinking about a second.

Here is my questuon, i want to sync the future camera(on its own Pi) to my current camera. I would like the Videos to be recorded "in sync" similar to Genlocking old VTR's and Analog Cameras.
Can I sync my hypothetical 2 Pi, 2 Cameras for "frame" accurate sync(I know that rolling shutter sensors are not global meaning pixel by pixel not frame by frame).
How do I achieve this?
Do I simply attach a hardwire between cameras?
Do I send the Camera Sync to a GPIO and "trigger" that GPIO?

Any videos or how too's that anyone can point me too would be greatly appreciated.

Thanks in advance for the help.

[6by9]

I understand about 42% of this sync discussion. I have read it, I just don't fully understand everything yet.
With that said I am an intermediate camera and RasPi Camera user.
I just got my first HQ Camera and am thinking about a second.

Here is my questuon, i want to sync the future camera(on its own Pi) to my current camera. I would like the Videos to be recorded "in sync" similar to Genlocking old VTR's and Analog Cameras.
Can I sync my hypothetical 2 Pi, 2 Cameras for "frame" accurate sync(I know that rolling shutter sensors are not global meaning pixel by pixel not frame by frame).
How do I achieve this?
Do I simply attach a hardwire between cameras?
Do I send the Camera Sync to a GPIO and "trigger" that GPIO?

Any videos or how too's that anyone can point me too would be greatly appreciated.

Connect the XVS line on the HQ cameras together.
On one Pi add "imx477_trigger_mode=1" to config.txt
On any other Pis add "imx477_trigger_mode=2" to config.txt

Currently you'll need to call raspivid at the same point (within a few 100ms) on all Pis as the trigger sink will otherwise time out due to not receiving any CSI2 data.

[RichShumaker]

Thanks 6by9 That Rocks!!!

Saving for HQ #2 to try this.