Re: [libdc] usb dc1394 cameras and bandwidth

[David M. <dav...@gm...>]

Ed, sorry to resurrect this old thread but I have more to say on the subject
of corrupt images from Firefly MV USB cameras now!

Andrew Straw was recently having the same problem with some of his USB
Firefly MVs.  After helping him debug it, I discovered that Point Grey
released an updated firmware in the March/April time frame that solves this
problem.

The firmware bug is that sometimes when overflowing its internal FIFO, the
camera does not send a zero-length packet to resynchronize.  Version 1.3.3.0
or later of the Firefly MV firmware seems to correct this issue.

By the way, this also needs the kernel/libusb fixes that were committed some
time ago, but I imagine you've had those fixes for a while now.  Also, you
might still get single corrupt frames, but those can be detected with
dc1394_capture_is_frame_corrupt().

Regards,
David

On Wed, Mar 24, 2010 at 9:42 AM, Edwin Olson <eb...@um...> wrote:

> Hiya!
>
> I've been happily using USB firefly MVs and libdc1394 for some time now and
> recently hit some unexpected behavior when I abused the system.
>
> In particular, plugging three USB cameras into the same controller causes
> the frames for each camera to be horribly corrupted. (It looks like packets
> are being lost, and the resulting frames end up offset in the image. The
> effect is very similar to the other intermittent bug where the kernel
> doesn't cancel pending URBs correctly (or something like that).)
>
> Three cameras exceeds the total USB bandwidth available from a single
> controller, and so I didn't expect this to work well. However, the manner in
> which it failed was more spectacular than I'd imagined. Better behavior, in
> my mind, would be for the frame rate of each camera to be effectively
> reduced but for the frames themselves to be intact.
>
> The effect can be trivial reproduced with camview by running three
> instances with three firefly cameras plugged in simultaneously. Note that if
> the camera resolution is dropped to ~360x240, three cameras works fine since
> (I assume) the bandwidth requirements drop.
>
> I mention this because it seems like a bug is being exposed in this
> admittedly silly situation. But because it is so easy to reproduce, it might
> be worth fixing. (Who knows? Maybe this problem occasionally affects more
> reasonable situations?)
>
> Best,
>
> -Ed
>
> --
> Edwin Olson
> Assistant Professor, University of Michigan
> http://www.eecs.umich.edu/~ebolson
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mailing list for libdc1394-devel
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel
>
>