naushir
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 136
Joined: Mon Apr 25, 2016 10:21 am

Re: HQ Camera external sync signals support added

Thu Sep 24, 2020 3:07 pm

Some quite strange results there. Not sure I can explain them.

Could you try an experiment? Switch to manual AGC mode for all 3 devices by adding the following to your command line:

Code: Select all

-ex off -ss 33000 -ag 1 -dg 1
There could be an issue with syncing devices if they are running different exposure parameters. I did try to account for this, but may have gotten something wrong.

User avatar
jwainwright87
Posts: 61
Joined: Wed Jul 01, 2020 10:46 am
Location: Liverpool, UK

Re: HQ Camera external sync signals support added

Thu Sep 24, 2020 3:15 pm

naushir wrote:
Thu Sep 24, 2020 3:07 pm
Some quite strange results there. Not sure I can explain them.

Could you try an experiment? Switch to manual AGC mode for all 3 devices by adding the following to your command line:

Code: Select all

-ex off -ss 33000 -ag 1 -dg 1
There could be an issue with syncing devices if they are running different exposure parameters. I did try to account for this, but may have gotten something wrong.
Thanks!

Just tried this with the updated command:

Code: Select all

sudo raspivid -o /vids/test40.h264 -t 20000 -w 1920 -h 1080 -fps 30 -awb greyworld -ex off -ss 33000 -ag 1 -dg 1 -v

Still the same issue.

I did just try switching the role of slave 2 (vertical white bars camera) and master so they are the reverse of each other (i.e. slave 2 is now master and master is now slave 2) and the new slave 2, previous master, was now showing the white vertical lines.

Very strange

naushir
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 136
Joined: Mon Apr 25, 2016 10:21 am

Re: HQ Camera external sync signals support added

Fri Sep 25, 2020 12:46 pm

I can't explain those results unfortunately. When I get time, I will create a multi-camera setup and try this again.

User avatar
jwainwright87
Posts: 61
Joined: Wed Jul 01, 2020 10:46 am
Location: Liverpool, UK

Re: HQ Camera external sync signals support added

Fri Sep 25, 2020 1:32 pm

naushir wrote:
Fri Sep 25, 2020 12:46 pm
I can't explain those results unfortunately. When I get time, I will create a multi-camera setup and try this again.

Thanks for taking the time to look into this.

I have got all the XVS lines connected together on a breadboard and all the grounds tied together. Is this right to have the 3 cameras connected in this way, or should they be connected in series? I.e. XVS feeding into GND on the next camera?

Thanks,
Jamie

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 04, 2020 9:22 am

HermannSW wrote:
Thu Aug 06, 2020 8:04 pm
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?
Today I wanted to followup on the HQ camera trigger MOSFET flash issue. HQ camera FSTROBE was too weak to trigger MOSFET's SIG pin as needed. I will amplify FSTROBE signal by sending through two inverters from 74HC04N hex inverter IC in series. Before testing the flash with MOSFET, I did setup workplace with 400Msps logic analyzer for verifying that all is setup correctly:
https://twitter.com/HermannSW/status/13 ... 8791173120
Image


I did connect logic analyzer channels 0/1/2 to FSTROBE/not(FSTROBE)/not(not(FSTROBE)); raspi2png snapshot demonstrates that all works as expected, FSTROBE duration because INCLK=24MHz and this /boot/config.txt setting:

Code: Select all

# Width of the pulse, in units of the INCLK period.
imx477_fstrobe_width=240
snapshot.png.jpg
https://twitter.com/HermannSW/status/1312671468791173120
snapshot.png.jpg (64.45 KiB) Viewed 6924 times

Finally zooming into FSTROBE rising edge shows, that not(not(FSTROBE)) delay is only 10ns(!). The software solution with gpioRead/gpioWrite I used before to trigger diy highspeed flash had 4 orders of magnitude longer delay (around 130µs)!
snapshot2.part.jpg
snapshot2.part.jpg
snapshot2.part.jpg (22.89 KiB) Viewed 6924 times

P.S:
74HC04N VCC is connected with Pi 3.3V pin.
Last edited by HermannSW on Sun Oct 04, 2020 9:58 pm, edited 2 times in total.
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 04, 2020 5:11 pm

In order to verify that flash gets triggered correctly, I needed something moving fast, locally.
I used mini drone propeller, powered by Arduino Uno GND/3.3V, Uno powered from Pi4B USB.
Also on the left side you see 5000lm led highspeed flash.
On left side of right photo you see MOSFET controlling the flash.
Right of the Pi4B is the minibreadboard with hex inverter described in previous posting.
not(not(FSTROBE)) is connected to MOSFET SIG pin:
setup.jpg
setup.jpg
setup.jpg (19.89 KiB) Viewed 6904 times

This is FSTROBE related part of /boot/config.txt:

Code: Select all

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=520

# 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=2400
Flash is delayed 520 lines, and has duration 2400/24MHz=100µs.
Mini drone propeller is rotating really fast, with 34mm diamter blade:
https://github.com/Hermann-SW/Raspberry ... shots-tool
Powering today is really suboptimal, but I have to live with what is here in hospital.
Normally the motor can run radially with ̶4̶7̶ 35.6m/s(!) at blade tips.
With flash duration 100µs that would be ̶4̶ ̶.̶7̶ 3.6mm, so definitely motor did run slower.
Anyway duration was long enough to see that blade rotates fast:
tst.30%.jpg
tst.30%.jpg
tst.30%.jpg (7.28 KiB) Viewed 6904 times

This is copied out propeller from 2028x1080 frame at 100% size:
tst.part.jpg
tst.part.jpg
tst.part.jpg (7.52 KiB) Viewed 6904 times

This was the command used to capture the photo:

Code: Select all

$ raspistill -md 1 -w 2028 -h 1080 -p 5,22,1014,540 --roi 0.25,0.25,0.5,0.5 -o tst.jpg
The flash was blinking a lot because raspistill captures many frames during (default 5s) capture time, not only the one stored in jpeg.

I took videos with raspivid, but frames were damaged because of bad powering of mini drone motor. With separate powering the motor from constant voltage mains adapter at home I will capture video. At home I also have laser tachometer to determine exact rpm of blade motor during video capturing.

Summary for today:
Two inverters in series can easily amplify HQ camera FSTROBE pin, allowing it to trigger arbitrary flashes via MOSFET.
Last edited by HermannSW on Mon Oct 05, 2020 7:55 am, edited 1 time in total.
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 04, 2020 9:39 pm

The 2nd line comment is correct.
The variable name and 1st line comment (taken from initial posting) are wrong!
And the numbers always correspond to 12MP mode, are wrong for eg. mode1 2028x1080.
# 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=520

Why?
First I did set

Code: Select all

imx477_fstrobe_cont_trig=0
For raspistill this leads to an initial flash short after starting the command, and a single flash when capturing the jpeg.

Then I did set

Code: Select all

imx477_fstrobe_delay=2320
and different other numbers. That number was the total rows getting exposed from 0 to 2319 in that case. Lines below do not see the flash and keep dark in dark room. I did "-md 1 -w 4056 -h 3040" raspistill capture in dark room, and the last line lighted is line 2319 (12MP image scaled to 15% for forum attachment): I did capture this frame with imx477_fstrobe_width=1200, corresponding to 50µs flash duration, and flash very near to blanket over bent knee:
tst.2320.15%.jpg
tst.2320.15%.jpg
tst.2320.15%.jpg (9.43 KiB) Viewed 6879 times

When setting imx477_fstrobe_delay to values >3040, always the whole frame is exposed to the flash. A better name describing what it does would be imx477_fstrobe_last_row.


In previous posting soldering 3rd hand in bottom half was lighted by next frame flash.
(that capture was done with imx477_fstrobe_cont_trig=1)
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Mon Oct 05, 2020 8:17 am

With

Code: Select all

imx477_fstrobe_cont_trig=0
I just verified that there is a single flash at start with raspivid only.

More importantly, besides initial flash, each saved frame with raspistill gets its flash:

Code: Select all

$ raspistill -md 3 -w 4056 -h 3040 -p 5,22,1014,540 --focus -o tst.%04d.jpg -s &
$ pid=$!
$ kill -s USR1 $pid
$ kill -s USR1 $pid
...
$ kill $pid
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Mon Oct 05, 2020 7:19 pm

In 2nd last posting we have seen that imx477_fstrobe_delay would better be named imx477_fstrobe_last_row.

In very early posting in this thread I showed that the amount of rows exposed can be restricted with "--shutter":
viewtopic.php?f=43&t=281913#p1717420


All 12MP frames were scaled to 15% size for forum attachment.
The bottom exposed row is the same for the three frames because of imx477_fstrobe_delay=2280 in /boot/config.txt.

Capturing 12MP frame with raspistill is done with 10fps framerate. So 50ms shutter time exposes roughly half of the rows (the shadow you see is the 5000lm led used for flashing, from behind):

Code: Select all

$ raspistill -md 3 -w 4056 -h 3040 -p 515,22,507,380 -o tst..50.jpg --shutter 50000
tst.50.png
tst.50.png
tst.50.png (143.5 KiB) Viewed 6822 times

25ms shutter time exposes roughly a quarter of rows:

Code: Select all

$ raspistill -md 3 -w 4056 -h 3040 -p 515,22,507,380 -o tst..25.jpg --shutter 25000
tst.25.png
tst.25.png
tst.25.png (77.63 KiB) Viewed 6822 times

And 12.5ms shutter time exposes 1/8th of the rows:

Code: Select all

$ raspistill -md 3 -w 4056 -h 3040 -p 515,22,507,380 -o tst..125.jpg --shutter 12500
tst.125.png
tst.125.png
tst.125.png (36 KiB) Viewed 6822 times

Summary:

imx477_fstrobe_delay
➥bottom row number of exposed rows

--shutter
➥how many rows get exposed

imx477_fstrobe_width/24
➥flash duration in µs on camera FSTROBE (to be amplified, like not(not(FSTROBE)) before)
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Wed Oct 07, 2020 2:22 pm

For capturing frames with a single flash per frame, the imx477_fstrobe_* settings provide for more than needed options with super fine time resolution, as shown on the last few postings.

For more than one flash per frame the imx477_fstrobe_* settings are of no help. This posting shows how you can use HQ camera VSYNC together with pigpio C interface program to achieve multiple flashes per frame:
viewtopic.php?f=43&t=284108&p=1738021#p1738021

In that posting it is described in detail how to capture 12MP frame of fast rotating (333 rotations per second, 35.6m/s at blade tips) mini drone propeller 5 times per frame with 19us duration flashes:
Image
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 11, 2020 1:53 pm

I only have access to one HQ camera currently, but want to play with camera in target mode.

From this previous posting in current thread:
viewtopic.php?f=43&t=281913&start=25#p1722778
XVS line is nearly always high, besides triggering. My 400Msps logic analyzer has 2.5ns resolution, and shows minimal pulse duration as 40ns, maximal as 42.5ns, with average 41.07ns.
Frequency of the signal is camera framerate, was 80fps (mode4 1012x760) then.

Today I used pigpio library pigs command to create similar signal:

Code: Select all

pi@raspberrypi4B2:~ $ sudo pigpiod
pi@raspberrypi4B2:~ $ pigs hp 12 80 999997
pi@raspberrypi4B2:~ $ 
TIL that for PI4B requested frequency is derived from is 375MHz (BCM2711), different to 250MHz for all other PIs:
http://abyz.me.uk/rpi/pigpio/pigs.html#HP

For created 80Hz (hardware) PWM I measured minimally 37.5ns and maximally 40ns LOW duration, with 38.3ns on average. Will go with that signal and connect GPIO12 with HQ camera XVS, and configure "imx477_trigger_mode=2" in Pi /boot/config.txt as sync device:
pwm.XVS.80Hz.40ns.jpg
pwm.XVS.80Hz.40ns.jpg
pwm.XVS.80Hz.40ns.jpg (30.13 KiB) Viewed 6720 times
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 11, 2020 2:47 pm

naushir wrote:
Fri Sep 18, 2020 11:52 am
naushir wrote:
Wed Sep 09, 2020 8:07 am
Earlier in this thread, it was mentioned that for raspivid, you must run both (source and sink) instances within a few 100ms of each other. Otherwise we get a timeout on the sink waiting for frames. When we get some time, this will be fixed, but for now starting both instances as close as possible is the workaround.
Work for this is now complete, and should be available in the latest firmware (via rpi-update). With this update, any device that is configured as a trigger sink will have timeouts disabled. This should allow more lenient timing when starting up multiple devices.
Just verified that, without the PWM signal from previous posting.
Instead constant high signal on GPIO12 connected to HQ camera XVS with camera in sync mode.
Recording completes after default of 5 seconds, with no frame captured.
But without any sync error messages as before (after sudo rpi-update and reboot):

Code: Select all

pi@raspberrypi4B2:~ $ sudo pigpiod
pi@raspberrypi4B2:~ $ pigs m 12 w
pi@raspberrypi4B2:~ $ pigs w 12 1
pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts
pi@raspberrypi4B2:~ $ cat tst.pts
# timecode format v2
pi@raspberrypi4B2:~ $ 
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Sun Oct 11, 2020 7:21 pm

External triggering with the PWM signal described in 2nd last posting really works!

Pi GND/GPIO12 is connected to HQ camera GND/XVS.
HQ camera configured as sync device:

Code: Select all

pi@raspberrypi4B2:~ $ tail -4 /boot/config.txt 
# 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.
imx477_trigger_mode=2
pi@raspberrypi4B2:~ $

First test, 80Hz PWM matching 80fps raspivid command:

Code: Select all

pi@raspberrypi4B2:~ $ sudo pigpiod
pi@raspberrypi4B2:~ $ pigs hp 12 80 999997
pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380  
pi@raspberrypi4B2:~ $ 
ptsanalyze confirms that all is fine:
https://github.com/Hermann-SW/userland/ ... ptsanalyze

Code: Select all

pi@raspberrypi4B2:~ $ ptsanalyze tst.pts
creating tstamps.csv
387 frames were captured
majority framerate 80fps
  frame delta time[us] distribution
      1 12422
      1 12476
      1 12480
      1 12483
      1 12484
      1 12485
      1 12487
      1 12488
      1 12489
      1 12490
      3 12491
      1 12492
      4 12493
      5 12494
      5 12495
     11 12496
     27 12497
     27 12498
     62 12499
     71 12500
     65 12501
     39 12502
     15 12503
      7 12504
      9 12505
      8 12506
      2 12507
      2 12508
      1 12509
      1 12510
      1 12511
      1 12513
      1 12514
      1 12516
      1 12517
      2 12521
      1 12524
      1 12578
> after skip frame indices (middle column)
0 frame skips (0%)
average framerate 80fps
pi@raspberrypi4B2:~ $ 

Next test, triggering with 84Hz although raspivid framerate is 80fps does not work (as expected):

Code: Select all

pi@raspberrypi4B2:~ $ pigs hp 12 84 999997
pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380
pi@raspberrypi4B2:~ $ cat tst.pts
# timecode format v2
pi@raspberrypi4B2:~ $ 

Next, 60Hz PWM with 80fps raspivid results in 60fps captured video:

Code: Select all

pi@raspberrypi4B2:~ $ pigs hp 12 60 999997
pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380
pi@raspberrypi4B2:~ $ ptsanalyze tst.pts
creating tstamps.csv
288 frames were captured
majority framerate 59fps
  frame delta time[us] distribution
      2 16658
      1 16660
      1 16661
      2 16662
      7 16663
     13 16664
     38 16665
     67 16666
     78 16667
     42 16668
     14 16669
     10 16670
      4 16671
      3 16672
      1 16673
      1 16675
      1 16678
> after skip frame indices (middle column)
0 frame skips (0%)
average framerate 60fps
pi@raspberrypi4B2:~ $ 

Last (for now) is disabling PWM, then after start of 80fps raspivid command, 70Hz PWM for 1.5 seconds, in 5 seconds raspivid execution time:

Code: Select all

pi@raspberrypi4B2:~ $ pigs w 12 1
pi@raspberrypi4B2:~ $ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380 &
[1] 13395
pi@raspberrypi4B2:~ $ pigs hp 12 70 999997 && sleep 1.5 && pigs w 12 1
pi@raspberrypi4B2:~ $ 

ptsanalyze shows a single frameskip, with 69fps average framerate:

Code: Select all

pi@raspberrypi4B2:~ $ ptsanalyze tst.pts
creating tstamps.csv
90 frames were captured
majority framerate 69fps
  frame delta time[us] distribution
      1 14281
      1 14282
      2 14283
     12 14284
     20 14285
     25 14286
     19 14287
      5 14288
      1 14289
      1 28573
> after skip frame indices (middle column)
> 28573,214288
1 frame skips (1%)
average framerate 69fps
pi@raspberrypi4B2:~ $ 
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Mon Oct 12, 2020 6:28 pm

Now I was able to trigger single frame captures at arbitrary points in time using raspivid.

For the experiments HQ camera did look down vertically onto Pi4B and mini breadbord.
This is a 1012x760 frame from video captured.
Pi 3.3V/GPIO18/GND is connected to 74HC04N GND/2A/VCC.
74HC04N GND/2B(inverter output) is connected to HQ camera VCC/XVS:
frame.0109.png.jpg
frame.0109.png.jpg
frame.0109.png.jpg (91.25 KiB) Viewed 6564 times

Yesterday we have seen how to use pigpio pigs hp command to create signal with 40ns low duration at 80Hz frequency.
I wanted to trigger with single command as well, and needed to create 40ns low pulse.
The only method I know of to trigger precise nanosecond length pulses with Raspberry Pi is based on pigpio nanopulse.c example:
viewtopic.php?f=33&t=270197&p=1641091#p1641091
In addition to the changes needed to make the 2016 Pi1 code work on all PIs, I used scaling by 4/3 needed by Pi4B this time as well. I verified that the code creates nanosecond pulses of requested length using 400Msps logic analyser. This is complete diff:

Code: Select all

$ diff nanopulse.c.orig nanopulse.c
4c4
< gcc -o nanopulse nanopulse.c
---
> gcc -I/opt/vc/include -L/opt/vc/lib -lbcm_host -o nanopulse nanopulse.c
21,23c21,25
< #define CLK_BASE  0x20101000
< #define GPIO_BASE 0x20200000
< #define PWM_BASE  0x2020C000
---
> #include <bcm_host.h> 
> #define PI_BASE_ADDR  bcm_host_get_peripheral_address()
> #define GPIO_BASE     (PI_BASE_ADDR + 0x200000)
> #define PWM_BASE      (PI_BASE_ADDR + 0x20C000)
> #define CLK_BASE      (PI_BASE_ADDR + 0x101000)
240a243,244
>    nanos = (nanos * 4) / 3;
> 
251c255
<       pulses, cfg.divider * 2 * cfg.bits, gap, cfg.divider, cfg.bits);
---
>       pulses, cfg.divider * 2 * cfg.bits *3 / 4, gap, cfg.divider, cfg.bits);
$
nanopulse.c uses PWM to create nanosecond long high pulses.
I was not able to invert the signal in software, that is the reason I used 74HC04N hex inverter IC.

Because of inversion, for setting camera XVS to high, I need to set GPIO18 to low.
The 80Hz PWM signal on GPIO12 yesterday ...

Code: Select all

$ pigs hp 12 80 999997
... now has to be this on GPIO18 because of the inverter:

Code: Select all

$ pigs hp 18 80 3

First I created 80HZ PWM on GPIO18, then started 10 second recording with raspivid with sink mode camera (which immediately starts because of the needed PWM signal on XVS) and the executed combined command:
End PWM, then create three 39ns long low pulses on XVS with different delays in between:

Code: Select all

$ pigs hp 18 80 3
$ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380 -t 10000 & 
[1] 3527
$ pigs w 18 0 && sudo ./nanopulse 39 1 9 && sudo ./nanopulse 39 1 9 && sleep 0.2 && sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ 
Then I executed the last command line a second time:

Code: Select all

$ pigs w 18 0 && sudo ./nanopulse 39 1 9 && sudo ./nanopulse 39 1 9 && sleep 0.2 && sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ 

These are the last 9 lines of recorded timestamp file, with time deltas added.
The first 3 frames are the last captured at 80fps (with 12.5ms time delta).
Then each group of following 3 frames timestamps was created by one command line shown above:

Code: Select all

1362.501	
1375.002	12.5
1387.502	12.5
1446.579	59.1
1492.413	45.8
1717.798	225.4
4134.210	2416.4
4184.902	50.7
4420.123	235.2

I created a 2fps animation from the last seven 1012x760 frames, extracted from tst.h264 by:

Code: Select all

rm -f frame.* && ffmpeg -i tst.h264 frame.%04d.png
The frames were scaled to 25%, with delta time overlayed top left.
As can be seen, each frame's exposure time is given by the time delta:
x.anim.gif
x.anim.gif
x.anim.gif (119.59 KiB) Viewed 6564 times
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12336
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HQ Camera external sync signals support added

Mon Oct 12, 2020 7:28 pm

Did you measure the voltage levels on XVS when in output mode?

If the information I have is correct, then V(IF) is 1.8V. The datasheet shows protection diodes in the equivalent circuit for XVS between the GPIO and both DGND and V(IF). Pumping 3.3V into that isn't going to play nicely in the longer term.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Tue Oct 13, 2020 8:57 am

6by9 wrote:
Mon Oct 12, 2020 7:28 pm
Did you measure the voltage levels on XVS when in output mode?
Will do when back at home.
Thanks for the warning comment.
If the information I have is correct, then V(IF) is 1.8V. The datasheet shows protection diodes in the equivalent circuit for XVS between the GPIO and both DGND and V(IF). Pumping 3.3V into that isn't going to play nicely in the longer term.
From "Input/Output equivalent circuits" on page 12, and bottom text says "V_IF: 1.8V power supply".
https://www.uctronics.com/download/Imag ... 477-DS.pdf
20201013_102438.jpg
20201013_102438.jpg (37.48 KiB) Viewed 6497 times
The reason why pumping 3.3V did work can be found on page 3 of datasheet. While recommended V_IF is 1.8 ± 0.1V, same page absolute maximum ratings for V_IF is -0.3 to 3.3V.

From what I read, resistor ladder voltage divider is best for keeping my 40ns low pulse. With 680 and 470 Ohm resistors I could bring down 3.3V to 1.951V, which should be good enough given XVS absolute maximal ratings. I will test when back at home.


P.S:
Sending 40ns long low pulses to XVS of sink HQ camera allows for arbitrary long exposures, no 239 seconds upper limit anymore:
viewtopic.php?f=43&t=273358&p=1741281#p1741091
Image
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12336
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HQ Camera external sync signals support added

Tue Oct 13, 2020 10:50 am

HermannSW wrote:
Tue Oct 13, 2020 8:57 am
The reason why pumping 3.3V did work can be found on page 3 of datasheet. While recommended V_IF is 1.8 ± 0.1V, same page absolute maximum ratings for V_IF is -0.3 to 3.3V.
I have the schematic. V_IF is a power supply rail, and that rail IS at 1.8V. It doesn't matter what the min/max permitted values are.

You have therefore forward biased that protection diode into conduction by connecting it to 3.3V, and it's likely to only be output resistances that are limiting that current from the GPIO at 3.3V, through that diode, and being absorbed by the 1.8V V_IF rail.
HermannSW wrote:P.S:
Sending 40ns long low pulses to XVS of sink HQ camera allows for arbitrary long exposures, no 239 seconds upper limit anymore:
viewtopic.php?f=43&t=273358&p=1741281#p1741091
Image
I know you're excited over this, but please avoid spamming multiple threads in your excitement.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

sam598
Posts: 2
Joined: Tue Oct 13, 2020 8:10 pm

Re: HQ Camera external sync signals support added

Tue Oct 13, 2020 8:14 pm

6by9 wrote:
Tue Oct 13, 2020 10:50 am
I have the schematic. V_IF is a power supply rail, and that rail IS at 1.8V. It doesn't matter what the min/max permitted values are.
Does this mean that the fstrobe pin outputs at 1.8v?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12336
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HQ Camera external sync signals support added

Wed Oct 14, 2020 6:33 am

sam598 wrote:
Tue Oct 13, 2020 8:14 pm
6by9 wrote:
Tue Oct 13, 2020 10:50 am
I have the schematic. V_IF is a power supply rail, and that rail IS at 1.8V. It doesn't matter what the min/max permitted values are.
Does this mean that the fstrobe pin outputs at 1.8v?
I would expect so, yes.
Hermann has provided a link to a partial datasheet, and from that you can see the equivalent circuit on the fstrobe line where the driver is connected to V_IF, which is 1.8V.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Wed Oct 14, 2020 7:50 pm

6by9 wrote:
Tue Oct 13, 2020 10:50 am
You have therefore forward biased that protection diode into conduction by connecting it to 3.3V, and it's likely to only be output resistances that are limiting that current from the GPIO at 3.3V, through that diode, and being absorbed by the 1.8V V_IF rail.
OK, I used a voltage divider to not send more than 1.8V to XVS pin of HQ camera.

I used the smallest resistors I found, and R1=82Ω and R2=100Ω should be perfect match:
https://ohmslawcalculator.com/voltage-d ... calculator
V_S=3.3 should give V_OUT=1.813V.

This is true if I connect GND/VCC from Pi to the voltage divider.
But pin 2B (=not(2A)) does not provide 3.3V but much less.

This is the connection diagram used:
voltage_divider.png
voltage_divider.png
voltage_divider.png (9.19 KiB) Viewed 6398 times
I placed the 4 resistors onto a 2nd mini breadboard:
https://stamm-wilbrandt.de/en/forum/20201014_161619.jpg
20201014_161619.15%.jpg
20201014_161619.15%.jpg
20201014_161619.15%.jpg (56.45 KiB) Viewed 6398 times

I had no idea how to do it correctly, so I did it iteratively and ended up with four 100Ω resistors, two used in parallel for 250Ω in total.
With 250Ω resistor connected to GND/2B (and without HQ camera connected) measured voltage was 2.29V.
Measuring between 0Ω and 200Ω showed 1.80V(!).

But when connecting GND/XVS from HQ camera as well voltage between GND and 2B dropped to 2.10V.
Measuring between 0Ω and 200Ω showed only 1.58V.

I tested and everything worked with 1.58V, so I have my working good enough voltage divider that does not pump more than 1.8V into XVS.
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

User avatar
jbeale
Posts: 3898
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: HQ Camera external sync signals support added

Wed Oct 14, 2020 8:04 pm

I'm not sure I followed everything, but if you're trying to drive 182 ohms to ground from a GPIO pin, since I=V/R and 3.3V / 182 ohms = 18 mA you would need to make sure your source is OK with driving 18 mA. The output has some equivalent internal resistance; I don't know what it is exactly but I know the full supply rail is reached exactly only with no current output, and my guess is the output would be noticeably less than 3.3V at 18 mA current, due to internal resistance of the driver.

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Thu Oct 15, 2020 12:04 am

jbeale wrote:
Wed Oct 14, 2020 8:04 pm
I'm not sure I followed everything, but if you're trying to drive 182 ohms to ground from a GPIO pin, since I=V/R and 3.3V / 182 ohms = 18 mA you would need to make sure your source is OK with driving 18 mA. The output has some equivalent internal resistance; I don't know what it is exactly but I know the full supply rail is reached exactly only with no current output, and my guess is the output would be noticeably less than 3.3V at 18 mA current, due to internal resistance of the driver.
Good to know.

In previous postings I connected not(GPIO18) on 74HC04N (pin 2B) to XVS (input in that case for external trigger)
So it is not GPIO18 driving 182Ω or 250Ω but the hex inverted output pin 2B.
Since Pi4B GND/3.3V powers 74HC04N GND/VCC the voltage divider is driven from Pi 3.3V rail and not from GPIO18.

250Ω voltage divider is driving less current than 182Ω (3.3V / 250Ω = 13mA), so that was definitely a better choice than 182Ω.
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

Siddarth
Posts: 2
Joined: Wed Oct 14, 2020 9:53 am

RPi Zebronics Zeb-Crisp pro USB webcam built-in mic driver support

Thu Oct 15, 2020 10:44 am

Hi,

I recently purchased RPi 4 Module B for education and online classes. I have a Zebronics Zeb-Crisp Pro purchased for Zoom meetings. I do experience problem with the video quality and mic as it doesn't capture the voice though being recognized as audio input device. Though not sure, I suspect it could be because of the driver as the device is not in the USB devices list. Being a beginner, I do not have much experience in managing RPi or Linux. Any help is much appreciated.

Thanks,
Sid
USB.png

nicolap8
Posts: 692
Joined: Mon Mar 13, 2017 9:45 pm

Re: HQ Camera external sync signals support added

Thu Oct 15, 2020 4:59 pm

HermannSW wrote:
Thu Oct 15, 2020 12:04 am
jbeale wrote:
Wed Oct 14, 2020 8:04 pm
I'm not sure I followed everything, but if you're trying to drive 182 ohms to ground from a GPIO pin, since I=V/R and 3.3V / 182 ohms = 18 mA you would need to make sure your source is OK with driving 18 mA. The output has some equivalent internal resistance; I don't know what it is exactly but I know the full supply rail is reached exactly only with no current output, and my guess is the output would be noticeably less than 3.3V at 18 mA current, due to internal resistance of the driver.
Good to know.

In previous postings I connected not(GPIO18) on 74HC04N (pin 2B) to XVS (input in that case for external trigger)
So it is not GPIO18 driving 182Ω or 250Ω but the hex inverted output pin 2B.
Since Pi4B GND/3.3V powers 74HC04N GND/VCC the voltage divider is driven from Pi 3.3V rail and not from GPIO18.

250Ω voltage divider is driving less current than 182Ω (3.3V / 250Ω = 13mA), so that was definitely a better choice than 182Ω.
Hi Hermann,
from photos I see that your multimeter is a cheap one: before trusting it, you have to calibrate it against something better. Often these items have an error of some hundreds of millivolts :(

Reading the datasheet of 74HC04 https://www.ti.com/lit/gpn/SN74HC04 we can note some intersting things(1):
- table 6.1 Absolute Maximim Ratings: do not let more than 20 mA through a pin! This table is very important: exceeding some parameter IS dangerous!
- table 6.4 Electrical Characteristics: if you power the chip with (say) 4.5V and sink (require from the output) -4mA the expected voltage is MIN 3.98 V, typical 4.3 V. This explains that you measured.
- table 6.5 Switching characteristics: tpd at 4.5V can be as large as 24ns (use the worst!); at 3.3V it will be more. Here "pd" is Propagation Delay but the "t" is not the "typical" cited at paragraph 8.3, it's only "time"! You know, in the rank there are lies, big lies, statistics and datasheets :twisted: ;-)
- 10 Power Supply Recommendations: use bypass capacitor! Even on breadboards! Something like this:
(big: https://www.nicolaperotto.it/images/Capacitor 1uF.jpg)(2)
Capacitor 1uF small.jpg
Capacitor 1uF ceramic
Capacitor 1uF small.jpg (73.97 KiB) Viewed 6281 times
- 11.2 Layout Example: remember to tie at +Vcc or GND unused inputs. This is very important: never let CMOS input float.

For the resistor divider I would start with a 1800/1500 Ohm pair, this limits the current to 1mA. Normally I would prefer something "bigger": the current is more important than the voltage (some millivolt less is not a problem), a 3k3/2k2 pair can be sufficient.

This chip can be good for pulses of some ms. But for the 40ns pulses I would like use something better, like a 74LVC04.


(1) LS or SN are indicating different vendors, in this case there are not (usually) significant differences.
(2) Photo take with the HQ camera, the microscope lens, the stand you linked some time ago and some 3d printed accessories.
Microscope small.jpg
Microscope small.jpg (24.92 KiB) Viewed 6281 times

User avatar
HermannSW
Posts: 4941
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: HQ Camera external sync signals support added

Thu Oct 22, 2020 8:57 am

I will followup on the resistors, but currently the 0Ω/200Ω/250Ω voltage divider works like a charme, and there are so much things to try based on the "trigger frame capture with 40ns duration low pulse on sink mode HQ camera XVS pin".

We have already seen in this thread, that triggering at arbitrary point in time is posible, and that the whole time since last exposure becomes the exposure time for the newly triggered frame:
Image

I used this technique to create arbitrary long exposures with HQ camera, starting with this posting:
viewtopic.php?f=43&t=273358&start=50#p1744900
This is proof that really 60 minutes got captured, for details see:
viewtopic.php?f=43&t=273358&start=50#p1745789
Image


Now the new technique allows for something different as well. Without HQ camera XVS slave trigger technique, frames are captures with raspivid/raspiraw/raspistill at a specific framerate. Actions like flashes can be triggered upon VSYNC signal in a frame, but the frame start cannot be set arbitrarily. So these steps allow to capture a frame at arbitrary point in time with the correct exposure (eg. 12.5ms for 80fps):
  1. trigger exposure (that leads to a highly overexposed frame normally)
  2. after 12.5ms trigger exposure again
Step b) does capture the frame of interest, step a) guarantees the correct capturing timepoint.
Only side effect is that for each wanted frame, an additional frame gets captured just before.
The additional frames can be eliminated in post processing easily (take every other frame, starting at some offset).


That new technique has another application with just capturing a single frame of interest at a specific point in time:

Yesterday I started to capture (100m/s) airgun pellet inflight with HQ camera "normally":
viewtopic.php?f=43&t=288886

The technique to trigger single digit microsecond long flashes with 5000lm led allows for multiple exposures with HQ camera at daylight:
viewtopic.php?f=43&t=284108&p=1738021#p1738021
Image

Using a sound trigger allows to trigger flashes at a specific point in time, relative to sound trigger. This allows to have areas at left and right of frame without a (pellet here) exposure:
https://github.com/Hermann-SW/Raspberry ... nd-trigger
Image

Now triggering steps a) and b) with a microphone allows to start capturing 12.5ms exposure frame exactly when microphone module triggers on airgun shot. Instead of waiting for delay in microseconds and then doing some flashes as done with audio:shots.c for previous v1 camera sound trigger work, for this application only two frames (for steps a and b) get captured. 100m/s bullet moves 100m/s / 80Hz = 1.25m/s while capturing 12.5ms exposure frame. Therefore capturing bullet on frame captured in step b) is guaranteed, and as in long_exposure script
viewtopic.php?f=43&t=273358&start=50#p1744900
only few frames get captured. The "ffmpeg -i tst.h264 -ss 3 frame.%04.png" trick allows to only extract very few frames from the captured tst.h264. The second last is the bright one from step a and can be ignored. Just the last extrcated frame is the one with the bullet.
https://github.com/Hermann-SW/memrun
https://stamm-wilbrandt.de/2wheel_balancing_robot
https://stamm-wilbrandt.de/en#raspcatbot
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/en/Raspberry_camera.html

Return to “Camera board”