ArduCam OV5647 Camera Board w/ M12 Mount

[HermannSW]

I was a little bit stuck in making v1 camera capture in "global reset" mode, although ov5647 spec did say it is possible:
viewtopic.php?f=43&t=218576&p=1436391#p1436982

From other postings here it was clear that Raspberry v1 camera board (or China clones) do not expose ov5647 FREX and STROBE pins. After some searching I found that one of the many Arducam cameras is an ov5647 with FREX and STROBE exposed, and I ordered and received it.

Even the Arducam product description is a bit outdated (it mentions FREX, STROBE, GND and 3.3V pins only):
http://www.arducam.com/raspberry-pi-cam ... rformance/

Same for the product page where I bought my module (19$):
https://www.robotshop.com/en/arducam-ov ... ry-pi.html

Why outdated? The module I received has VSYNC exposed as well:



In the afternoon I did experiments again to "see something" on logic analyzer without success:
https://twitter.com/HermannSW/status/11 ... 7884691456

I do work as Compiler Level3 support for DataPower Gateways at my day job at IBM. We do have weekend coverage (I currently have), but customer issues need to be sev1 prod down to be handled on weekend and not on Monday.
I only mention this because short after the tweet I got Arducam support response on my request for infromation wrt FREX/STROBE and their camera module. I was really impressed, by the fact to get this on Sunday afternoon as well on the detailed technical information they provided.


My first successful logic analyzer capture of all three exposed ov5647 pins is from after a long walk with dog. Channel 0/1/2 were connected to FREX/STROBE/VSYNC:
https://twitter.com/HermannSW/status/11 ... 8853915649



This this the bash script I extended (based on i2cwrite36 tool from the other thread):

Code: Select all

$ cat frex_i2c
#!/bin/bash
./i2cwrite36 /dev/i2c-0 3002 ff
./i2cwrite36 /dev/i2c-0 3b01 00 08 00 04 00 14 1d

./i2cwrite36 /dev/i2c-0 3b08 01 
sleep 0.1
./i2cwrite36 /dev/i2c-0 3b08 01 
sleep 0.2
./i2cwrite36 /dev/i2c-0 3b08 01 
./i2cwrite36 /dev/i2c-0 3b08 01 
./i2cwrite36 /dev/i2c-0 3b08 01 
./frex_i2c_trig
$

The initial two lines bring ov5647 into FREX mode, then FREX is triggered via frex_i2c mode by setting bit0 or 0x3b08 register. The last line generates 4 very short apart frex_i2c signals:

Code: Select all

$ cat frex_i2c_trig.c 
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>

#define I2C_SLAVE_FORCE 0x0706
#define WRITE_I2C(fd, buf, len)  (write(fd, buf, len) != len)

#define D 3000

int main(int argc, char *argv[])
{
    int  i2c_fd = 0;
    char *i2c_device_name;

    i2c_device_name = "/dev/i2c-0";

    i2c_fd = open(i2c_device_name, O_RDWR);
    assert(i2c_fd);
    assert(ioctl(i2c_fd, I2C_SLAVE_FORCE, 0x36) >= 0);

        char buf[3];

        buf[0]=0x3b;
        buf[1]=0x08;

        buf[2]=0x01;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        buf[2]=0x00;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        usleep(D);
        buf[2]=0x01;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        buf[2]=0x00;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        usleep(D);
        buf[2]=0x01;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        buf[2]=0x00;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        usleep(D);
        buf[2]=0x01;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        buf[2]=0x00;
        assert( WRITE_I2C(i2c_fd, buf, sizeof(buf))==0 );
        usleep(D);

    if (i2c_fd) 
        close(i2c_fd);

    return 0;
}
$

This is the complete logic analyzer picture (not sure about VSYNC in bottom channel 2).
First I started "raspivid -md 2 -fps 1 -pts tst.pts -t 8000 -o h.264 &" in background.
Then I started logic analyzer capture.
Then I executed "./frex_i2c".
After that completed I stopped I2C capture.



I really tried to minimize the time between consecutive frex_i2c triggers (the only possible on v1 camera), but 3ms usleep delay were needed to see the 4 strobe pulses (4.372ms apart ‒ that limits framerate to 228fps ):



I have to understand how the measured 10.37µs strobe pulse length corresponds to the register values written with i2cwrite36 command:



Summary sofar:

• above register settings allow to bring ov5647 into frex mode
• as shown frex_i2c works (allows v1 camera to do "global reset" captures)
• as described in other thread this means "global shutter" for exposure time of (line_time_ns =) 21.165µs!
  (5000lm focussed light will produce well lighted frames)
• The ov5647 Arducam exposed STROBE pin seems to be what people asked for long in "Hardware camera sync pulses" thread:
  viewtopic.php?f=43&t=190314
• a lot more to investigate ...

[HermannSW]

This posting shows that capturing global reset frames in FREX mode really works with raspiraw:
(with Arducam ov5647 camera as well as with Raspberry v1 camera clone)
viewtopic.php?f=43&t=218576&p=1440654#p1440654



It also shows that ov5647 minimal exposure time is much less than 21.165µs in FREX mode!
1.338µs at 92MHz pixel clock, or 2.753µs in 640xH mode 7 with 46.5MHz pixel clock!

This posting gives a preview on how a flying 9x19 Parabellum bullet will look like with 2.753µs exposure time:
viewtopic.php?f=43&t=234416&p=1440815#p1440815


Next work will happen in thread pointed to first (capturing "global reset AND very short shutter time == global shutter" video of closing mouse trap and hopefully seeing vertical closing mouse trap bar because of missing rolling shutter effect).

Next step in this thread will be triggereing frex mode via FREX pin of Arducam ov5647 camera board (impossible with v1 camera clone) and seeing whether minimal time between successive captured FREX mode frames can be reduced compared to frex_i2c triggering as described here with maximal framerate just above 200fps.

[6by9]

(capturing "global reset AND very short shutter time == global shutter"

No it doesn't.
Global reset and short readout time ~= global shutter.
In some ways global reset and very long exposure time is closer to global shutter, as the variance in exposure due to the readout time is significantly smaller than the configured exposure time.

You trigger a global reset and ALL lines start exposing.
At the end of the exposure time line 1 starts reading out. Lines 2-N keep exposing.
At exposure time + 1 line readout time, line 2 starts reading out. Lines 3-N keep exposing.
At exposure time + N * readout time line N has stopped exposing and completed readout.

If using a mode based on mode 7, then a full line takes 31us to read out. For the full 480 lines of readout you've therefore got 14ms of variation in exposure between first and last lines. Even down at 50 lines you've got 1.5ms of variation.

[HermannSW]

I got you.

So there are still next steps.

First is to see what is the best result for rolling shutter capturing of RC airplane propeller with 180fps/1007fps framerates and v2 camera:
viewtopic.php?t=190407#p1319617

The videos were taken at a time where I thought shutter times of 200µs are really short, but I learned that shutter time of 1×line_time_ns or 19.5µs work well with v2 camera, so both videos will be redone with "-ss 20" instead of "-ss 200".


Next I will do global reset capture with raspistill to see what we get with RC airplane propeller. By what you explained it will be uglier than the rolling shutter frames because it will show much more blur for lower lines of frame, and exposure will be different for each line recorded.


Then a shutter is needed, and it seems I will have to build my own shutters (I have searched on google, amazon, aliexpress but did not find add on shutters).


The easier will be a one-time shutter (light off), but for correct timing FREX signal is needed.
Since FREX pin is exposed on Arducam ov5647 only, it will only work with that camera, and is described below.

The continuous shutter will be described in utilizing frex and strobe pads for ov5647 thread. I have an initial idea, but it will definitely be more difficult than the one-time FREX pin shutter.


One-time FREX pin shutter:

At some time T0 the frex_i2c command is complete.
A little later at T1 FREX pin output will be set high as I showed on the logic analyzer images.
It is assumed that at time T4 the external shutter is closed.
T4-T1 is T_delay and configured in registers 0x3b0[23].
T3 is T4-T_exposure configured in registers 0x3b0[145].
T2 is T3-T_reset configured in register 0x3b0a.

Now that we have defined the times, this is what happens:
At T1 FREX pin goes high.
At T2 global reset gets started.
At T3 global reset ends, and exposure starts for all lines.
Also at T3 STROBE pin goes high.

This is all that is needed to know for one-time shutter.

The 5000lm led will be powered by a motor controller.
The TB6612FNG I used has peak 3.2A which is fine for 1.5A LED driver, but Vmax is 15V only.
I will need to find a motor controller that can handle 38V and 1.5A peak, because the LED will be on only for very short time.

Then a 555 timer chip will be used to cut power after T_delay(=T4-T1).
I do have several of these timer chips, but not used yet. Will have to learn.
What I know is that they allow for very precise timing.

This will take time, but if it works it allows for very cheap global shutter one-shot solution:

• 5$ Pi Zero
• 20$ Arducam ov5647 camera
• 10$ 5000lm led with 1.5A/38V LED driver
• few $ for motor driver and 555 timer chip

P.S:
Mosfets are better for this, and I have some IRF520 at home. They can do 24V/5A, so using two in series will do.
I did order a 36V/5A mosfet locally that will arrive on Saturday,
And I did order three 1.11$ 36V/22A mosfets on aliexpress (impressive is that heatsink is only needed for >5A).

[HermannSW]

No other continuous shutter is needed, since the one-shot shutter described will just work continuously!
Every new frame will trigger FREX pin high, that will turn on 5000lm led for T_delay time and the turn it off.
This will be repeated for every frame, the logic will just have to act on rising FREX pin.

With v1 camera raspiraw tool 640x128_s captured (rolling shutter) video at 665fps (it captures 64 "every other" lines).
Reading a single 640xH line takes 31µs, so reading out 64 takes 31×64=1.984ms, allowing for 504fps.
I could live with reduction from 665fps to 500fps for global shutter capturing of 640x128 frames ...

The global shutter camera modules I have read about sofar have framerate 120fps or less.

[HermannSW]

After having looked into 555 timer programming I did not like it.

So I thought on using 84Mhz Arduino Due actively polling FREX pin on rising edge, then powering 5000lm led and doing microsecond range delay and finally power off the LED. Reading an Arduino Due port can be done in 3 clock cycles or 3/84,000,000=35.7ns(!). I used that to build a 14Msps/8CH logic analyzer with that (biggest restriction was only 96KB main memory):
https://forum.arduino.cc/index.php?topic=422173.0


But then I thought that a micro controller for doing the delay was overkill and a pure logic gate solution would be good.
The 5000lm led needs to get powered on rising FREX pin, and it should power off at T4.
Since I did not make use of the available STROBE pin sofar I thought on setting T_strobe = T_exposure and use STROBE falling edge on T4!

Then I had to learn how to detect rising and falling edges, and it turned out to be easy:
https://www.allaboutcircuits.com/textbo ... lip-flops/

Adding an RS flip-flop to hold state between rising FREX and falling STROBE edges was all that was needed.
I found an online logic simulator that allowed me to create the circuit as well as get a "share" link for you to open and edit:
https://simulator.io/board/NM1OhH09Ge/2


I just found one SN74HC00N quad 2-input NAND and two SN74HC02N quad 2-input NOR ICs and will start building the circuit.


Then I looked at frex_i2c script described before and saw that STROBE delay configured in registers 0x3B0[bc] is 00 3d.
On logic analyzer I saw that strobe width was slightly above 10µs(!).
Since there is no need for T_strobe falling edge to be on T4, I tried to set the values to minimal "00 01".
Unbelievable, strobe pule length is 0.24µs only!!!


The logic circuit will take some 10s or 100s of nanoseconds delay, the mosfet perhaps 100ns as well.
All in all it seems to be possible to get the led completely powered off in less than 1µs!
It does not matter how long the led is powered on before global reset since integration starts on T3 which is STROBE rising edge!

[HermannSW]

Done with the cabling of the 3 ICs, and it really works.

GPIO17 simulates the FREX pin, GPIO18 the STROBE pin.
This is the simple code that sets the pin values for shown logic analyzer capture:

Code: Select all

$ for((i=0;i<3; ++i)); do gpio -g write 17 1; gpio -g write 18 1; gpio -g write 18 0; gpio -g write 17 0; echo $i; done
0
1
2
$

Top channel is for FREX, middle channel is for STROBE and bottom channel rises on FREX rising edge and falls on STROBE falling edge:



Does not look that nice, but is working prototype:



I did measure what the rising/falling edge pulse widths are, logic analyzer says 10ns, but that is the resolution of the 100 Msps logic analyzer and probably not accurate. For getting more precise numbers I would need to connect my 400 Msps logic analyzer.

I did export the logic analyzer data, and added comments on rising delay (20-30ns) and falling delay (10ns). Relevant delay sofar: 0.24µs+10ns=0.25µs. Next step is to add mosfet to the circuit and determine total delay then. Finally add laser sensor that detects LED light and measure delay from STROBE falling edge until laser sensor falling edge:

Code: Select all

$ cat untitled.csv 
Time[s], Channel 0, Channel 1, Channel 2
0.000000000000000, 0, 0, 0
1.694371090000000, 1, 0, 0
1.694371120000000, 1, 0, 1  rising 30ns
1.702768980000000, 1, 1, 1
1.711098040000000, 1, 0, 1
1.711098050000000, 1, 0, 0  falling 10ns
1.719537340000000, 0, 0, 0
1.728389000000000, 1, 0, 0
1.728389020000000, 1, 0, 1  rising 20ns
1.736730410000000, 1, 1, 1
1.745049500000000, 1, 0, 1
1.745049510000000, 1, 0, 0  falling 10ns
1.753414100000000, 0, 0, 0
1.762253080000000, 1, 0, 0
1.762253100000000, 1, 0, 1  rising 20ns
1.770696250000000, 1, 1, 1
1.778980010000000, 1, 0, 1
1.778980020000000, 1, 0, 0  falling 10ns
1.787336710000000, 0, 0, 0
$ 

[HermannSW]

I have no idea why I am not able to measure the output voltage of mosfet with logic analyzer.
This time I used Arduino Uno because it has 5V logic, and the laser sensor I wanted to use operates at 5V.

I used Arduino Blink example and triggered the IRF520 mosfet driver. I did use Arduino 5V as input voltage of the mosfet so that I could directly measure Vout that resulted from triggering. Unfortunately when connecting logic analyzer cable to Vout it kept always high. I have no explanation for that, any hint is welcome as I would really like to measure the pure mosfet dealy.

While I was not able to use logic analyzer, I was able to power a 5V laser led from Vout. I taped it directly in front of the laser sensor as can be seen in photo below. The capturing of that scenario (not 5000lm led but laser led, unknown characteristics of laser sensor) produced not the delay values in sub µs range I hoped for,

<old>but falling edge delay is not more than 17µs<old>
Corrected, I got lost in too many digits past comma:
<new>but falling edge delay is not more than 1.7µs<new>
(Channel 0 is D13 from Arduino used for triggering, Channel 1 is digital output of laser sensor):

Code: Select all

Time[s], Channel 0, Channel 1
0.000000000000000, 1, 1
0.574536920000000, 0, 1
0.574538620000000, 0, 0  falling 1.7µs
1.574424100000000, 1, 0
1.574424800000000, 1, 1
2.574313640000000, 0, 1
2.574315320000000, 0, 0  falling 1.68µs
3.574205180000000, 1, 0
3.574205880000000, 1, 1
4.574097480000000, 0, 1
4.574099160000000, 0, 0  falling 1.68µs
5.573985780000000, 1, 0
5.573986500000000, 1, 1
6.573875680000000, 0, 1
6.573877360000000, 0, 0  falling 1.68µs

Now what can be captured nicely with <old>17µs</old> 1.7µs exposure time?
If we restrict object move to 1mm in that tine, anything below 565m/s!

Code: Select all

$ echo "1000000/1.77*0.001" | bc -ql
564.97175141242937853107
$ 

The 375m/s Glock bullet would fly 0.675mm during the 1.7µs ...

[HermannSW]

It was the first time above that I did not look at the details in logic analyzer diagram and calculated wrongly.
The corrected times in previous posting are already cool, but it comes better.
I did the measurement again, in darkness, and now 1.1µs delay between falling signal edge of mosfet and falling laser sensor are measured:



Here are the exported numbers:

Code: Select all

$ cat untitled.2.csv 
Time[s], Channel 0, Channel 1
0.000000000000000, 1, 1
0.924440990000000, 0, 1
0.924442090000000, 0, 0  falling 1.10µs
1.924332620000000, 1, 0
1.924333500000000, 1, 1
2.924225070000000, 0, 1
2.924226170000000, 0, 0  falling 1.10µs
3.924114260000000, 1, 0
3.924115140000000, 1, 1
4.924003650000000, 0, 1
4.924004750000000, 0, 0  falling 1.10µs
$ 

A minor correction needs to be done, the 0.25µs delay from minimal strobe pulse length plus logic circuit delay need to be added., resulting in 1.35µs total delay!

Now what can be captured nicely with 1.35µs exposure time?
If we restrict object move to 1mm in that tine, anything below 740m/s or 2666km/h!

Code: Select all

$ echo "1000000/1.35*0.001" | bc -ql
740.74074074074074074074
$ echo "1000000/1.35*0.001*3.6" | bc -ql
2666.66666666666666666666
$ 

2666km/h is more than mach 2 (double speed of sound) ...

The 375m/s Glock bullet would fly 0.50625mm during the 1.35µs.

These numbers are for laser led, I will now use two 24V mosfets in series to power 5000lm led with 38V/1.5A and measure the delay in that (target) setup.

[HermannSW]

I did the measurement again, this time in darkness and with 5000lm led, and now 2.4µs delay between falling signal edge of mosfet and falling laser sensor are measured:


Here are part of the exported numbers:

Code: Select all

$ cat untitled.3.csv 
Time[s], Channel 0, Channel 1
5.548686670000000, 1, 1
6.548579880000000, 0, 1
6.548582280000000, 0, 0  falling 2.40µs
7.548471490000000, 1, 0
7.548471500000000, 0, 0
7.548471510000000, 1, 0
7.548472370000000, 1, 1
8.548361760000001, 0, 1
8.548364149999999, 0, 0  falling 2.39µs
9.548254710000000, 1, 0
$ 

Again adding 0.25µs delay from minimal strobe pulse length plus logic circuit results in 2.65µs total delay, with 5000lm 38V/1.5A led!

Now what can be captured nicely with 2.65µs exposure time?
If we restrict object move to 1mm in that time, anything below 377m/s or 1358km/h (more than mach 1)!

Code: Select all

$ echo "1000000/2.65*0.001" | bc -ql
377.35849056603773584905
$ echo "1000000/2.65*0.001*3.6" | bc -ql
1358.49056603773584905658
$ 

Now we have reached the exact target speed of 375m/s, Glock bullet would fly less than 1mm during the 2.65µs exposure.

On the photo you can see that I went back to my old Motor Test Station after a friend told me that the outrunner motor with the 25.5cm propeller can be really dangerous with higher rpm.

The 5000lm led at the bottom is connected to output of 2nd IRF520 mosfet, the input of 1st mosfet is done by the 38V/1.5A led driver that can be seen in top middle. The laser sensor is held by the Realacc arm just above Motor Test Station looking down. Its late here and I don't want to mess things up. I will replace the Arduino Uno with Raspberry Pi 3B+ tomorrow and do the triggering of the mosfets with the output signal of the logic circuit described yesterday that gets its two input signals from Arducam ov5647 FREX and STROBE pins.

[HermannSW]

It took me one day to solder the FREX/STROBE/MOSFET logic circuit and debug it, but now I have it:



Later Arducam FREX and STROBE pins will get connected. I did solder a 10pin header with 2 pins for each of GND/FREX/MOSFET/VCC/STROBE. In this test setup Pi3B+ pin1/pin6/pin11/pin12 are connected with VCC/GND/FREX/STROBE. The four logic analyzer cables connect to GND/FREX/STROBE/MOSFET.

I am not good at soldering, which can easily be seen from the bottom side:



I did not use a layout program but just copied the three ICs in intended layout into GIMP and marked blue what I would have to solder (the connections to center headers are not shown). In order to be able to see connections the way I solder I did flip the image vertically and printed it:



It was not that difficult to solder the connections and make sure no unintended connections were created, but it took a long time for me. Finally the circuit did not work, and I had to do long hardware debugging sessions. First I found a missed cable forgotten to be soldered, then two cables connecting the wrong pins. After all that I now have a "working" circuit:



There is one bug left (in software there is always a bug left) in the logic circuit, but I could live with that. The difference to screenshot from logic analyzer with previous breadboard circuit is that after some time after the end of the sent FREX/STROBE signals, MOSFET line (channel2) goes up without a rising FREX edge (0.28s). So the MOSFET line starts high which means that 5000lm led will be powered on before 1st FREX frame captured. But that is OK since only the 2.65µs after STROBE rising edge will be exposed. And after a capture experiment I can just turn off the 38V/1.5A led driver separately.

As expected the soldered circuit has the same 10ns delay for STROBE (channel 1) falling edge compared to MOSFET (channel 2) falling edge:

Code: Select all

Time[s], Channel 0, Channel 1, Channel 2
0.000000000000000, 0, 0, 1
0.918334700000000, 1, 0, 1
0.926938980000000, 1, 1, 1
0.935176040000000, 1, 0, 1
0.935176050000000, 1, 0, 0  falling 10ns
0.943322890000000, 0, 0, 0
0.952262560000000, 1, 0, 0
0.952262580000000, 1, 0, 1
0.960547050000000, 1, 1, 1
0.968585860000000, 1, 0, 1
0.968585870000000, 1, 0, 0  falling 10ns
0.976782560000000, 0, 0, 0
0.985493670000000, 1, 0, 0
0.985493690000000, 1, 0, 1
0.993771860000000, 1, 1, 1
1.001960000000000, 1, 0, 1
1.001960010000000, 1, 0, 0  falling 10ns
1.010033270000000, 0, 0, 0
1.291391360000000, 0, 0, 1

[HermannSW]

I looked again at my statement that 0.24µs is the shortest strobe pulse length above, with setting "00 01" in registers "0x3b0[bc]". That was wrong, in fact registers 0x3b0[bc] are bits [19:4] or strobe length, bits [3:0] are stored in register 0x3b06[3:0]!

Looking at the setting for register 0x3b06 in script freq_i2c there is value 0x14 written to 0x3b06. Therefore strobe length as I configured was 1*16+4=20(!) for 0.24µs. From the information received by Arducam support I read that different to exposure and delay (which have time resolution 128tp/bit) strobe has resolution 1tp/bit.

Looking into ov5647 spec section "2.3 format and frame rate", the 5MP mode 2 uses 80MHz pixel clock:
https://cdn.sparkfun.com/datasheets/Dev ... df#page=21

Now verifying the 0.24µs logic analyzer reading for strobe length 20 is easy, "20/80MHz = 0.25µs", the logic analyzer reported 0.24µs probably because its 100Msps resolution is "10ns = 0.01µs" steps. Most importantly we can reduce strobe pulse length to real minimum now, length 1 corresponds to "1/80MHz = 0.0125µs = 12.5ns" in 5MP mode. I just measured with logic analyzer and STROBE pulse width is shown as 10ns because that is resolution of 100Msps logic analyzer:



A picture says more than 1000 words, I described the FREX mode timings in a previous posting in this thread, but only textually (T0-T4). After I learned how to do diagonal borders this is FREX mode timings diagram relevant for ultra short exposure times, already with corrected T_strobe time:
https://stamm-wilbrandt.de/en/forum/FRE ... mings.html



Now what can be captured nicely with 2.4225µs exposure time?
If we restrict object move to 1mm in that time, anything below 412m/s or 1484km/h (more than mach 1)!

Code: Select all

$ echo "1000000/2.4225*0.001" | bc -ql
412.79669762641898864809
$ echo "1000000/2.4225*0.001*3.6" | bc -ql
1486.06811145510835913312
$ 

[HermannSW]

On Monday night I had everything wired together.
Arducam ov5647 camera's (in motor test station) FREX and STROBE pins should power on 5000lm led on top of reflector on top plexiglas for say 40µs, in order to capture frame with 2.5µs exposure time only, then power the led off, in order to get first 2MP "global shutter" frames of mini drone 34mm diameter propeller rotating with 32500rpm (more than 57m/s or 205km/h on the outside). Unfortunately something did not work and hardware debugging is needed. Will do that when back at home on Friday:



This image from the other related thread
viewtopic.php?f=43&t=234416&p=1444155#p1443728

shows that the 10$ reflector is worth the money as it really concentrates the 5000lm light to a small area of interest:

[HermannSW]

During hardware debugging yesterday it turned out that the problem is somehow related to Raspberry being on 3.3V logic level and my two IRF520 Mosfet module chain not correctlly dealing with that. The module documentation explicitely states that 5V as well as 3.3V logic level are fine (to drive 0-24V, <5A) and I did that even from Raspberry side often successfully in the past:
https://www.aliexpress.com/item/20pcs-l ... 28133.html

Yesterday I just connected the Arduino Uno on 5V logic with Blink example sketch to the two chained IRF520 mosfets with 38V/1.5A led driver and recorded a "really bright" Arduino Blink example. Replacing the Arduino Uno with 3.3V logic Arduino Due and same Blink sketch did not blink:
https://www.youtube.com/watch?v=DnUDftz1q38


Today I tried to follow the KISS way (Keep It Stupid Simple), and after having verified that the 50W 5000lm led slightly glows when it receives 24V only (with less than 0.001A, constant voltage supply reports 0.000A), I did experiments with a single IRF520 mosfet and 24V current today,


As expected the Arduino Uno with 5V logic just works, I took the photo when led was on for 1s:



Next was Arduino Due with 3.3V logic and identical setup and no changes in sketch or wiring.
The led did not blink, and I measured constant 0.2V on Mosfet output (measured 24V on Mosfet input):



Finally I added a logic level converter for 5V signalling on Mosfet signal pin, and powerded Mosfet logic Vcc with 5V.
The led did not blink, and I measured switching between 0V and 1.1V on Mosfet output:



Ooops, I just replace the IRF520 module I just tested with the other used in globel reset setup, and that works with Arduino Due 3.3V logic without logic level converter -- so the module I tested is broken and only works with 5V logic. Now searching wether I have any other IRF520 mosfet that works ...

[HermannSW]

I had five IRF520 mosfet modules, and all but one were broken.

Then I tried to use 400W mosfet I had ordered for this task,
https://www.ebay.de/i/173283172524

and this time I experienced no issues. Blink sketch just works with Arduino Due 3.3V logic and 5000lm led:
https://www.youtube.com/watch?v=nJqreTP ... e=youtu.be



D13 is Arduino Due builtin led pin, and that is a low current pin (can deliver 3mA maximally). I did measure mosfet output voltage as 32.6V, and output current as 1.44A; therefore the 50W 5000lm led gets 46.2W.

Next step is measuring led-laser sensor power down delay (for the two-IRF520 mosfet chain it was 2.4µs) with just 5000lm led as is. Then repeat measurement with 5000lm led focused with reflector, as that is what is relevant.

[HermannSW]

OK, I did the "normal led" led-laser sensor delay test, sensor 30cm away from 5000lm led.
The delay for the 400W mosfet is a bit worse than the 2.4µs measured for the two IRF520 mosfets, it is 2.98µs:


First I did place the led incorrectly directly in front of the 5000lm led, in that scenario the delay was >20µs. So I expect the 5000lm focused with reflector delay to be somewhere between 3µs and 20µs -- to be measured.

What is nice is that the raising edge delay is even less than the falling edge delay, only 2.5µs -- I thought that I have to power on the 5000lm led for 40µs before before powering off. Maybe that is still needed to get full brightness ...

[HermannSW]

While I measured yesterday 2.98µs delay, today in motor test station it was around 11µs, even without reflector. Reason seems to be that the bright wooden bottom plate and the inside white borders of motor test station provide so much reflection potential, that the laser sensor gets far longer enough light to detect. There are counter measures to get delay down again: have a lot of space behind the mini drone instead of sitting on bottom plate, make wall and bottom plate black, ... .

For initial tests "global reset plus 11µs real exposure" will still be "global shutter".

All tests I did today in motor test station were triggered by Raspberry Pi 3B, so no problems left after the hardware debugging of the weekend.


There was some differences in digital speed tachometer determined propeller rpm values and what I can count for low rpm values (<1000rpm) by looking at a Raspberry mode 7 video captured at 90fps. It turned out that I need to use digital tachometer when it is dark, and for that add a small reflective mark. The measurements done this way are reliable and match with what I manually determined by counting 90fps Raspberry videos when single-frame stepping though the video. Finally I determined the maximal speed for 3.7V, and it was 27612rpm, or 49.1m/s or 179.6km/h:

Code: Select all

$ echo "pi=4*a(1); pi*0.034*27612/60" | bc -ql
49.15587193218877684002
$ echo "pi=4*a(1); pi*0.034*27612/60*3.6" | bc -ql
176.96113895587959662407
$ 

For initial testing that is good enough, and also having real exposure of even 11µs is OK. The propeller blades move only 0.5mm in that time.

Code: Select all

$ echo "49.1*0.000011" | bc -ql
.0005401
$ 

These are two consecutive frames from propeller run at 5100rpm. That is a bit smaller than 90*60=5400rpm. Although the propeller rotates counter clockwise, it seems that it turned clockwise a small bit (top frame is first, bottom frame is next). But because of the 5100rpm the propeller does nearly a full round and that can be seen in the frames (the reflective material is on right side blade). Both frames show extreme rolling shutter effects. Scene was lit with a 1000lm unfocused lamp only, and although shutter time was set to 100µs, the frames do not look to dark:

Code: Select all

$ raspivid -md 7 -w 640 -h 480 -p 10,10,640,480 -fps 90 -ss 100 -o tst.7.h264

[HermannSW]

I have taken first "global shutter" video with Arducam ov5647 camera. More details in later postings, this is just to show what I got.

After I soldered a new logic circuit yesterday (just RS flip-flop with R and S bein triggered from rising/falling edge detectors) I tried the whole setup and found that the 400W mosfet was broken (always on, regeardless of signal). Luckily I received yesterday 5 new IRF520 24V mosfets I did order on the weekend after realizing that I only have one working, and used two IRF520 in series to drive the 38V/1.5A 5000lm led. Unfortunately the setup did not work last night, whenever I connected the RS flip-flop Q output with 1st IRF520 mosfet signal pin.

In the morning I thought that perhaps a one-way separation might be needed between Q output and mosfet SIG pin, because Q is in feedback loop with not(Q) for the flip-flop. I will try a diode later, today I just used not(Q) output and added a single inverter to get the right signal for mosfet sig pin (on top black mini breadboard), and it worked:



So what did I get, see again the rolling shutter effect of the propeller in previous posting. Today I did run the propeller again at 5100rpm and took first global shutter video. I used this tuned script, the 0.0288s delay result in 25Hz frequency of generated STROBE signals (measured with logic analyzer). The value "00 c8" in 030[bc] and "_4" in 0306 correspond to value 3204 for strobe puls length, that I measured as 36.4µs (I tried with 3.6µs before, but the video was nearly completely black; I used unfocused 5000lm led, using reflector the focused light will result in much brighter videos, I have also the option to upgrade to 10000lm led):

Code: Select all

$ cat frex_i2ccs
#!/bin/bash
./i2cwrite36 /dev/i2c-0 3002 ff
./i2cwrite36 /dev/i2c-0 3b01 00 08 00 04 00 14 1d
./i2cwrite36 /dev/i2c-0 3b0b 00 c8

while true
do
  ./i2cwrite36 /dev/i2c-0 3b08 01 
  sleep 0.0288
done
$

The video was captured by running raspivid in 2MP mode in the background with a dummy slow framerate, and then run above script to capture the global reset frames:

Code: Select all

pi@raspberrypi3B:~ $ 
pi@raspberrypi3B:~ $ raspivid -md 1 -p 10,10,960,540 -fps 1.2 -t 10000 -pts tst.pts -o tst.h264 -t 10000 &
[1] 7631
pi@raspberrypi3B:~ $ ./frex_i2ccs
i2cwrite36: i2cwrite36.c:33: main: Assertion `WRITE_I2C(i2c_fd, buf, len)==0' failed.
./frex_i2ccs: line 10:  7968 Aborted                 ./i2cwrite36 /dev/i2c-0 3b08 01
i2cwrite36: i2cwrite36.c:33: main: Assertion `WRITE_I2C(i2c_fd, buf, len)==0' failed.

After raspivid completed, I stopped frex_i2ccs script that gets only assertions, and used mediainfo to determine frames captured:

Code: Select all

$ mediainfo --fullscan tst.h264 | grep "Frame count"
Frame count                              : 160
Frame count                              : 160
$ 

I uploaded the video to youtube, propeller rotates with 5100rpm, that is 85rps or one full rotation per 11.7ms. Video was captured at 25fps, so propeller moves 3.4 full rounds between successive frames:
https://www.youtube.com/watch?v=iWLeZDj ... e=youtu.be


Here are three consecutive frames from the captured video -- more work to be done, but these frames prove that Arducam ov5647 can do "global shutter" (2MP!) frames:



On this frame you can clear read "A2" on the rotating propeller!

[HermannSW]

More details on first successful Arducam ov5647 global shutter video.

I loaded 1st of the three frames shown above into gimp, and then changed brightness by +100, contrast by +71. This is just the propeller, even that is 714x935:



This is just propeller from previous 640x480@90fps with 100µs shutter time video with extreme rolling shutter effect for comparison (both times the propeller speed was 5100rpm, that is not rifle bullet speed, but 9m/s or 36.6km/h on the outside of the properller):



I took a 640x480@100fps v2 camera video on how taking global shutter videos looks like:
https://www.youtube.com/watch?v=v0zhZI8 ... e=youtu.be

The global shutter video was recorded with exactly 25fps, therefore 3 of every 4 frames look like this (only power led from Pi 3B is lighted, room is dark):



Every 4th frame is very bright with 5000lm led powered, the 5000lm led is powered on for 2ms, but only the last 36.34µs of that time frame are inside frame exposure:




This is from "FREX rising edge until STROBE falling edge" phase of logic analyzer that captured FREX/STROBE/SIG pins during taking the video. If you zoom in, you can see frequency of 24.98Hz for the strobe pulses. And you can see 36.34µs strobe pulse length:



In previous posting I showed that pulse length was configured with value 3204. The 36.34µs are interesting, because the ov5647 pixel clock must have run at 96MHz, and not at 68MHz (which is the default for 1920x1080 mode 1):

Code: Select all

$ echo "3204/96" | bc -ql
33.37500000000000000000
$ 

The falling edge delay (between STROBE pin in middle channel, and mosfet SIG pin in bottom channel) has increased, its now 100ns (the logic circuit plus the added inverter between circuit and mosfet SIG pin):

[HermannSW]

Final details of first global shutter capturing with Arducam ov5647 camera.

This is the whole setup, on the left you see the 5000lm led with heatsink on top, on bottom right you see logic analyzer (that is not really needed, but provides invaluable insights into what is going on). I used the two halves of motor station security plexiglas top as transparent layer on top of motor station bottom installations. This allows to place all but the Arducam ov5647 camera on the plexiglas top. With one of the plexiglas halves being placed diagonally, the top layer is sufficiently stiff for all the stuff placed on it:



Following the flow, the Pi 3B is the first. It is connected to HDMI monitor, and that shows global shutter preview frames. The Pi powers the new logic circuit board, the SN74HC04N 6xInverter IC on black mini breadboard as well provides GND to logic analyzer. Of course Arducam ov5647 camera is connected as well:



The new logic circuit I did solder is different to the old one. It has 2pin yellow headers for GND, VCC, Q and not(Q), and for S and R, where you can select individually whether you want to trigger on falling or rising edge:



As discussed already, Q cannot be directly connected to mosfet SIG. This is SN74HC04N 6xInverter IC with VCC and GND connected from Pi on diagonally opposite pins. Logic circuit not(Q) is connected to 1st inverter input, and its output is connected to mosfet SIG:



Since my only 400W mosfet got broken, I use two IRF520 0-24V mosfets in series for the 38V/1.5A led driver that is connected on right side of right mosfet. Left side of left mosfet is directly connected to 5000lm led. Both mosfets are connected in the middle by thick cables that can deal with 1.5A/3A for 5000lm/10000lm led. The three thin cables at bottom connect GND/VCC/SIG pins of both modules together:



Finally this is Arducam ov5647 camera connected to Pi 3B. Its FREX and STROBE signals are connected to logic circuit S rising edge and R falling edge inputs:



This is the underside of new logic circuit just shown, better than last time, partially because I used thinner tin-solder:



And this is the soldering layout, again vertically flipped in order to match what you see when soldering. Instead of having complete rising/falling edge detection in left/right side module, this time both moduels are just a sequence of 4 NOTs, with connections to 4th and 3rd not. All three ICs are four 2-input NORs this time, and the 4th not allows to do rising edge detection as well. The middle IC contains two NORs to complete the side edge detection circuits, and the two RS flip-flop feedback NORs.
I told a colleague about the hardware issue/feature with my last logic circuit (output signal goes high without cause after 0.2s), he told me "change the IC". I was not able to do that easily because I did solder the ICs directly for that logic circuit. This time I did solder IC sockets allowing to switch ICs later:



Next steps:
When I will be back home on the weekend I will enhance global shutter lighting (with reflector and/or 10000lm led instead of 5000lm), decrease exposure time from 36.34µs to say below 10µs as a next step, capture propeller with 25000rpm speed instead of 5100rpm, campture closing mouse trap, perhaps take global shutter video with a "normal" v1 camera as described in this posting, ....

[HermannSW]

Back home earlier than I thought, and I captured more global shutter videos.

The first video was the exact same setup as described before, captured with the same commands and same steps described. The only difference was that I added the reflector to the 5000lm led. Now global shutter videos are really well lit (at least with 36.34µs effective exposure time). On the bottom you can see that the propeller is running while taking this photo with Android camera. Because I made the photo with flash, you can see the reflective material I added to one propeller blade describing a complete circle. On bottom right you see Arducam ov5647 camera with cables attached that bring the FREX and STROBE signal from the camera to my logic circuit controlling the flashes:



I uploaded the video to youtube, because it was recorded at 25fps youtube plays the video as it should. The 1920x1080 frame from that video shows that now scene is well lit despite only 36.34µs of effective frame exposure time:
https://www.youtube.com/watch?v=7yR_Wgi ... e=youtu.be



Then I did another global shutter video, again changing just one feature of the setup. This time I powered the propeller maximally with 3.7V (it draws 867mA) with speed slightly above 26000rpm(!), and there were 3 phases without flash light (I don't know the reason), as can be seen on the logic analyzer capture for that video:



This is the youtube video, you will notice that the other propellers and their motors get heavily shaken by the rotating propeller wind(?). Stop the video and press "."/"," to single-frame step fore/back; you will see no rolling shutter effect. Right clicking into the video you can select "Loop" for repeatedly playing the video, under settings you can select quality as 1080p over the automatically selected 720p to match video 1920x1080 format, and you can select speed as 0.25 to get a nicer global shutter viewing experience:
https://www.youtube.com/watch?v=aE4ihAg ... e=youtu.be


Although not planned, these flash-free phases revealed a difference of the propeller motor running that fast -- there is a small led below the propeller motor that lights the whole time. This is a (scaled down) 2MP frame from a dark phase:



Here is a full 2MP frame of a flash phase, and because of the always on led below propeller motor you can see the bottom blade looking transparent -- interesting, yes, but definitely a reason to get that led off or at least taped away. As long as all the light comes from the top 5000lm led no transparency effects show up:



Now the math on what this frame shows.

The propeller moved with >26000rpm, I do the calculation with 26000rpm. Propeller blade speed on the outside is 46.3m/s or 166.6km/h:

Code: Select all

$ echo "pi=4*a(1); pi*0.034*26000/60" | bc -ql 
46.28613176288962037666
$ echo "pi=4*a(1); pi*0.034*26000/60*3.6" | bc -ql 
166.63007434640263335597
$ 

The rotating propeller blades do not look that sharp as in the previous video. Reason is that during the 36.34µs effective frame exposure the outmost point of a blade moves 1.7mm(!) radially, while it only moves 0.33mm radially with 5100rpm:

Code: Select all

$ echo "pi=4*a(1); pi*0.034*26000/60*0.00003634" | bc -ql 
.00168203802826340880
$ 
$ echo "pi=4*a(1); pi*0.034*5100/60*0.00003634" | bc -ql 
.00032993822862089941
$ 

Last, but not least, the propeller moves 17.3 (full) rotations between two succesive frames of the 25fps video. It rotates with 433 rotations per second, and a single full rotation takes 2.3ms only:

Code: Select all

$ echo "(1/25)/(60/26000)" | bc -ql 
17.33333333333333335066
$ echo "(60/26000)" | bc -ql 
.00230769230769230769
$ echo "(26000/60)" | bc -ql 
433.33333333333333333333
$ 

P.S:
For convenience this a 1 second from the 2nd 25fps video, converted into an animated .gif playing at 5fps. This allows to really see each single global shutter frame, as well as to see that the other propellers+motors are heavily shaken by the front propeller (rotating with 26000rpm) wind:

[HermannSW]

After successfully doing 2MP 25fps global shutter videos with raspivid, I just tried to make global shutter photo using raspistill.

When I trigger frex_i2c during the runtime (-t) of raspistill, then after the time raspistill takes a rolling shutter image at the end and overwrites the previously captured global shutter frame. Later I tried timelapse, but none of the captured frames is global shutter frame, although I can see on logic analyzer that frex_i2c triggered flash happened.

I would not have thought on taking a rolling shutter photo with propeller rotating at 26000rpm, because we all know on rolling shutter effect and in previous posting we saw clear global shutter frames for 26000rpm. But after seeing this frame I thought this earns to be shown here -- the biggest rolling shutter effect I have ever taken in video or photo:

[HermannSW]

I removed the disturbing small led at rotating propeller motor. Then I reduced strobe pulse length to 960 (_0 .... 00 3c) in registers 030[6bc]. The resulting video is more dark than the initial 36.34µs strobe pulse length without reflector video, although it was taken with 5000lm led and reflector, but it is a global shutter video:
https://www.youtube.com/watch?v=J4griCg ... e=youtu.be


I tried to play with -ISO setting of raspivid, but regardless of setting video becomes even much more black thank the previously shown frame. Next I tried sharpness (-sa to 75/90/98) and saw no effect of the video captured.

So in order to get brighter frames I need to swap the 5000lm led with a 10000lm led.

So what did 10.88µs strobe pulse length result in compared to 36.34µs?
Frame became much sharper as well; while a blade moved 1.68mm radially in 36.34µs probe pulse length scenario for 26000rpm propeller (left), it does move only 0.5mm for 10.88µs (I did load frame from 10.88µs strobe pulse length video into gimp and did the same modifications as described in previous posting, and then extracted the propeller). New video was taken with 26000rpm propeller speed as well:

[HermannSW]

It seems that it was too late last night, I chose the wrong raspivid option (sharpness instead of brightness), and even for that option the wrong short option (-sa instead of -sh).

So just now I did another video with 10.88µs shutter time, and I looked up the real logic circuit delay in logic analyzer capture for that run as 140ns. So strobe pulse lengths was 11.02µs for that run, and from previous posting measurements we know that laser sensor measured delay for two IRF520 mosfet chain is 2.4µs. So real eposure of the new video is 13.42µs. I tried "-br 75" because 50 is default (0-100 range). No need (yet) to upgrade to 10000lm led, with brightness 75:
https://www.youtube.com/watch?v=089scsY ... e=youtu.be



Currently it seems there are no obstacles for going into low 1-digit microsecond strobe pulse length range global shutter videos, raspivid brightness can be increased over 75, and I have the 10000lm led [either as replacement of the 5000lm led, or additionally for 15000lm (although more reflectors are shipped but in transit)].

There is a little optimization that needs to be done, in propeller range, in middle of the rotating propeller motor, there is a little reflective spot of solder. I just taped it away because light from below the propeller is unwanted as discussed in a previous posting.

Part of the 25fps video converted to animated gif, playing at 5fps allowing to really see the global shutter frames.
11µs strobe pulse length is 1/90909 second.
I used modified gifenc.sh, that scales 1920×1080 video to 640×360 animated gif:

[HermannSW]

Today I soldered the not from black breadboard onto the logic circuit itself. I used the same quad nor IC as the three already present ICs. And I exposed two new buffered outputs, one for Q and one for not(Q):



This is the underside, just some more soldered pins for the new IC and few new cables:



This is the corresponding layout, flipped vertically to match what has to be soldered:



The new logic circuit allows for a clearly arranged setup with just the minimal number of cables. The led driver on top right delivers 38V/1.5A to two-IRF520 mosfet chain, and that powers the 5000lm led (with heatsink on top and reflector below) on left side. GND and Vcc of 1st IRF520 mosfet are connectore to logic circuit GND and VCC, that are connected to Pi 3B GND and VCC. Mosfet SIG is connected to logic circuit Qbuf. Two cables from Arducam ov5647 camera below are connected to rising S and falling R. Logic analyzer GND is connected to Pi 3B, and channels 0/1/2 are connected to rising S/falling R/Qbuf of logic circuit: