Low-Light HD USB Camera Random Disconnect | Pi 3B+

Blue Robotics Products Cameras
1

I am using the Low-Light HD USB Camera on a Pi 3B+ (Kernel 5.10.11-v7+). On multiple occasions the USB device has disconnected from the Pi and requires a reboot for the device to be rediscovered. While the device is disconnected the /dev/video2 will not appear. During this time I cannot access the camera until the Pi has been power cycled. The immediate solution is to reboot and if it occurs very often then I swap the sensor with a brand new camera which seems to alleviate problem for sometime. Any recommendations on how to prevent this?

[Mon Mar 1 16:54:16 2021] usb 1-1.3: USB disconnect, device number 4
[Mon Mar 1 16:54:16 2021] uvcvideo: Failed to resubmit video URB (-19).
[Mon Mar 1 16:54:16 2021] uvcvideo: Failed to resubmit video URB (-19).
[Mon Mar 1 16:54:16 2021] uvcvideo: Failed to resubmit video URB (-19).
[Mon Mar 1 16:54:16 2021] uvcvideo: Failed to resubmit video URB (-19).
[Mon Mar 1 16:54:16 2021] uvcvideo: Failed to resubmit video URB (-19).
[Mon Mar 1 16:54:16 2021] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[Mon Mar 1 16:54:16 2021] usb 1-1.3: New USB device found, idVendor=05a3, idProduct=9422, bcdDevice= 1.00
[Mon Mar 1 16:54:16 2021] usb 1-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[Mon Mar 1 16:54:16 2021] usb 1-1.3: Product: H264 USB Camera
[Mon Mar 1 16:54:16 2021] usb 1-1.3: Manufacturer: Sonix Technology Co., Ltd.
[Mon Mar 1 16:54:16 2021] usb 1-1.3: SerialNumber: SN0001
[Mon Mar 1 16:54:16 2021] uvcvideo: Found UVC 1.00 device H264 USB Camera (05a3:9422)
[Mon Mar 1 16:54:17 2021] input: H264 USB Camera: USB Camera as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
[Mon Mar 1 16:54:17 2021] usb 1-1.3: 4:1: cannot get freq at ep 0x84

2

First of all, you should get your usb connection into a reliable condition. Make sure there is enough slack in the cable and that it is not pulled tightly. Make sure the connectors on both sides are well-seated. Contact support@bluerobotics.com if the cable is damaged and you need a new one.

With that aside, you should be able to use the camera after it reconnects without a reboot. When you are doing file I/O with the camera on /dev/video2 and the camera disconnects, when the camera reconnects, it will not be assigned /dev/video2 if you have not closed the file at that point. It will appear at /dev/video3 or whichever number is next available and not in use at that point in time.

What you need to do is close the /dev/video2 file after the camera disconnects (there are a number of ways of detecting and accomplishing this, but you should see some error in your program when you try to do file I/O on the device after the camera disconnects.

If you need more help, please provide more information with your code and full dmesg output.

3

Thanks for the reply Jacob.

My projects gstreamer pipeline currently defaults to /dev/video2 for its v4l2src and I am looking for a way to dynamically select the H264 v4l2 device I should be using here. This is important because if the USB disconnects like I described in the previous post my live stream will be down. I want to fall back onto the next available v4l2 device that supports H264 video capture from my BlueRobotics Low-Light HD USB Camera.

My gstreamer pipeline starts like this:
gst-launch-1.0 v4l2src device=/dev/video2 ...

I noticed after reading your comment that the video capture device will swap to /dev/video3 if the USB disconnects on /dev/video2. Conversely, When /dev/video2 is connected, /dev/video3 cannot be used for the gstreamers video capture device. I was able to determine this after I ran v4l2 commands on two nodes, one with the USB connected as expected and one without. I attached the output that details this behavior below.

I also wanted to note that I still have not been able to recover the /dev/video2 device once it disappears without rebooting the RPi. You mentioned "What you need to do is close the /dev/video2 file after the camera disconnects (there are a number of ways of detecting and accomplishing this". I was hoping you could provide more details on this, as I have not been successful in recovering access to the /dev/video2. If theres a way to dynamically select the active v4l2 device that is being used for H264 video capture then no matter how many potential USB disconnects could occur I would be able to fall back onto a valid v4l2 device for my live stream. Assuming something like this is possible, I would like to implement this.

Possible Solution:
I’m thinking of iterating over each /dev/video* device and checking for the output of the command v4l2-ctl --list-formats --device /dev/video*. The v4l2 device I want to use should output a response that contains the string [0]: 'H264' (H.264, compressed). This seems to correlate to the v4l2 device that can actively be used for H264 video capture in my gstreamer pipeline.

Does this sounds like the right approach? Would love to get your feedback on this, or if you think think there is a better solution to this problem I’ve been facing. Let me know if I can provide any additional information that I may not have provided below.

P.S
Additionally it would be nice to probe the buffer to determine if the sensor is even reading data from the v4l2 device. I’ve had a couple Low-Light HD USB Camera go bad, the sensor stops readings data and when that happens the gstreamer pipeline fails silently because it can open the video device but no data is coming through. When this has happened in the past I’ve just swapped it out for a new Low-Light HD USB Camera.

—————————————— on device with /dev/video2 (expected) —————————————————

v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12

bcm2835-isp (platform:bcm2835-isp):
        /dev/video13
        /dev/video14
        /dev/video15
        /dev/video16

H264 USB Camera: USB Camera (usb-3f980000.usb-1.1.2):
        /dev/video0
        /dev/video1
        /dev/video2
        /dev/video3

v4l2-ctl --list-formats --device /dev/video0
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'MJPG' (Motion-JPEG, compressed)
        [1]: 'YUYV' (YUYV 4:2:2)

v4l2-ctl --list-formats --device /dev/video1
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

v4l2-ctl --list-formats --device /dev/video2
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'H264' (H.264, compressed)

v4l2-ctl --list-formats --device /dev/video3
ioctl: VIDIOC_ENUM_FMT
       Type: Video Capture

—————————— on device with /dev/video2 disconnected (unexpected) ——————————

v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12

bcm2835-isp (platform:bcm2835-isp):
        /dev/video13
        /dev/video14
        /dev/video15
        /dev/video16

H264 USB Camera: USB Camera (usb-3f980000.usb-1.3):
        /dev/video0
        /dev/video1
        /dev/video3
        /dev/video4

 v4l2-ctl --list-formats --device /dev/video0
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'MJPG' (Motion-JPEG, compressed)
        [1]: 'YUYV' (YUYV 4:2:2)

v4l2-ctl --list-formats --device /dev/video1
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

v4l2-ctl --list-formats --device /dev/video2
Cannot open device /dev/video2, exiting.

v4l2-ctl --list-formats --device /dev/video3
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'H264' (H.264, compressed)

—————————— Full Dmesg Output (This is on RPi with the USB Disconnect) —————————

[Mon Apr  5 09:11:04 2021] uvcvideo: Found UVC 1.00 device H264 USB Camera (32e4:9422)
[Mon Apr  5 09:11:04 2021] input: H264 USB Camera: USB Camera as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input0
[Mon Apr  5 09:11:04 2021] usbcore: registered new interface driver uvcvideo
[Mon Apr  5 09:11:04 2021] USB Video Class driver (1.1.1)
[Mon Apr  5 09:11:04 2021] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[Mon Apr  5 09:11:04 2021] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan  4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[Mon Apr  5 09:11:04 2021] usb 1-1.3: 4:1: cannot get freq at ep 0x84
[Mon Apr  5 09:11:04 2021] usbcore: registered new interface driver snd-usb-audio
[Mon Apr  5 09:11:06 2021] uart-pl011 3f201000.serial: no DMA platform data
[Mon Apr  5 09:11:06 2021] random: crng init done
[Mon Apr  5 09:11:06 2021] random: 7 urandom warning(s) missed due to ratelimiting
[Mon Apr  5 09:11:06 2021] 8021q: 802.1Q VLAN Support v1.8
[Mon Apr  5 09:11:07 2021] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[Mon Apr  5 09:11:07 2021] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Mon Apr  5 09:11:07 2021] 8021q: adding VLAN 0 to HW filter on device eth0
[Mon Apr  5 09:11:07 2021] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[Mon Apr  5 09:11:13 2021] Bluetooth: Core ver 2.22
[Mon Apr  5 09:11:13 2021] NET: Registered protocol family 31
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI device and connection manager initialized
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI socket layer initialized
[Mon Apr  5 09:11:13 2021] Bluetooth: L2CAP socket layer initialized
[Mon Apr  5 09:11:13 2021] Bluetooth: SCO socket layer initialized
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI UART driver ver 2.3
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI UART protocol H4 registered
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI UART protocol Three-wire (H5) registered
[Mon Apr  5 09:11:13 2021] Bluetooth: HCI UART protocol Broadcom registered
[Mon Apr  5 09:11:13 2021] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[Mon Apr  5 09:11:13 2021] Bluetooth: BNEP filters: protocol multicast
[Mon Apr  5 09:11:13 2021] Bluetooth: BNEP socket layer initialized
[Tue Apr  6 04:15:35 2021] usb 1-1.3: USB disconnect, device number 4
[Tue Apr  6 04:15:35 2021] uvcvideo: Failed to resubmit video URB (-19).
[Tue Apr  6 04:15:35 2021] uvcvideo: Failed to resubmit video URB (-19).
[Tue Apr  6 04:15:35 2021] uvcvideo: Failed to resubmit video URB (-19).
[Tue Apr  6 04:15:35 2021] uvcvideo: Failed to resubmit video URB (-19).
[Tue Apr  6 04:15:35 2021] uvcvideo: Failed to resubmit video URB (-19).
[Tue Apr  6 04:15:36 2021] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[Tue Apr  6 04:15:36 2021] usb 1-1.3: New USB device found, idVendor=32e4, idProduct=9422, bcdDevice= 1.00
[Tue Apr  6 04:15:36 2021] usb 1-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[Tue Apr  6 04:15:36 2021] usb 1-1.3: Product: H264 USB Camera
[Tue Apr  6 04:15:36 2021] usb 1-1.3: Manufacturer: H264 USB Camera
[Tue Apr  6 04:15:36 2021] usb 1-1.3: SerialNumber: 2020032801
[Tue Apr  6 04:15:36 2021] uvcvideo: Found UVC 1.00 device H264 USB Camera (32e4:9422)
[Tue Apr  6 04:15:36 2021] input: H264 USB Camera: USB Camera as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
[Tue Apr  6 04:15:36 2021] usb 1-1.3: 4:1: cannot get freq at ep 0x84
4

Hi @dcdennis, welcome to the forum :slight_smile:

I’m not sure if this is what Jacob meant, but the Blue Robotics companion software runs a script on startup called streamer.py which basically manages the video connection. If the stream drops out it tries to reconnect again 2 seconds later.

This is similar to what’s done in the companion software, except that instead of searching through the v4l2 device format info it just tries to connect to each device with gstreamer until it finds one that works. You may wish to do something similar.

This shouldn’t really occur. Unfortunately I’m not sure how to add polling functionality to check that frames are actually being retrieved and sent to the top side. If the camera sensor is broken then the camera needs to be replaced, and if the video feed isn’t arriving at the top I’d assume you need to open the watertight enclosure anyway, so not certain how useful such polling functionality would be anyway. If you’re wanting to run a remote check without opening the enclosure then your best bet is likely SSHing into the RPi and trying to run a gstreamer pipeline so you can read any error messages that appear :slight_smile:

5

Hi @dcdennis,

It’ll depends of the programming language that you are using, but you’ll probably find a library that’ll abstract v4l for you with the camera capabilities.
Be aware that if you are having connection issues in the usb cable this may not work, as said, you should first fix the cable, otherwise we you are going to have the same problems, as the kernel can give up trying to detect it.