Multi_Adapter_Board_2Channel_uc444

[adzio]

1.Which seller did you purchase the product(s) from?
Amazon
2.The Model number of the product(s) you have purchased?
B016601
3.Which Platform are you using the product(s) on?
Raspberry Pi
4.Which instruction are you following?
paper instruction
5.Has your product ever worked properly?
work intermittently
6.What problems are you experiencing?
There seems to be a delay between the completed write on GPIO 7 and the multiplexer switching to the “other” sensor, especially when you try to squeeze out more performance out of this hardware setup.

My questions are:

• What is the anticipated total time delay for the multiplexer hardware to switch completely to the “next” camera so that the next grab is taken entirely from the “other” sensor?
• Similar to the above, what is the maximum frame rate obtainable at the hardware level at the resolution you’re promoting (320x240, https://github.com/ArduCAM/RaspberryPi/blob/master/Multi_Camera_Adapter/Multi_Adapter_Board_2Channel_uc444/arducam_multi_adapter_uc444.cpp#L129-L130)
• Is there a way to read some GPIO or issue an I2C call to be able to know reliably when the next grab will happen from the intended sensor? I don’t know if it’s intentional, but in your example code you’re "grab"bing before doing a “read”: https://github.com/ArduCAM/RaspberryPi/blob/master/Multi_Camera_Adapter/Multi_Adapter_Board_2Channel_uc444/arducam_multi_adapter_uc444.cpp#L142-L143 which is redundant and introduces a slight, artificial delay.

In summary I’d like to know a way to programmatically tell that the next read from each sensor can be performed in full.
7.What attempts at troubleshooting have you already made?

8.How would you like us to help you?

[lvbin]

Hello,

Thanks for your business. Don’t worry and I will try my best to help you.

According the current design plan, we can’t determine the specific time when the field signal(VTS) of A and B camera ends. So we can’t guarantee that the data obtained after switching

the camera channel is just complete. It may be the middle position of a frame of data. Therefore, in order to prevent wrong data from being fetched, the first frame of image fetched after switching will be discarded, and the second frame of data will be fetched for display. Therefore, the frame rate will suffer a certain loss.Generally speaking, if the sensor outputs 320x240@30fps, it is good that we can get 15 frames of stable data.

[adzio]

Thanks Bin for the answer. It makes sense that the effective fps per sensor is somewhat less than 50% of the original one sensor fps. But I’m also trying to push the limits of the multiplexer - from what you wrote it’s not impossible for the upper bound of the multiplexer performance to lay somewhere above the sensor’s 30fps.

Based on some other posts by RPi foundation the sensor fps is configurable for RPi supported cameras and some modes to above 30 fps, including 90fps; did you folks play with that? For me it seemed to hang at 60fps but 90fps setting does return solid images through the 2 channel adapter, albeit they are a bit underexposed. Given what you wrote above I figured we could expect 30-40 fps read per camera with sensor configured at 320x240 and 90fps and with appropriate lighting, correct? I’m getting 36fps in that configuration.

Also: you use OpenCV in example code for your products. It looks like OpenCV image processing speed is faster in Raspberry Pi OS 5.4 vs. Ubuntu 20.04 by about 15% on the same hardware. Based on your familiarity with OpenCV, what could be the reason for the difference? Does Raspberry Pi OS has the benefit of shipping with IPP or some custom Broadcom optimized libs?

Thnx

[lvbin]

Hello,

About the frame speed, It’s up to the sensor’s configuration. We can’t change official’s configuration.

About the second issue. It may be related to the operating system scheduling and memory size.