BATC Forum

I note in the software section that having the EasyCap dongle connected blocks certain video camera devices / encoder modes.
Indeed as I have the easycap built into my case and plugged in, I had to unplug it to make the rpi cam work.
Is this a bug or a feature ?
I could easily fix it in hw by adding a switch in series with the USB control lines to the easycap, but a FW fix would be more elegant.

Are there any plans to address this or should I simply fit a switch ?

73 Tim

Hi Tim

I spent a good few hours on this problem last week. The issue is a lot more complex to solve with software than it seems at first, mainly due to the specialised nature of the Pi hardware relating to its camera and hardware H264 encoder.

I suspect that the final answer is going to be a software controlled relay that switches the USB lines in and out - much as you have suggested. I'm still looking for a totally software based solution, but I will give up in a week or 2. I need to finalise the hardware design of my own Portsdown then!

If you want to future-proof your Portsdown against too many future changes, I would suggest a relay to switch the EasyCap into circuit when energised (ie normally out of circuit). We'll work out how to drive it in a few weeks, but there should not be any need for a front panel switch.

Dave

Hi Dave,

thanks for the explanation. I didn't want to clutter up the front panel with a switch as it would defeat the idea of a touch screen.
So a relay controlled by a GPIO signal seems like the better option at this point.

73 Tim

Disable via UDEV maybe and reload the rules? I suppose you tried that as well as loading and unloading kernel modules.

Mike

Mike

I did not get into udev, but am keen to try if you could help.

What I need to achieve is that the EasyCap always loads as /dev/video1, even if the RPi Camera has not activated and taken /dev/video0. The solution needs to work even if the PiCam or the EasyCap is not present.

How might I load/unload kernel modules to make it work?

Thanks

Dave

Hi Dave,

Like Mike says that sounds like a job for Udev - it's a problem I had before with various USB devices being allocated differently.
I understand enough to do it for Ubuntu (it's actually quite easy), but not sure about RPI but I doubt it's much different.
Knowing me I could do it ok, but would likely break something else in the process !

Hi Dave,

I would need to do some investigation - we had the same problem with the UKUBE ground station, with several audio cards and serial adaptors it was important to make them load consistently. I recall latterly similar issues with DATV Express. UDEV is designed to do exactly this, so if you want it to load as /dev/video1 you can do this with UDEV. The following is in linux lingo so may not make sense to many sorry.

Firstly we need the vendor code. I don't know how consistent these are. Plugging in the capture device and running the dmesg command piped through grep usb to reduce the verbiage indicates in my case

pi@raspberrypi:~ $ dmesg |grep usb
....
[ 328.387835] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[ 328.519572] usb 1-1.3: New USB device found, idVendor=534d, idProduct=0021
[ 328.519585] usb 1-1.3: New USB device strings: Mfr=1, Product=0, SerialNumber=0
[ 328.519594] usb 1-1.3: Manufacturer: MACROSIL

pi@raspberrypi:~ $ dmesg |grep video
....
[ 328.520649] uvcvideo: Found UVC 1.00 device <unnamed> (534d:0021)
[ 328.520888] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 328.521569] uvcvideo 1-1.3:1.0: Entity type for entity Processing 2 was not initialized!
[ 328.521590] uvcvideo 1-1.3:1.0: Entity type for entity Camera 1 was not initialized!

and just for the record lsusb

pi@raspberrypi:~ $ lsusb
Bus 001 Device 006: ID 534d:0021
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And video for linux shows that the device has defaulted to /dev/video0

pi@raspberrypi:~ $ v4l2-ctl -d 0 --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : UVC Camera (534d:0021)
Bus info : usb-3f980000.usb-1.3
Driver version: 4.9.24
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height : 720/480
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 1440
Size Image : 691200
Colorspace : Unknown (00000000)
Flags :
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 720, Height 480
Default : Left 0, Top 0, Width 720, Height 480
Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 720, Height 480
Selection: crop_bounds, Left 0, Top 0, Width 720, Height 480
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25



So we know the capture cards vendor and device ID idVendor=534d, idProduct=0021

I was going to write instructions but then recalled they are already there in this post http://www.batc.org.uk/forum/viewtopic. ... 744#p11292

and even better here http://www.djsadhu.com/software/linux-h ... dev-rules/

Now this will simply map video0, and video1 to the same name each time but might not solve the problem if the software is hardwired to /video0. I think there is a way to make the capture driver module go to video1 but it will need more research. IT seems the answer is via the module uvcvideo but I need to find the manual.

Mike

G8GKQ wrote:Mike

I did not get into udev, but am keen to try if you could help.

What I need to achieve is that the EasyCap always loads as /dev/video1, even if the RPi Camera has not activated and taken /dev/video0. The solution needs to work even if the PiCam or the EasyCap is not present.

How might I load/unload kernel modules to make it work?

Thanks

Dave

Dave - to kill the capture module just use sudo modprobe -r uvcvideo - however, that's not very clean

Its put back with sudo modprobe uvcvideo

As per usual the driver documentation is absolutely woeful. Should be able to put options in /etc/modprobe.d/uvcvideo.conf but what these options are is a mystery.

Mike

Thanks very much for both of these posts. I had tried the former method and rejected it because if you force load the Pi Cam early in boot to make sure that it is /dev/video0, the Pi freezes if the camera is not present, and I could not see a way around this. So not robust enough for Portsdown.

The second post using sudo modprobe -r uvcvideo is a lot more interesting - I don't care if it is not too clean as long as it works and the rest of the Portsdown functionality is unaffected by its lack of subtlety. I'll put aside some time to work on this tomorrow.

Thanks again

Dave