Page 2 of 2

Re: Update 20181229

Posted: Sat Jan 12, 2019 5:32 pm
by g0mjw
I tried both C920 and Webcam


Re: Update 20181229

Posted: Sat Jan 12, 2019 5:46 pm
by G8GKQ
OK Mike

It will only work with Webcam selected (C920 mode is 2MS QPSK or 1MS APSK16 only), but I have just tried it here and cannot reproduce the fault. It seems to work perfectly in both H264 (down to 125 KS) and MPEG-2 (tested down to 500KS).

Please could you try it on the bench and give me some more information?



Re: Update 20181229

Posted: Sat Jan 12, 2019 6:46 pm
by g0mjw
I am not sure how to get you further debug info? All I found was it not working, symptom was the TX sending a plan carrier and nothing else. It has worked before which is why this is odd. I tried resetting - is it because I have a PI cam? I have a vague recollection that might be an issue. It is built in so can't be disconnected.


Re: Update 20181229

Posted: Sat Jan 12, 2019 9:22 pm
by G8GKQ
Hi Mike

Yes - that's it. There is a workaround documented on the Wiki here:


Re: Update 20181229

Posted: Sun Jan 13, 2019 9:34 am
by g0mjw
Thanks Dave,

I verified that. Plugging in later corrects it. Rebooting, with camera still attached and now it does not work. After about half an hour with google I came up with this potential solution to try.

The Wiki does not explain what the problem is so it is hard to think of a solution. Is it the order drivers are loaded? Anything to do with this ? If so that's relatively easy to fix, but I suspect its not that or you would have already.

If it is a matter of disabling the camera when a USB camera is plugged in there is a tutorial here ... s-in-linux that explains how to do that. The example if for a mouse and touchpad but I think it is just a case of finding the device identification data for the C920 and then running the correct action to unload the PICAM.

Alternatively you could unplug and replug the C920 in software during the setup sequence. Suggested code from ... 80#p219980

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

void main(int argc, char **argv)
char devicename[1024];
const char *filename = devicename;
int fd;

if ( 2 > argc || 3 < argc ) {
printf("Give USB device name as parameter\n");

if ( 2 == argc )
filename = argv[1];
sprintf( devicename, "/dev/bus/usb/%s/%s", argv[1], argv[2] );

printf( "Resetting USB device '%s'\n", filename );

fd = open(filename, O_WRONLY);
if (fd == -1) {
perror("USB device open failed");
if (ioctl(fd, USBDEVFS_RESET, 0) == -1) {
// Don't care! It usually does, when we need to reset it.
//perror("USBDEVFS_RESET device ioctl failed");

Calling it with the USB device number. So does it work? Well not on it's own but probably a starting point.

pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 046d:082d Logitech, Inc. HD Pro Webcam C920
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. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@raspberrypi:~ $ sudo ./usbreset /dev/bus/usb/001/004
pi@raspberrypi:~ $

dmeg output

[ 235.331906] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ 453.081912] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
[ 453.311872] usb 1-1.5: reset high-speed USB device number 4 using dwc_otg

But, there is also the option of unbinding and rebinding the dirver - my USB device appears as 1-1.5 in dmesg

pi@raspberrypi:~ $ sudo sh -c 'echo 1-1.5 > /sys/bus/usb/drivers/usb/unbind'
pi@raspberrypi:~ $ sudo sh -c 'echo 1-1.5 > /sys/bus/usb/drivers/usb/bind'

That did work. Unexpected consequences I don't know.