sanjaya
Posts: 14
Joined: Thu Jul 05, 2018 11:00 am

utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Fri Jul 20, 2018 1:55 pm

reposting as a new thread jic it would increase exposure level.
i hope someone would be interested to pick this up do further explorations.

ov5647 sensor can handle global shutter (if the hardware is available)
despite the lack of hardware support (nor a software to utilize them) arducam exposes the frex and strobe pads in its board
http://www.arducam.com/raspberry-pi-cam ... rformance/

we have proven that arducam can be used to control strobe light
we've also proven that ordinary ov5647 camera can also be used for the same purpose.

according to the doc, there are 2 modes of operations:
1. frex as input (a.k.a frex-pad)
2. frex as output (a.k.a frex-i2c)
sanjaya wrote:
Wed Jul 11, 2018 10:25 am

Code: Select all

struct sensor_regs ov5647_setup_frex_pad[] = {
  { STROBE_FREX_MODE_SEL, 0x08 }, // 0x3B07
  { SC_CMMN_PAD_OEN2    , 0xE8 }, // 0x3002
  { DVP_VSYNC_MODE      , 0x02 }, // 0x4704
  { SC_CMMN_PAD_PK      , 0x00 }, // 0x3011 // [1] enable frex; 0 == enable!!!
  { TIMING_HSYNCST      , 0x08 }, // 0x3817 
  { STROBE_FREX_CTRL0   , 0x0F }, // 0x3B06
};
struct sensor_regs ov5647_setup_frex_i2c[] = {
  { STROBE_FREX_MODE_SEL, 0x09 },
  { SC_CMMN_PAD_OEN2    , 0xF8 },
  { STROBE_FREX_EXP_H1  , 0x5D },
  { STROBE_FREX_EXP_L   , 0xB7 },
  { STROBE_FREX_CTRL0   , 0x0F },
};
struct sensor_regs ov5647_emit_frex_i2c[] = {
  { STROBE_FREX_EXP_REQ , 0x01 }, // 0x3B08
};
frex-pad
you can verify with raspi-raw (after minor modification - in you know where)
- connect a pwm circuit to the frex pin (set it up to pulse according to desired fps)
- connect the strobe pin to the led
- start the pwm
- run the (modified) raspiraw with above registers

frex-i2c (hack)
for this i modified another application (raspiraw by rafael Muñoz Salinas)
- connect gpio to the led (it should be connected to the strobe pin, but this is a hack)
- modify the code such that every grab request emits i2c command to 0x3B08 as well as turn the led on for a short duration
caveats: sometimes the i2c command fail.
extra notes:
regardless of which mode we use, frex trigger would cause the camera to drop the current frame and start anew
- the camera would need to reset the sensors first; and how long it takes depend on how many have been read for the dropped frame.
- - - if frex frequency is higher than normal stream frequency, we'd never get a frame
- - - as the difference between frex and stream frequency grows a dark band at the top of the frame would becomes thicker.
- what happen to the dropped frame? in raspiraw derivative it would be passed to video_buffer_callback
- - - might want to check the pts. if th pts remains the same, the buffer contains a stale frame -- not the dropped frame with partial content.
- - - if u decided to ignore the stale frame, be sure to keep the pipeline going. breaking the flow here would stall the system

revising the comment in the code above
- the 4 lsb of 0x3B06 determines the strobe duration
- - - from the oscilloscope, 15 units roughly equals to 340µs -- this doesn't fit with the line times that 6by9 has shared in multiple occasions
- - - although the doc said that 0x3B0C & 0x3B0B also control strobe width, changing these has no impact to strobe duration.
the tests were done in vga resolution

due to the short strobe duration, intense light would be required
- strobe intensity diminishes very quickly as the distance grows
- adopting frex-i2c hack instead would enable greater control for the strobe duration

u might want to inverse the frex signal in 0x3B07 to conserve energy
- in frex-pad mode i set a short pwm.duty_cycle; timing shouldn't matter here because there's no actual global shutter hardware.

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Fri Jul 20, 2018 4:24 pm

sanjaya wrote:
Fri Jul 20, 2018 1:55 pm
ov5647 sensor can handle global shutter (if the hardware is available)
despite the lack of hardware support (nor a software to utilize them) arducam exposes the frex and strobe pads in its board
http://www.arducam.com/raspberry-pi-cam ... rformance/
Minor correction here. The OV5647 has a global RESET. When triggered it resets the full sensor, starts the exposure time, and will then start reading out the frame. To get a global shutter behaviour will require a mechanical shutter to be closed at the end of the exposure period, otherwise each successive line will be exposed for a longer and longer period. I even went as far to confirm this with an Omnivision support engineer.

I have previously said that if someone can provide a useful and working register set with raspiraw that I would entertain merging it into the firmware. I'm expecting a pull request to implement it, not random patches posted on the forum.
I2C frex is not useful as there is no easy or reliable way to inject the required commands. The GPIO is only brought out on some 3rd party camera modules, therefore it adds little benefit to Raspberry Pi, only to those 3rd parties.
What I'm looking for is a simple register set that allows an external trigger to trigger capture of a frame, and/or a set that does something sensible on the strobe line.

AFAIK I have never made any comment about how FREX and STROBE are controlled and the timings therein. I can't see any units being stated on the datasheet, and they may or may not relate to line lengths.
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.

sanjaya
Posts: 14
Joined: Thu Jul 05, 2018 11:00 am

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sat Jul 21, 2018 12:58 am

6by9 wrote:
Fri Jul 20, 2018 4:24 pm
sanjaya wrote:
Fri Jul 20, 2018 1:55 pm
ov5647 sensor can handle global shutter (if the hardware is available)
despite the lack of hardware support (nor a software to utilize them) arducam exposes the frex and strobe pads in its board
http://www.arducam.com/raspberry-pi-cam ... rformance/
Minor correction here. The OV5647 has a global RESET. When triggered it resets the full sensor, starts the exposure time, and will then start reading out the frame. To get a global shutter behaviour will require a mechanical shutter to be closed at the end of the exposure period, otherwise each successive line will be exposed for a longer and longer period. I even went as far to confirm this with an Omnivision support engineer.
yes the lack of actual global shutter hardware might make this implementation a moot point
but perhaps by mandating extra requirements, e.g:
- use ir led against ir reflective surface
- - - bear in mind that sunlight carries a lot of ir, especially in tropical area
- - - if there are other ir source (in your expected bandwidth) you'd get double exposed frame
- use it in a dark room; e.g. a chamber within a bee hive
- intense strobe with horizontal & vertical sensor skips (to shorten scan time)
6by9 wrote:
Fri Jul 20, 2018 4:24 pm
I have previously said that if someone can provide a useful and working register set with raspiraw that I would entertain merging it into the firmware. I'm expecting a pull request to implement it, not random patches posted on the forum.
these are not production grade;
my intended audience are people like HermannSW, those in the bee counting project -- people with technical know-how and passion to tinker.

although it works just fine for normal usage, those that want to work at hundreds of fps would have to figure out how to set 0x3B06
there is also the matter of 0x3B0C & 0x3B0B. was the document wrong? or do we need to set some registers to enable longer strobe period?
6by9 wrote:
Fri Jul 20, 2018 4:24 pm
AFAIK I have never made any comment about how FREX and STROBE are controlled and the timings therein. I can't see any units being stated on the datasheet, and they may or may not relate to line lengths.
not specific to frex-strobe, but the unit should be a multiply of tline.
6by9 wrote:
Tue Jun 30, 2015 2:43 pm
I can confirm that in the line times for the various modes as configured in the firmware are:
- 1080P30 cropped: 29.584us
- 5MPix 15fps: 32.503us (this is the mode captured by jbeale and used in raspiraw)
- 5MPix 1/6-1fps: 183.789us
- 1296x976 binned: 23.216us
- 1296x730 binned: 23.216us
- 640x480 30-60fps: 31.749us
- 640x480 60-90fps: 21.165us
further clarification: 340us was observed with raspiraw working at 640x480 30fps:
340 / 15 = 22.6
without a clear guidance one would have to resort to trial and error.

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sat Mar 02, 2019 11:12 am

I am late to the party, but very interested.

I learned of the Global RESET capabilities from ethanol100 in "Re: Is there any photo/video of flying rifle bullet done with v2 camera?" thread:
https://www.raspberrypi.org/forums/view ... 6#p1434563
The v1 cam had a register to perform a "global reset" where after that all lines are stated to be exposed on the same time. The readout is then longer for the later lines, but as the flash behaves like a global shutter in a way, this does not matter.
.
6by9 wrote:I2C frex is not useful as there is no easy or reliable way to inject the required commands.
I doubt that, even for raspivid I was able to inject I2C commands to camera with only a minimal risk of clashes with I2C commands sent from GPU to camera:
"Re: Inspecting Pi camera registers over I2C without need for logic analyzer":
https://www.raspberrypi.org/forums/view ... 3#p1421743

As far as I can see there are no I2C commands sent to camera after "start_camera_streaming()" in raspiraw. So using I2C FREX should be without any risk using raspiraw.


In the last thread I pointed to I provided command i2cread that allows to read out i2c registers of v2 camera (either during a running "raspivid" or after having run raspiraw "camera_i2c" command). I just realized that this tool had 0x10 hardcoded for v2 camera. For v1 camera i2cread36.c can be used:

Code: Select all

$ diff i2cread.c i2cread36.c 
22c22
<     assert(ioctl(i2c_fd, I2C_SLAVE_FORCE, 0x10) >= 0);
---
>     assert(ioctl(i2c_fd, I2C_SLAVE_FORCE, 0x36) >= 0);
$ 

Chapter "4.11 FREX strobe flash control" documents the 13 relevant ov5647 registers (4.10 describes options):
https://cdn.sparkfun.com/datasheets/Dev ... df#page=44
Image


After having booted and just executed "camera_i2c" v1 camera has this set of FREX registers

Code: Select all

$ i2cread36 /dev/i2c-0 3B00 0d
00 00 08 00 04 00 04 08 00 02 04 00 3d 
$

During running "raspivid -md7 -w 640 -h 480" as well as during running "640x128_s 5000" this changed FREX register set can be read (only change 0x08 to 0x0c for register 3B07 STROBE_FREX_MODE_SEL:

Code: Select all

$ i2cread36 /dev/i2c-0 3B00 0d
00 00 08 00 04 00 04 0c 00 02 04 00 3d 
$

This changes frex_inv bit of that register from 0 to 1. After raspivid has ended (and camera_i2c has been run) or after raspiraw has finished, the initial register set can be seen again.


Some FREX related facts I found in several postings:
  • FREX and STROBE pins from ov5647 are NOT available on Sunny connector (that is sad as I will have to find another way of synchronizing (air-gap spark) flash with camera for capturing flying bullet image (at 375m/s))
  • I took successfully 1007fps closing mouse trap video with 19.5µs shutter time (exp=1 or expus=20) with v2 camera:
    https://www.raspberrypi.org/forums/view ... 8#p1433278
    Very bright light was needed (I used 5000lm or 10000lm LEDs)
  • You "can" do "global shutter" capturings with v1 camera without shutter hardware:
    • the integration time gets bigger and bigger for each line in the frame
    • no problem for 1µs flash duration needed by capturing flying bullet
    • no problem with exposure time being exactly line_time (19517ns for v2, 21165ns for v1)
    • even for X times the line_time exposure (exp=X) a frame will have correctly lighted lines starting at line X in frame, only lines 0..(X-1) will look darker

Next step is to find out what register settings exactly trigger FREX mode. Then running raspiraw with adding these register settings via "--regs " option should start recording without frames being captured. But every time "i2cwrite36 /dev/i2c-0 3b08 01" (and probably "i2cwrite36 /dev/i2c-0 3b08 00" afterwards) will trigger FREX I2C, a frame should get recorded. If that works, triggering "FREX I2C" at end of "saving Nth frame" in raspiraw.c via a new option would record nearly as fast as possible, and "--fps" option will have no meaning anymore. This should allow to get 665fps 640x128_s mouse trap video with closing bar not showing rolling shutter effect, and without blur with exp=1, because with measured 20m/s of closing mouse trap the bar will only move

Code: Select all

20m/s * 0.000021165s = 0.0004233m = 0.4233mm
This is v2 camera 1007fps 320x75 (from 640x150_s tool) frame taken with 19.5µs shutter time, you see rolling shutter effect for the closing bar.
v1 camera global reset exp=1 frame should show closing bar just vertical:
https://www.raspberrypi.org/forums/view ... 3#p1433883
Image


From the 13 FREX registers only 3b06 and 3b07 should be needed for initial testing described, later 3b0[145] as well for exposure, 3b0[23] for shutter time. Because STROBE pin of ov5647 is not accessible, registers 3b0[bc] (and 3b0a?) are not of interest.
Last edited by HermannSW on Sun Mar 03, 2019 7:20 am, edited 2 times in total.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sat Mar 02, 2019 4:49 pm

HermannSW wrote:
Sat Mar 02, 2019 11:12 am
From the 13 FREX registers only 3b06 and 3b07 should be needed for initial testing described, later 3b0[145] as well for exposure, 3b0[23] for shutter time.
I was wrong on registers 3b0[23], they are for STROBE_SHUTTER_DLY. You can control the delay a hardware shutter closes by that. The only important time is shutter time in 24 STROBE_FREX_EXP bits of 3b0[145] registers of ov5647.

Section 4.10.1 details the function of STROBE_FREX_EXP:
4.10.1 FREX control
user-defined exposure time (0x3B01, 0x3B04, 0x3B05), the shutter closes, preventing further integration and the image begins to read out. After the readout finishes, the shutter opens again and the sensor resumes normal mode, waiting for the next FREX request.

The minimal exposure recordings I did sofar where done with "-expus" or "-exp" options.
I remembered that I once reverse engineered how setting "--shutter" works, in this posting:
https://www.raspberrypi.org/forums/view ... 4#p1313917

It details register settings for a given shutter value for v2 camera (not of interest here), and details of register settings for v1 camera, measured by capturing I2C commands sent to camera with logic analyzer.:
Summary for v1 camera:
Setting shutter time for X microseconds is done by writing X/16000*12096 to registers 350[0-2].
For setting the shutter time to line_time_ns (21165 for v1 camera mode 7) setting 16 to the registers 350[0-2] "EXPOSURE" is needed:

Code: Select all

21.165/16000*12096 = 16.00074
Time for line_time_n2 for v2 camera makes more sense to me (just 1 (line)):

Code: Select all

19.517/20000*1024 = 0.9992704
It is not clear yet whether timing resolution of v1 STROBE_FREX_EXP is same as for v1 350[0-2], will have to test.

P.S:
With register 3b01 default of 0x00 this raspiraw option is needed for "16":

Code: Select all

--regs 3b04,0010
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sun Mar 03, 2019 7:44 am

HermannSW wrote:
Sat Mar 02, 2019 11:12 am
Next step is to find out what register settings exactly trigger FREX mode.
No, I did not read sanjaya's initial posting good enough:
sanjaya wrote:
Wed Jul 11, 2018 10:25 am
...

Code: Select all

struct sensor_regs ov5647_setup_frex_pad[] = {
  { STROBE_FREX_MODE_SEL, 0x08 }, // 0x3B07
  { SC_CMMN_PAD_OEN2    , 0xE8 }, // 0x3002
  { DVP_VSYNC_MODE      , 0x02 }, // 0x4704
  { SC_CMMN_PAD_PK      , 0x00 }, // 0x3011 // [1] enable frex; 0 == enable!!!
  { TIMING_HSYNCST      , 0x08 }, // 0x3817 
  { STROBE_FREX_CTRL0   , 0x0F }, // 0x3B06
};
struct sensor_regs ov5647_setup_frex_i2c[] = {
  { STROBE_FREX_MODE_SEL, 0x09 },
  { SC_CMMN_PAD_OEN2    , 0xF8 },
  { STROBE_FREX_EXP_H1  , 0x5D },
  { STROBE_FREX_EXP_L   , 0xB7 },
  { STROBE_FREX_CTRL0   , 0x0F },
};
struct sensor_regs ov5647_emit_frex_i2c[] = {
  { STROBE_FREX_EXP_REQ , 0x01 }, // 0x3B08
};
...

This seems to be all that is needed for my "without hardware shutter" experiment described before -- I would have missed 0x3002:

Code: Select all

struct sensor_regs ov5647_setup_frex_i2c[] = {
  { STROBE_FREX_MODE_SEL, 0x09 }, // 0x3B07 +frex_strobe mode: 0->1
  { SC_CMMN_PAD_OEN2    , 0xF8 }, // 0x3002 +io_frex_en
  { STROBE_FREX_EXP_H1  , 0x00 }, // 0x3B04 "16" exposure
  { STROBE_FREX_EXP_L   , 0x10 }, // 0x3B05 "16" exposure
  { STROBE_FREX_CTRL0   , 0x0F }, // 0x3B06
};
struct sensor_regs ov5647_emit_frex_i2c[] = {
  { STROBE_FREX_EXP_REQ , 0x01 }, // 0x3B08
};

Next step is to try with this raspiraw option for "16" exposure FREX ...

Code: Select all

--regs "3002,f8;3b04,00100f09"

... and trigger capturing a frame with:

Code: Select all

"i2cwrite36 /dev/i2c-0 3b08 01" (and probably "i2cwrite36 /dev/i2c-0 3b08 00" afterwards)
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sun Mar 03, 2019 9:41 am

Something is wrong after setting up the v1 camera environment I created 640x128_s_expus tool like I did before with 640x150_s_expus tool. But this time passing "25" for 25µs exposure time did not work. This is 640x128_s animated .gif playing 665fps video at 2fps, lit by "only" 1000lm, 7 frames show the bar closing phase (10 for 1007fps video). The bar is by far too blurry for 25µs exposure (worked for v2 camera):
Image


Will have to investigate that later, now FREX experiments first.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sun Mar 03, 2019 4:43 pm

Setting the registers as described does not work.

So I looked for a mode that allows for the least fps among all, and tried mode 3. During 10s of recording only 2 frames get captured, the 10s should give enough time to play with i2cwrite36 and trying to trigger an additional frame capture.

I have no idea why "-e 1" setting exposure to line_time_n2 =183,789ns does not show a darker image.
Scene is lit by 30cm distant 1000lm unfocused light only and should not show that bright with 0.184ms exposure time:
Image


5MP frame was taken with "./2592x1944_frex_i2c 10000" command at 0.2fps

Code: Select all

...
fps=0.2
echo "capturing frames for ${1}ms with ${fps}fps requested"
raspiraw -md 3 -t $1 -ts tstamps.csv -hd0 hd0.32k --height 1944 --top 0 --fps $fps -e 1 -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/shm/err #/dev/null >/dev/null
...

P.S:
Now with mode 2 "-e 1" should be line_time_ns exposure time which is 32503ns or only 32.5µs, no idea why this frame is so bright, maybe a bug in exposure setting of raspiraw for v1 camera (setting exposure to very low values as "-e 1" works fine for v2 camera, frames look really dark when not lit by 5000lm or more focussed light):
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Sun Mar 03, 2019 7:07 pm

I changed camera back to v2, "--expus 1000" and "--expus 2000" generate differently bright frames after processing with dcraw.

Then changed back to v1 camera. Here both frames are identical, "--expus" does not work for ov5647, created new issue on that:
https://github.com/6by9/raspiraw/issues/25

P.S:
I just closed the issue as duplicate because there is a yet unmerged pull request with fix.
Details on why "-e" worked for imx219 and not for ov5647, as well as some new ov5647 frames with fix here:
https://github.com/6by9/raspiraw/issues ... -469225638
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Mon Mar 11, 2019 6:18 pm

I was stuck in getting FREX mode working.
Therefore I ordered an Arducam ov5647 camera with STROBE and FREX pin exposed.
With detailed information from Arducam support I was able to trigger several FREX mode frames yesterday:
viewtopic.php?f=43&t=235523#p1440270

Now I used the script "frex_i2c" and C program "frex_i2c_trig.c" and tried to really capture the frames and have a look at them. Instead "raspivid" I switched to use "raspiraw" for the capturing part, and "frex_i2c" for the triggering part. "raspiraw" has an advantage over "raspivid" other than allowing much higher framerates, it allows also capture much smaller framerates! With mode 7 640x480 the minimal framerate that works for "raspivid" is 60fps. Very low framerate for the automatically captured frames from "raspiraw" is not possible with mode 7 and "raspivid". But with raspiraw that is no problem. I created new "640x120" tool from "640x480" tool:

Code: Select all

[email protected]:~ $ diff raspiraw/tools/640x480 640x120 
10c10
< raspiraw -md 7 -t $1 -ts tstamps.csv -hd0 hd0.32k --height 480 --top 0 --vinc 17 --fps $fps -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null >/dev/null
---
> raspiraw -md 7 -t $1 -ts tstamps.csv -hd0 hd0.32k --height 120 --top 0 --vinc 17 --fps $fps -sr 1 -o /dev/shm/out.%04d.raw 2>/dev/null >/dev/null
19c19
< D=`echo "0123456789" | sed "s/\`echo $((1000000/$fps)) | cut -b1\`//"`
---
> D="012346789"
[email protected]:~ $ 

This was needed to get good above potentially 200fps because "frex_i2c_trig.c" sends 4 frame capturing requests slightly more that 4ms apart ("640x120" allows for 360fps). Then I called "640x120" with 1.8519fps requested. Why? That requested framerate results in 500006µs time between frames or nearly 2fps. Doing so generates only very few "raspiraw" frames, allowing to send the "frex_i2x" FREX frames in between. "640x120" gets started in the background after logic analyzer capturing of FREX/STROBE/VSYNC lines has been started. Then "frex_i2c" gets executed. As you can see 18 frames got captured, while "640x120" alone would have captured only 9 frames:

Code: Select all

[email protected]:~ $ ./640x120 5000 1.8519 &
[3] 17646
[email protected]:~ $ removing /dev/shm/out.*.raw
capturing frames for 5000ms with 1.8519fps requested
./frex_i2c
[email protected]:~ $ 18 frames were captured at 1fps
frame delta time[us] distribution
      1 
      1 4352
      1 4355
      1 4423
      1 17400
      1 17457
      1 18548
      1 136322
      1 235012
      1 432878
      3 500005
      5 500006
after skip frame indices (middle column)
> 432878,4,163496178678
> 136322,5,163496315000
> 235012,6,163496550012
> 18548,7,163496568560
> 17400,8,163496585960
> 17457,9,163496603417
> 4423,10,163496607840
> 4352,11,163496612192
> 4355,12,163496616547
33% frame skips

[3]+  Done                    ./640x120 5000 1.8519
[email protected]:~ $

From the logic analyzer capture I exported the data, and grepped for the lines where STROBE (middle column) gets high (that happens exactly after ov5647 global reset happend as response to frex_i2c request). Find complete logic analyzer export attached:

Code: Select all

$ grep ", 1, 1, 1" frex_i2c.1.csv 
3.465324625000000, 1, 1, 1
3.601645912500000, 1, 1, 1
3.836655887500000, 1, 1, 1
3.855203450000000, 1, 1, 1
3.872603762500000, 1, 1, 1
3.890060700000000, 1, 1, 1
3.894483550000000, 1, 1, 1
3.898835775000000, 1, 1, 1
3.903190450000000, 1, 1, 1
$ 

Then I did put the 1st column (seconds) into LibreOffice Calc and determined the rounded value of consecutive diffs after being multiplied by 1 million to get µs numbers:

Code: Select all

136321
235010
18548
17400
17457
4423
4352
4355

If you compare these numbers to those reported from "640x120" output you will notice that they are identical (up to 2µs for the first two numbers):

Code: Select all

after skip frame indices (middle column)
> 432878,4,163496178678
> 136322,5,163496315000
> 235012,6,163496550012
> 18548,7,163496568560
> 17400,8,163496585960
> 17457,9,163496603417
> 4423,10,163496607840
> 4352,11,163496612192
> 4355,12,163496616547
33% frame skips

Ok, this was done with Arducam ov5647 camera in order to get the STROBE captures for the FREX frames. I tried the same procedure with a normal 4$ Raspberry v1 clone camera.

A v1 camera clone running 640x128_s tool requests 659fps and gets 665fps. I noticed that maybe the I2C bus on Arducam camera was more efficient, since with that camera the same tool requesting 659fpscaptures 718fps.

Since v1 camera clone is a bit slower, the delays for fast frex_i2c_trig.c needed to be increased to work. 4774µs translates to 209fps only, but with global reset!

Code: Select all

[email protected]:~ $ diff frex_i2c frex_i2c2
13c13
< ./frex_i2c_trig
---
> ./frex_i2c_trig2
[email protected]:~ $ 
[email protected]:~ $ diff frex_i2c_trig.c frex_i2c_trig2.c 
11c11
< #define D 3000
---
> #define D 3400
[email protected]:~ $ 

Again executing 640x120 in background (without logic analyzer since v1 clone does not expose FREX/STROBE pins), and then modified "frex_i2c2". You can see the slightly longer short distant FREX frames again:

Code: Select all

[email protected]:~ $ ./640x120 5000 1.8519 &
[3] 19025
[email protected]:~ $ removing /dev/shm/out.*.raw
capturing frames for 5000ms with 1.8519fps requested
./frex_i2c2
[email protected]:~ $ 17 frames were captured at 1fps
frame delta time[us] distribution
      1 
      1 4754
      1 4755
      1 4774
      1 17178
      1 17311
      1 17348
      1 136269
      1 234955
      1 315196
      4 540006
      3 540007
after skip frame indices (middle column)
> 315196,5,168464678529
> 136269,6,168464814798
> 234955,7,168465049753
> 17311,8,168465067064
> 17348,9,168465084412
> 17178,10,168465101590
> 4774,11,168465106364
> 4754,12,168465111118
> 4755,13,168465115873
34% frame skips

[3]+  Done                    ./640x120 5000 1.8519
[email protected]:~ $ 

Until now all is just numbers, how about a real frame? I did convert frame 12, the middle of the 3 frames with 4.7ms frame delta:

Code: Select all

[email protected]:~ $ grep ",1[0-4]," tstamps.csv 
17178,10,168465101590
4774,11,168465106364
4754,12,168465111118
4755,13,168465115873
540006,14,168465655879
[email protected]:~ $ 
[email protected]:~ $ raw2ogg2anim f 12 12 1 
And here you can see it (scene was lit by a 1000lm only unfocused lamp), FREX frame capturing really works!
Image


4774µs translates to 209fps. For a closing mouse trap bar that closes in 10ms that means we will get two frames of mouse trap bar in motion. I don't know how to control where these two will be, but the 2nd will definitely be right of mouse trap middle! And the to be captured frames will show vertical closing mouse trap bar different to this frame because "global reset AND very short shutter time == global shutter":
Image


Next very fun observation with FREX mode capturing is that the exposure time is completely controlled by 24bit value in 0x3b0[145] registers. It is exciting because the time base is different to normal rolling shutter capture mode. There the minimal exposure time is line_time_ns which is 21.165µs. With frex mode this is different. From the information I got from Arducam support:
The example value 00|04|00 written to 0x3b0[145] is 1024 and corresponds to 1.37ms.
Therefor minimal exposure value configurable is crazy low 1.37ms/1024 = 1.338µs(!!) under the assumption of 92MHz pixel clock.

Even in 640x480 mode 7 the pixel clock is 46.5MHz, and the unit of FREX exposure is 1 ×128tp/bit or 128/46.5 = 2.753µs(!):
https://cdn.sparkfun.com/datasheets/Dev ... df#page=21


It seems that no air-gap flash is needed to capture a 375m/s flying bullet because it will fly 2.753*0.375mm = 1.032375mm only(!!) during frame exposure time.
Attachments
frex_i2c.1.zip
contains frex_i2c.1.csv
(476 Bytes) Downloaded 33 times
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Thu Mar 21, 2019 1:50 am

I had to debug a hardware issue in trying to do a sub-3µs total exposure global reset frame capture of a fast rotating mini drone propeller. But I can only work on that when back home on Friday when having access to the 5000lm led and the other stuff.

I do have the Arducam ov5647 and a logic analyzer with me though and investigated what can be done with a normal Raspberry v1 (clone) camera that does not expose ov5647 FREX and STROBE pins needed for sub-3µs flash exposure.

Today I used logic analyzer to capture Arducam FREX pin (channel 0), STROBE pin (channel 1) and GPIO17 (channel 2).

Since only the camera sync pulse will be available for "normal" v1 camera I determined the exact times from FREX rising edge until STROBE rising edge of each frame. I exported the captured data and determined the minimal and maximal values for these times. The maximal and minimal value were just 30ns apart. I repeated that experiment three times to be sure it will be always 30ns apart, and it was.

So knowing when FREX edge rises means one knows when STROBE edge rises based on FREX mode register settings:
https://stamm-wilbrandt.de/en/forum/FRE ... mings.html

With frex_i2c the code signals to ov5647 that FREX mode should be entered. This time I used a tricky piece of C code with wiringPi library, compiled with -O6 to see GPIO17 falling edge just after the I2C command was sent using "write()". Even the assertion of the length compare is done later. It turned out that digitalWrite() is faster writing LOW than HIGH, that is reason for falling edge signalling. The script "frex_i2ccs2" as well as C program "frex_i2c_trig2.c" are attached. Here is the relevant C code part:

Code: Select all

        char buf0[3];        buf0[0]=0x3b;        buf0[1]=0x08;        buf0[2]=0x00;
        char buf1[3];        buf1[0]=0x3b;        buf1[1]=0x08;        buf1[2]=0x01;

 for(;;)
{
        assert(3==write(i2c_fd, buf0, 3));
        digitalWrite (17, HIGH) ;
        l = write(i2c_fd, buf1, 3);
        digitalWrite (17,  LOW) ;
        assert(l==3);
        usleep(D);
}

The first write() seems useless because the register will have value 0 already by ov5647. But only doing it exactly this way the time difference between "virtual FREX" falling edge on GPIO17 and FREX pin rising edge keeps in the low two digit microsecond range.

I did the experiment three times, started logic analyzer, started "raspivid -md 1 -fps 1.2 -t 10000 -pts tst.pts -o tst.h264&" in background and the started frex_i2ccs2 script. When raspivid completes after 10s, frex_i2c_trig2 will assert and stop. Then I did stop the logic analyzer and exported then captured data.


Then I imported the data into libre office calc with "soffice --calc untitled.csv". Then I did add a new formula that checks GPIO17 being 1 (that is GPIO17 risinging edge), and taking the difference of interest in that case (between the next two timestamps). Otherwise the empty string is taken. Then I did copy that formula down in area of interest. Finally used MIN() and MAX() functions for that range to determine their difference as bottom number:
Image


In this case the difference is 13637.5ns. I repeated this experiment two times and saw these durations min/max/diff triples:

Code: Select all

0.0014531125
0.001464175
0.0000110625

0.001448700000001
0.001464524999999
0.0000158250

0.001450912500001
0.00146455
0.0000136375
So the delta between GPIO17 falling edge and FREX rising edge is just above 11µs/15µs/13µs. As you can see the absolute delta times are in same range as well. GPIO17 falling edge is at T0 or only some microseconds later (FREX mode is entered after frex_i2c I2C command is completed):
https://stamm-wilbrandt.de/en/forum/FRE ... PIO17.html
Image


After having successfully captured a sub-3µs flash global reset frame that will be a "global shutter" frame (because its dark while the lines get read and no further integration happens) with Arducam ov5647 camera, I will try to make use of above described "virtual FREX" pin GPIO17 and try to do "global shutter" frames with normal v1 (clone) camera without exposed FREX/STROBE pins as well. I will report the outcome here then.


P.S:
I have two ESP32-camera modules at home and learned yesterday how easy it is to install Arduino CamWebServer example sketch:
https://twitter.com/witnessmenow/status ... 9929532416

I just mention this here because the image sensor ov2640 (predecessor of ov5647) has FRame EXposure mode as well(!):
https://www.uctronics.com/download/cam_ ... pdf#page=4
Attachments
virtual.FREX.zip
contains script and C code
(855 Bytes) Downloaded 24 times
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Thu Mar 21, 2019 9:11 pm

It turned out to be even better to do the falling GPIO17 edge just before the last buf1 write:

Code: Select all

$ diff -C 1 frex_i2c_trig2.c frex_i2c_trig3.c 
*** frex_i2c_trig2.c	2019-03-21 01:59:33.241893318 +0100
--- frex_i2c_trig3.c	2019-03-21 21:17:31.087480197 +0100
***************
*** 44,47 ****
          digitalWrite (17, HIGH) ;
-         l = write(i2c_fd, buf1, 3);
          digitalWrite (17,  LOW) ;
          assert(l==3);
--- 44,47 ----
          digitalWrite (17, HIGH) ;
          digitalWrite (17,  LOW) ;
+         l = write(i2c_fd, buf1, 3);
          assert(l==3);
$

I did the whole steps (logic analyzer capture, raspivid in background, new script with new C program, exporting data) 10 times.
I wrote small analyze.c for not needing to do manual steps, this is output:

Code: Select all

$ for f in untitled.??.csv; do ./analyze $f; done
0.002102030,0.002106610,0.000004580
0.002102530,0.002107450,0.000004920
0.002102730,0.002107160,0.000004430
0.002101875,0.002107575,0.000005700
0.002101700,0.002107950,0.000006250
0.002102788,0.002107525,0.000004737
0.002101812,0.002107437,0.000005625
0.002102075,0.002108863,0.000006788
0.002102725,0.002106450,0.000003725
0.002102738,0.002108125,0.000005387
$ 


The 3-tuples are minimal,maximal value and their difference for each file. The overall maximum in 3rd column (maximal difference between min and max) is 0.000006788, but that value is not that important. The overall minimum is 0.002101700, the overall maximum is 0.002108863, and their difference is only slightly more than 7µs (0.000007163). So taking the maximal value determined added to falling GPIO17 edge is only a 1-digit microsecond value after T1, the rising FREX edge.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

perrociego
Posts: 14
Joined: Fri Jan 06, 2017 4:21 am

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Fri Mar 22, 2019 1:01 am

A bit of sand:

Most active sensor CMOS use 3 transistor per pixel. For an electronic GLOBAL SHUTTER 4 to 5 transistor per pixel are required. If a remember right the problem, the difficult part, is not all the pixels beginning the exposure at the same time (the reset) but ending the exposure and avoiding any pixel to add more light at the same time.

I know only two cameras with an electronic global shutter: the Blackmagic Design Cinema Camera and the Sony PMW-F55. These are expensive equipment (roughly $3000 and $30000 at launch time). Because of that I think that an electronic global shutter is not available on the Raspberry sensors.

Marcelo

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Fri Mar 22, 2019 6:52 am

perrociego wrote:
Fri Mar 22, 2019 1:01 am
... the difficult part, is not all the pixels beginning the exposure at the same time (the reset) but ending the exposure and avoiding any pixel to add more light at the same time. ...
Thanks, and you are right for non-dark scenes.

But I solved the problem for dark scenes already, will just need to fix hardware issue after complete wiring of all components on the weekend.

For a dark scene (and I have that under control) I will light the scene with a 5000lm led say for 40µs (I read that is needed to get the led fully lit). Most importantly I have already proven that I can power off and get darkness again in 2.4µs after begin of exposure for 20$ Arducam ov5647 camera in the other thread:
viewtopic.php?f=43&t=235523&p=1444846#p1442871
Image


So the scene will be dark and only lit for 2.4µs plus 10ns STROBE pin falling edge detection delay plus 12.5ns minimal strobe pulse length = 2.4225µs. It does not matter that reading the 2MP frame takes a lot of time (many milliseconds) as there is no more light that can be added to the sensors during that long time. Hopefully I can fix the cabling error quickly on weekend and get first sharp global shutter frames of 32500rpm mini drone rotor (at 57.8m/s the rotor will move only 0.14mm during the 2.4225µs exposure time with light):
Image


The problem I tried to overcome with my recent postings in this thread is that v1 camera does not expose the FREX and STROBE pins like the Arducam ov5647 camera, which are currently needed for described solution.


P.S:
There is a trivial global shutter photo that can be taken with v1 camera, not needing anything but the global reset.
I will have dark scene unlike shown below and capture "-t 2000" raspistill image. During that 2s I will trigger a single 1000KV Tesla coil spark (sparks light in sub µs range). Will be interesting whether the v1 camera global.reset frame will look different to the v2 photo below:
viewtopic.php?f=43&t=207537
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Thu Mar 28, 2019 6:41 am

HermannSW wrote:
Thu Mar 21, 2019 9:11 pm
.... The overall minimum is 0.002101700, the overall maximum is 0.002108863, and their difference is only slightly more than 7µs (0.000007163). So taking the maximal value determined added to falling GPIO17 edge is only a 1-digit microsecond value after T1, the rising FREX edge.
This became more important after I did first successful global shutter capture with Arducam ov5647 camera:
viewtopic.php?f=43&t=235523&p=1448036#p1447743

In that setup I configured shutter delay as 0800, that is 2048*128/96=2730µs. Now adding the maximum of 0.002108863s gives 4.839ms. A simple circuit is needed that generates a pulse of length 4.839ms, or a similar other value as the shutter delay can be configured.

For this a 555 time monostable circuit can be taken, I have several at home. From DueVGA project (let Arduino Due output to VGA monitor) I do have a 390Ω resistor, together with a 10µF capacitor a pulse length of 4.29ms can be achieved, see this calculator:
https://www.allaboutcircuits.com/tools/ ... e-circuit/

The 7µs difference I talked about would mean that in first global shutter scenario the frames would get exposure times in the range 29.34µs..36.34µs, which will give good v1 camera global shutter frames with enhanced lighting (adding reflector that was missing in 1st capturing).


This is propeller rotating at 5100rpm or 85 times a second from first global shutter capture in the other thread:
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Mon Apr 01, 2019 6:46 pm

After successful 2MP global shutter videos with Arducam ov5647 camera, I have bought ingredients for allowing a big range of pulse lengths for the monostable circuit:
  • 1/10/100 pF/nF/µF and 1000µF capacitors
  • 20Ω/30Ω/40Ω/50Ω/60Ω/70Ω/80Ω/90Ω/100Ω resistors

Pulse length of mono stable circuit is 1.1×R×C seconds, the bought capacitors and resistors allow for pulse lengths from 22 pico seconds to 0.11 seconds. The first monostable 555 circuit I did build had incorrect connections and I burned a 555 by that (I have 9 others). The second circuit I checked the cabling several times does not work either and started to smell when powered. I need to get this straight. In order to not risk one of my PIs I will use Arduino Uno, because minimal voltage for 555 timer chip is 4.5V and Uno has 5V logic.

It should not be that difficult to get this right, and when I have it, I can trigger a pulse of the length needed as described in previous posting on falling edge just before sending the frex_i2c command to v1 camera this time, and get first global shutter videos with "normal" v1 camera (clone) that miss FREX and STROBE pins the Arducam ov5647 camera provides:
https://en.wikipedia.org/wiki/555_timer_IC#Monostable
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Tue Apr 02, 2019 5:47 pm

I manged to setup the logic circuit as shown, but measured strange data.

These are minimal, maximal and their difference for C=1000µF and R=100Ω. This does not match the t=1.1*R*C, is nearly 10 times less the 0.11s:

Code: Select all

0.017187963
0.018180375
0.000992412
Similar for C=100µF and R=100Ω :

Code: Select all

0.001310350
0.001439400
0.000129050
And for C=10µF and R=100Ω:

Code: Select all

0.000140925
0.000144162
0.000003237
These three scenarios are not recreatable. I use an Arduino Uno to signal high, then every second go low and immediately high again for falling edge triggering the pulse. If I power off the Uno, and then power it on again, and do another 1 minute logic analyzer capture to get 60 pulses, I get measurements in the same order, but totally different (for 1000µF I have seen values around 0.015s as well as around 0.013s).


Values for C=1µF and R=100Ω are sufficiently stable, even powering Uno off and on keeps the measured pulse lengths. But changing resistor to 50Ω keeps the same pulse duration?!?

Code: Select all

0.000010100
0.000010113
0.000000013

0.000010100
0.000010138
0.000000038
So I increased resistor by factor of 10 and pulse lengths did increase by factor less than 4 (C1µF, R=1KΩ)?!?

Code: Select all

0.000036675
0.000036763
0.000000088

0.000036537
0.000036563
0.000000025
It looks like these RC 555 timer circuit is just not precise enough for microsecond precision delay generation ...


P.S:
I must have done something wrong, I use NE555P which is a precision timer, and the datasheet timing diagrams look pretty nice ...
https://datasheet.octopart.com/NE555P-T ... df#page=11
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Tue Apr 02, 2019 7:33 pm

The mini breadboard I used had problems, after moving the complete circuit onto a real breadboard the measured values make sense.

This is logic analyzer for R=4.67KΩ and C=10nF:
Image

1.1×R×C = 0.00005137s = 51.37µs, sufficiently close to the measured 53.1µs for me.
I did run 1 minute test generating 60 pulses and determined minimum, maximum and the difference again:

Code: Select all

0.000052970
0.000053020
0.000000050
The 53.1µs shown before are outside this min-max range, but all in all the pulse length seems to be precise and recreatable.
I just power cycled the Uno and for the 60 pulses measured then I got the exact same minimum and maximum.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Wed Apr 03, 2019 7:00 pm

In order to have less of cable clutter and more recoverability for generation of precision pulses of a length 1.1×R×C seconds I did solder a small logic circuit, with female headers for easily switching R and C for different pulse lengths, and with 2 male headers for GND/TRIG/OUT/VCC (the constant 10nF capacitor is hidden between IC and circuit board):
Image


This is the corrected layout, flipped vertically for soldering -- corrected means I did solder as shown in the wrong layout before, and then had to fix the layout as well as to fix the soldering:
Image


I did a 1 minute run with 60 pulses as yesterday, with minimum/maximum being 52.990µs/53.080µs and their difference being 90ns only.


So now that I have logic circuit to generate precise pulses of a specified length, I can try to record global shutter videos with "normal" Raspberry v1 camera (clone). The role that FREX and STROBE pin played in the Arducam ov5647 thread will be taken over by this tiny logic circuit.


What I can measure with logic analyzer for Arducam ov5647 camera is T1 and T3+"strobe pulse length". It would be better if I could measure T4 instead to get the timings right for normal v1 camera. Next step is to switch to "strobe mode 2" where strobe is on for the whole configured exposure time:
https://stamm-wilbrandt.de/en/forum/FRE ... mings.html
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

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

Re: utilizing frex and strobe pads for ov5647 (probable solution for rolling shutter issue?)

Tue Apr 09, 2019 8:00 pm

Off topic a bit.

A colleague saw that I do solder IC logic circuits, the one from previous posting and the one from other thread:
Image


He gifted me his 34yo diploma thesis ISDN ISA card for IBM PC to make use of the many 74xxx ICs in IC sockets. He did that card after ISDN spec was available, but before you could buy any such card:
Image


I started with this table and copied together the ICs I found in top two rows of ICs on the card:
https://en.wikipedia.org/wiki/List_of_7 ... footprints

This is what I found, many useful ICs, and though 34 years old they should work as if they are new:
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

Return to “Camera board”