My webcam seems to be unstable with trunk, and crashes every couple hours on my TL-WR703N (luckily mjpg-streamer automatically restarts). This is what my kernel log looks like:

[43177.500000] input: HD Webcam C525 as /devices/platform/ehci-platform/usb1/1-1/1-1:1.2/input/input16
[44416.580000] usb 1-1: USB disconnect, device number 18
[44416.970000] usb 1-1: new high-speed USB device number 19 using ehci-platform
[44417.400000] uvcvideo: Found UVC 1.00 device HD Webcam C525 (046d:0826)
[44417.650000] input: HD Webcam C525 as /devices/platform/ehci-platform/usb1/1-1/1-1:1.2/input/input17
[47125.740000] usb 1-1: USB disconnect, device number 19
[47126.070000] usb 1-1: new high-speed USB device number 20 using ehci-platform
[47126.510000] uvcvideo: Found UVC 1.00 device HD Webcam C525 (046d:0826)
[47126.750000] input: HD Webcam C525 as /devices/platform/ehci-platform/usb1/1-1/1-1:1.2/input/input18

I figured out that if I put my hand in front the lens it triggers the autofocus, which seems to cause a crash and USB re-enumeration.

Not sure if this is a driver, device or power issue.

Probably power.

I thought so too, so I had put an extra 100 uF decoupling capacitor on the USB 5 V power lines. I still have the problem though.

What picture size @fps?

1280x720 @ 5 fps. Works great most of the time.

Does this error occur also at certain lighting levels?

Reason for asking: I have a bunch of webcams (see sig), and the Logitech Pro 9000 ones give errors around sunrise/sunset when used with fswebcam -> "Timed out waiting for frame"

They work perfect during daytime, perfect during nighttime, but at sunrise/sunset they throw errors for about 20mins. Maybe there's a connection to autofocus, but since all my cams are attached to powered hubs, it's unlikely that it's a power issue caused by autofocus current draw in my case.

In your case: Have you measured the USB voltage? Just to make sure, as unlikely it may be.

Hi roger_
I run an HD USB Webcam on a DIR-505 using trunk ok with mjpg_streamer 1280X960 at 5 fps.

BusyBox v1.19.4 (2014-04-22 12:35:18 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
-----------------------------------------------------
BARRIER BREAKER (Bleeding Edge, r40569)
-----------------------------------------------------

root@OpenWrt:~# lsusb
Bus 001 Device 002: ID 0ac8:3420 Z-Star Microelectronics Corp. Venus USB2.0 Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have had issues with it on other routers that did not have enough "oomph" and was current starved for HD webcams.
This happened when the auto focus would draw more current.

I tried powered hubs but had issues with bandwidth limits.

(Last edited by johnisaacson on 27 Jun 2014, 22:14)

My experiences with achievable resolution of webcams on OpenWRT r40502:

It often crashes when I'm not around, so it might be due to lighting levels. I discovered by accident that I could trigger it by putting a finger in front of the lens, which triggers the autofocus. I may have to figure out how to disable that and see if it's more stable.

I haven't measured the USB voltage, but it might be worthwhile to hook up a scope sometime. My next plan is to either get a powered hub or try another camera, but I really hope it's a software issue.

Interesting -- so you agree that it could be an autofocus related issue? As I mentioned, I tried adding a capacitor in case it was a current draw issue, but that didn't help.

I don't really need autofocus, so it wouldn't be a big issue if I had to disable it.

Interesting. I actually have a Logitech Pro 9000 and LifeCam Cinema running on two other WR703N's, and they're pretty stable (and good quality). In the future I'll just avoid autofocus cams.

Hi roger_,
It is possibly a current issue, the camera I have is the autofocus  "voice-coil" type. I do not know of the current draw
but USB ports on routers are current starved in my opinion.
A capacitor should help but there are many variables.

tmo26's table seems comprehensive. I have not tried the range and types of cameras listed.

I use the web cam up to10 fps on the single USB port and no issues. No powered hub. It is a wireless link several hundred feet from my server through at least two repeated hops.

I store a picture on a server taken every 20 seconds. Each picture is roughly 300 KB in size.

I just tried disabling autofocus with mjpg-streamer, but it doesn't seem to work.

When I uncheck the option from the web interface it doesn't seem to stick (it's checked again when I reload) and doing it manually via this URL doesn't work either:

/?action=command&id=10094860&value=0&dest=0&plugin=0&group=1

Tried it on two different cameras (Logitech 525 and LifeCam Cinema) with no success.

(Last edited by roger_ on 3 Jul 2014, 21:46)

The most reliable solution: Desolder the AF drive. It's very simple, since it has only two connections.

Hi roger_/tmo26
I find it interesting in the wiki http://wiki.openwrt.org/toh/tp-link/tl-wr703n that it makes special mention of the
unit having issues with to much power draw. Particular note of this is made in the "Power consumption" section.
I wonder if the power supply wall unit has been checked. Perhaps it is suffering from current drag.
A simple volt meter check (with webcam connected) over time will point to a heat issue. If the voltage drops much below 5 volts then maybe the webcam does not like it. It could also affect the router 3.3 volt regulator.

Placing a capacitor will only help on a momentary current surge but if the power supply can not deliver the goods (current starved) then perhaps it could be the problem.

If you have another supply with more current capacity may be a quick way to check.

Something that works for a time and then fails after a couple of hours can be an indication of a heat related problem.

A crude test is to place a finger on the regulator under various loads and see how hot it is (very crude).
Or a can of cold spray on the components and see if it recovers.

In my experience electronic components and heat over extended periods are not compatible.

Just some ideas....

Did you tried to disable autofocus with v4l2-ctl or with uvcdynctrl.

I got a Logitech c270 and I disable/enable auto_exposure from cmd line with v4l2-ctl but before I have to execute uvcdynctrl to get the values visible to v4l2-ctl I turn off the led too with that command.

Regards
Luis

Those are some good ideas, I should probably try another power supply and see if it makes a difference. I did notice that this router wouldn't work reliably with a hard drive that my other WR703N supported fine, so you might be on to something.

Thanks, will try. Any idea where I can get uvcdynctrl? I don't see any package for it?

I don't know, you should ask for the compiled package to where you use to download your bins, I compile my own bin so I select from "make menuconfig".

I don't know why and I didn't investigate any further, but to see the "extended" options with v4l2-clt I have to run uvcdynctrl I've discover this by playing with the command, I saw "extended" options after test the uvcdyn... command.

So:

First try with

v4l2-ctl -l

to check for the autofocus option, if none is found you should try with:

uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml

(check your own path for the xml file) (this file is not up-to-date) (you can add your own registers values to the xml file for your cam model) (I have not need to edit the file even my cam model is not listed inside the file) (but it works for me).

after that re-check again with:

v4l2-ctl -l

to check for an autofocus option, if you found, you can set by something like this:

v4l2-ctl -c exposure_auto=3   (replace exposure_auto and value with your owns for autofocus)

Is the way I use to disable cam led and disable autoexposure (on time ranges).
Remember that everytime you restart the system you need to execute uvcdyn.... command before the call to v4l2ctl for that "extended" options.

sorry for my english

Luis

I haven't been able to get uvcdynctrl working on my device, but I think I fixed the issue.

Yesterday I connected the camera via an unpowered USB 2.0 hub (a cheap one off eBay) and so far it's been running for 12 hours with no crashes. I may be celebrating too quickly, but I'm optimistic so far.

I still think the original problem was related to autofocus, but I have no idea why buffering the camera via a hub seems to have helped. Maybe it's a kernel issue after all.

Would you mind making your Makefile public, e.g. by submitting a patch?

I'd be interested in this!

tmo23, roger:

A few days ago I recompiled everything after a svn update and I figure out that I miss uvcdynctrl, so I found that I was able to compile because I've downloaded a patch from patchworks to get the package.

This is the patch, just download to a proper folder:

http://patchwork.openwrt.org/patch/3792/

Sorry that I didn't told you before.

Luis

Thanks Luis. I got that patch merged, so binaries should show up on the OpenWRT servers soon.

This is because the usb had capacitors on the power lines, usually, capacitors store energy and this energy is used by the usb camera when it need more power from power line, without the capacitors, when the cams need more power (voice coil activated) it demands from the power line, this power cames from the usb connector, the power line of the usb connector in this router is controlled by a transistor, this transtistor is inside the hub (gpio 8 (tplink mr-3020) to control power for the usb port), the transistor is not perfect, so, if you demand more power from the transistor its resistance increments, so the voltage drops, the same may occur up to the power source, the good designs should use capacitors in the power lines near the chips or the devices that most power take, in this case, the problem must be the camera, it should have a capacitor with enough capacitance to provide a good power for the coil. Is a basic in electronics, but my english is soooo poor that I can't explain better.

Regards
Luis

(Last edited by LuisR on 1 Aug 2014, 14:59)

That's what I thought, so I actually soldered on a 100 uF capacitor across the power lines of the USB header. Sadly it didn't help