Hardware failure mechanisms?

I'm curious what kind of failure mechanisms one might expect from the OAK-FFC 4P.

I've been playing with this board a lot, and it's seen heavy use for the better part of the last five days. I have been running variations on the same code, which does the following. I am attempting to connect multiple sensors (usually two OAK-FFC-OV9782 modules), collect both isp and video frames, view the video frames with cv2.imshow and write them to memory with cv2.imwrite, and use the isp and control streams to monitor and adjust the settings on the cameras, similar to depthai-python/examples/ColorCamera/rgb_camera_control.py. Over the last couple of hours, I've observed notable degradation in the hardware.

When I was controlling and viewing image settings with the video, isp, and control streams, but not recording, things were working fairly smoothly.

When I started to also write the images to memory, I started to see some issues: after a few hundred images, my script would error out with the following runtime error:

RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: 'video_test_vid_F' (X_LINK_ERROR)'

As I continued to test, I started to see one of the sensors increasingly flickering purple and having a slightly streaky quality to it. I could not make this go away by changing the white balance or exposure settings.

I tried to isolate the failure to the board, cable, or camera module. After switching the cameras (and cables, independently) I attributed the poor image quality to CAM-D on the FCC board, while CAM-A seemed to be working fine.

At this point, I started testing different CAM buses. I tried running the example scripts (e.g. depthai-python/examples/ColorCamera/rgb_video.py and /rgb_camera_control.py), and to my surprise, they didn't even detect the camera--though the error came from socket0 while the camera was on a different slot. My own script could still detect a camera when I told it which slot to use.

[1844301011D0BD0F00] [3.1] [4.085] [ColorCamera(0)] [error] Camera not detected on socket: 0

Then I plugged one camera into CAM-C and tried to run my script again. The image was purple-ish, but it seemed I could change how much purple I saw by touching the cable, which was not the case before. After a few hundred frames, I saw a seg fault:

[2023-04-23 20:21:34.280] [warning] Monitor thread (device: 1844301011D0BD0F00 [3.1]) - ping was missed, closing the device connection

Stack trace (most recent call last) in thread 295330:

#9    Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in 

#8    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f472f93166b, in 

#7    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f472f8b0fd3, in 

#6    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/[depthai.cpython-310-x86_64-linux-gnu.so](http://depthai.cpython-310-x86_64-linux-gnu.so/)", at 0x7f470d239907, in 

#5    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/[depthai.cpython-310-x86_64-linux-gnu.so](http://depthai.cpython-310-x86_64-linux-gnu.so/)", at 0x7f470d23ab84, in dispatcherEventReceive

#4    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/[depthai.cpython-310-x86_64-linux-gnu.so](http://depthai.cpython-310-x86_64-linux-gnu.so/)", at 0x7f470d242956, in usbPlatformRead

#3    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/[depthai.cpython-310-x86_64-linux-gnu.so](http://depthai.cpython-310-x86_64-linux-gnu.so/)", at 0x7f470d24285e, in usb_read(libusb_device_handle*, void*, unsigned long)

#2    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/depthai.libs/libusb-1-105e664f.0.so", at 0x7f47267eddce, in libusb_bulk_transfer

#1    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/depthai.libs/libusb-1-105e664f.0.so", at 0x7f47267ed9db, in 

#0    Object "/home/mgiustina/.virtualenvs/luxonis/lib/python3.10/site-packages/depthai.libs/libusb-1-105e664f.0.so", at 0x7f47267eb8b5, in libusb_submit_transfer

Segmentation fault (Address not mapped to object [(nil)])

Segmentation fault

After this I have not been able to see any images with cv2.imshow, neither when I try to run the example scripts nor with my own script.

Are you familiar with any of this kind of behavior?

I emailed luxonis and received the following response; I'm including my answers to it inline.

Very interesting observations, I haven't encountered this kind of behavior before.

• Few things though: depthai-python/examples scripts don't really know what's plugged in where. The do as they were preprogrammed. This means you have to manually assign the socket of a camera if you wish to use the script with FFC.

OK, noted. I'd had success with the rgb_camera_control.py script earlier in the day, but I did have a camera in socket 0 (CAM-A), so that makes sense.

• You get purple image if you connect a mono camera and instantiate it as an RGB camera node inside the script. Perhaps this is what you are experiencing.

I've seen the purple image from connecting a mono camera instantiated as an RGB camera node. This is something different, in a few ways: (a) this isn't a mono camera!, (b) the image is not only purple but also streaky, (c) the color gradually degraded over the course of several hours (starting from one side of the image). However, it is a similar color of purple.

• Not sure about changing the purple amount by touching the cables -- sounds like a bad connection issue. Port pins on the board or on the molex connector could be damaged/oxidized due to frequent module change.

That's an understandable failure mechanism. In this case, the initial degradation happened over the course of a few hours in which I wasn't re-plugging any connectors at all--the module was powered on and operating the whole time.

Could you please open a thread at https://discuss.luxonis.com and paste your last message, so we have better tracking and visibility?

Done!