After a bit of searches I've found that bridge-utils will solve this issue.

I have a set-up with 3 raspies (type Pi2B or Pi3B+, here named pi_1, pi_2 and pi_3) like this: pi_1 ethernet connected to pi_3 usb2ethernet adapter, pi_2 ethernet connected ro pi_3 usb2ethernet adapter, pi_3 ethernet connected to the local subnet. They all (pi_1, pi_2 and pi_3) handle I/O signals an...

Yes, thank you.

modprobe i2c-bcm2835 did the trick.

Somehow I associated the "2835" with some older pi versions, and have not tried it before.

I have this same behavior. I dare to say that: - if you build the master branch of the buildroot system, as of today or last week, accepting everything default, and only adding userspace programs; - add dtparam=i2c_arm=on dtparam=spi=on at the end of config.txt, and boot, you do not get /dev/i2c any...

One part that we know needs work is optimising the tuner code. After each frame the resulting statistics are analysed and update the values to be used for the next frame. That processing is currently taking a good few milliseconds. When running at 90fps, there's only 11ms for each frame, so with th...

I believe the dark band is a side effect from the method used to emulate a given exposure time. See, this sensors do not have some sort of "global reset gate" like CCDs. They reset the collected charge from the pixel by reading it. This is the only way (AFAIK) they could reset the pixel charge. Now,...

My first try also left some oscillations, and did no lock that well. In the second try I changed the control to "proportional", and then it locked perfectly. This means that, instead of one or 2 or (your case) 3 levels of pull, we calculate the pull level on the fly. The bigger the error, the strong...

well, I believe this will compile natively too.... I do not see any reason why not. But for now it seems this solution will only be useful to me, since the only thing I need is the temporary image buffer, which I will process with a mix of opencv and custom routines. To be useful to BerryPicker and ...

I am afraid I have not understood exactly what you are asking. Anyway, I have cross tools and a sysroot built by buildroot. So the command line for compiling this code is: /home/ivan/buildroot-git/buildroot/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-g++ -c -pipe -D_LARGEFILE_S...

here is it: http://pastebin.com/QZDf0RNV I set the camera for 40FPS, and drove a LED from PWM. The LED pulse is very narrow; a few microsecs only. With the program running and the led light reaching the sensor, there is a black stripe crossing horizontally the screen. Without controlling the sensor ...

This "mmal_port_parameter_get_uint64(port, MMAL_PARAMETER_SYSTEM_TIME, &t_test);" seems to be the function I am looking for. I will try to close the software PLL loop tomorrow. I I succeed I will post the code here. Oh, and ... BerryPicker, if you set the GPIO18 to detect rising event before setting...

sorry, did not notice that this sync issue is currently discussed in this thread: viewtopic.php?f=43&t=143820

moving there

I have a callback like this: static void video_buffer_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buffer) { .... uint64_t t_frame = buffer->pts; //int64_t t_test = mmal_port_clock_media_time_get(port); .... } This callback almost works as intended. My issue is that the t_frame time, which is s...

Thank you. I will try it and report here the result.

Regarding this idea of software frame synchronization, I see that I could start the cameras from a LAN trigger and perhaps achieve a ms level sync. But if we have continuous image acquisition afterwards, is it possible to induce a small camera delay in one of the raspberries, should the program in t...