Acces to VSYNC pin for two OPenMV M7 in stereoscopic mode

OpenMV Products
#1

Hi,

I want to synchronise two OpenMV M7 for stereoscopic vision. Usually i connect the VSYNC pin of one camera module to the FSIN (FRAME SYNC )pin of the other camera module in a Master/slave fashion.

FRAME SYNC pin is already there, but can’t find a connexion for the VSYNC pin. In the schematics the VSYNC pin is connected nowhere.

Can we acces the VSYNC PIN somewhere on OpenMV M7 module ?

if not Is there a method to “redirect” the VSYNC signal to any other pins we have on the header ?

If not is there a method to toggle an external pin like P9 at the right moment (VSYNC) and fast enough for a 60 frames by seconds setting ?

Thanks.

#2

VSYNC is connected to the MCU it’s not broken out. It’s possible to toggle an I/O when VSYNC interrupt occurs, but that will have to be implemented in C code. I’ll try to enable that with an option in the next release.

#3

Hi thanks for the reply,

I want your advice about two possible solution in the wait for the next release:

Solution A)

I’am willing to do some precision soldering here ( and void the warranty of the M7, of course )
On the first camera module, solder the MCU pin receiving the VSYNC signal directly the the FSIN of the second camera.

To witch pin number of the MCU does VSYNC pin is connected to ?

Does i need some pull up or pull down resistor or a current limiting resistor ?

Solution B)

Program an Arduino board to send a pulse of 280 µs to FSIN (frames sync) PIN of both camera at a rate of 60 times per seconds.
Look better for me, but the 280 µs pulse is a guest based on other OV camera module.

I think the pulse should be 3.3 volts to keep things clean.

Another advantage of this solution i can simulate a 120 frames by seconds by adding an offset of 2 ms (1/120 seconds) to the second FSIN pin.
So we have two 60 frames by seconds capture offset by 2 ms giving 120 distinct frame by second.

is there a problem if i permanently send trigger signal to FSIN PIN (from power on until power off of both camera ) ?

Anyway i can program the Arduino to wait a HIGH on pin P9 of the master camera before starting sending FSIN pulse.


Have a nice day.

#4

I’d do solution 2. Um, look at the camera datasheet for how long to make the pulse. The data sheet has the vsync waveform.

#5

It’s going to be hard to solder a wire to VSYNC because it’s routed directly on the top layer (No vias) so you’ll have to scratch the wire’s solder mask and solder a wire there, or solder a very thin wire to the MCU pin.

is there a problem if i permanently send trigger signal to FSIN PIN (from power on until power off of both camera ) ?

I don’t think so, but if it’s a problem like you said you could wait until the sensors are both initialized.

An easier solution if you’re willing to hack the code is to implement this function in sensor.c:

__weak void HAL_DCMI_VsyncEventCallback(DCMI_HandleTypeDef *hdcmi)
{
  /* Prevent unused argument(s) compilation warning */
  UNUSED(hdcmi);
 
  /* NOTE : This function Should not be modified, when the callback is needed,
            the HAL_DCMI_VsyncEventCallback could be implemented in the user file
   */
}

And toggle any I/O you like (you’ll have to initialize it first, see stm32fxxx_hal_msp.c). This is how I plan to implement it but I’ll add a function to pass the pin name.

#6

So I did some testing, I connected VSYNC directly to FSIN and it seems to work (with 200ns latency) except the second cam’s VSYNC is inverted (when VSYNC1 is high VSYNC2 is low). I’m not sure why and I’m not sure if they’re capturing the same frame or 2 frames back to back. Anyway, so I tried to generate and inverted FSIN by toggling an I/O in VSYNC1 interrupt and in frame end interrupt. This time it works as expected, but there’s 500us delay between VSYNCs and that’s probably bad for stereo.

If you have any ideas/suggestion or want to test the code let me know.


NewFile2.png
NewFile2.png800×585 61.3 KB

#7

Both cameras should be a slave to one clock source. Neither should be a master.

The clock source can come from with cam via PWM. But, not VSYNC.

#8

Why not ? I think it’s okay to drive FSIN from VSYNC in master/slave setup, see this report using OV7221 (very similar to OV7725 but maybe FSIN behavior is different) I was trying to achieve the same results in Figure 6, but the best I can do is either inverted VSYNCs or 500us delay.

#9

Having a non vsync master source should solve the problem right?

#10

I’m not sure if it’s a problem or just different FSIN behavior.
I think the external clock has to match the timing for VSYNC (for each frame size) but it should work.

#11

Okay I fixed the issue with the inverted clock, and I also figured out why there’s a 500us delay, it’s actually the end of frame interrupt that’s delayed for some reason (Note this is generated by the DCMI not the sensor). Still not able to reduce that delay or detect VSYNC falling edge. Will keep trying for a while before giving up.

#12

Just use a standard pin interrupt.

#13

I tried that as well, it works but changing VSYNC function disables the DCMI.

#14

So I figured out the exact problem, see the following figure…I get an interrupt on the rising edge of VSYNC at this point I set the IO high (with 200ns delay==perfect) problem is I don’t get another interrupt on the falling edge (this is when valid data start), so as a workaround I used the HREF/LINE rising edge interrupt to set the external IO low. The first line is delayed about 500us from the VSYNC rising edge, and this causes the IO delay.

I couldn’t find any obvious way to get an interrupt on both edges, and I can’t set VSYNC as an interrupt because this changes the pin function. I’m interested in figuring out if there’s a software solution, otherwise we could buffer VSYNC and route to another pin in some future HW revision.


Screenshot from 2017-05-21 19-37-45.png
Screenshot from 2017-05-21 19-37-45.png2442×1084 104 KB

#15

Okay I finally got it working! It turns out you can enable EXTI and AF at the same time. The two VSYNCs now:

sync1.png
There’s about 80us delay between FSIN and VSYNC changing on the second cam, I don’t think this can be reduced (I’ve seen the same delay even when connecting VSYNC to FSIN directly)

sync3.png