HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

ArduCam OV5647 Camera Board w/ M12 Mount

Sun Mar 10, 2019 10:04 pm

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:
Image


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
Image


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.
Image


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 :-():
Image


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


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 ... ;-)
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Tue Mar 12, 2019 1:15 am

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
Image


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.
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

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

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Tue Mar 12, 2019 10:28 am

HermannSW wrote:
Tue Mar 12, 2019 1:15 am
(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.
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.

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Wed Mar 13, 2019 9:18 am

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).
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Wed Mar 13, 2019 11:28 pm

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.
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Thu Mar 14, 2019 6:33 pm

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
Image

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!!!
Image

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!
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Thu Mar 14, 2019 8:52 pm

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:
Image


Does not look that nice, but is working prototype:
Image


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
$ 
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Fri Mar 15, 2019 4:25 pm

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 ...

Image
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Fri Mar 15, 2019 6:32 pm

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:
Image


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.
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Fri Mar 15, 2019 8:13 pm

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:
Image

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.

Image
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Sun Mar 17, 2019 11:28 am

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


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:
Image


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:
Image


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:
Image


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
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Mon Mar 18, 2019 12:44 pm

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:
Image


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
Image


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
$ 
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Wed Mar 20, 2019 2:52 pm

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:
Image


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:
Image
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Sun Mar 24, 2019 12:20 pm

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:
Image


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):
Image


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:
Image


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 ...
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Sun Mar 24, 2019 8:46 pm

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
Image


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.
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Sun Mar 24, 2019 9:52 pm

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:
Image

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 ...

Image
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

HermannSW
Posts: 1029
Joined: Fri Jul 22, 2016 9:09 pm

Re: ArduCam OV5647 Camera Board w/ M12 Mount

Mon Mar 25, 2019 6:29 pm

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
Image
bookmark list: https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/fork-raspiraw      https://github.com/Hermann-SW/userland
https://github.com/Hermann-SW/wireless-control-Eachine-E52-drone      https://twitter.com/HermannSW

Return to “Camera board”