On Wed, 2005-02-09 at 15:57, Mark McClelland wrote: > I just noticed this in one of the Windows driver files (2610.set): > > ==================== > ;************* Frame Rate = 40fps > > > > HKR, %2610Vid800RGB24%\FrameRate0, CameraSetting, 1, 11,80,ff > HKR, %2610Vid800RGB24%\FrameRate0, AlternateSetting, 0x10001, 0 > HKR, %2610Vid800RGB24%\FrameRate0, FrameRate, 0x10001, 40000 > HKR, %2610Vid800RGB24%\FrameRate0, QualityLevel, 0x10001, 1 > HKR, %2610Vid800RGB24%\FrameRate0, RawData, 0x10001, 1 > HKR, %2610Vid800RGB24%\FrameRate0, RawFrameLength, 0x10001, 480000 > HKR, %2610Vid800RGB24%\FrameRate0, OneLine, 0x10001, 1 > > > > ;@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > ; > ;HKR, %2610Vid800RGB24%\FrameRate2, CameraSetting, 1, 11,83,ff > ;HKR, %2610Vid800RGB24%\FrameRate2, AlternateSetting, 0x10001, 0 > ;HKR, %2610Vid800RGB24%\FrameRate2, FrameRate, 0x10001, 15000 > ;HKR, %2610Vid800RGB24%\FrameRate2, QualityLevel, 0x10001, 1 > ;HKR, %2610Vid800RGB24%\FrameRate2, RawData, 0x10001, 1 > ;HKR, %2610Vid800RGB24%\FrameRate2, RawFrameLength, 0x10001, 480256 > ;HKR, %2610Vid800RGB24%\FrameRate2, OneLine, 0x10001, 1 > =================== > > Apparently, OmniVision ran into the same problem, and at one point > resorted to increasing the amount of data transferred per frame size by > 256 bytes. I'm guessing they did this by bumping the sensor window size > to 800x601 (the max window height is 606 according to the datasheet). >
Interesting point, but 800x601 would generate 800 bytes more data, not 256. I notice also that they seem to think that the frame-rate in this mode is 15fps, but the "CameraSetting" of 0x83 to register 0x11 in the sensor actually runs the sensor at 10fps as far as I know [0x80 is 40fps, 0x81 is 20fps, 0x82 is 13.3fps and 0x83 would be 10fps]. I am suspicious that some of the .set file stuff seems to be dead cruft left over from editing .set files for completely different cameras! > Fortunately, running the sensor at 40 FPS also seems to fix the problem, > assuming that the FrameRate0 settings above actually work. The FX2, at > least with this firmware, is extremely sensitive to the incoming data > rate. The FX2 datasheet lists some timing constraints that must be met, > otherwise the chip will stop working. If the IFCLK (pixel clock) rate is > too high, you will simply get a corrupted frame due to overflow of the > internal FIFOs, but if it is too low, the 200ns minimum IFCLK period > will be exceeded and the chip will freeze up. > I'm avoiding all that (in theory) by trying to run 1600x1200 at 10fps or 800x600 at 40fps. The data rate in those two modes is identical, both at the FX2 end and at the USB software in linux. Ditto 800x600 mode at 16 bits per pixel of course, though that's marginally different from the FX2's point of view as it has to read two FIFOs. But the data rate over USB is the same. > 20 FPS should be well within that limitation at 800x600x1, but there may > be other constraints that are near the limit. A comparison of the 2610 > timing diagrams with the FX2 "Externally Sourced IFCLK" tables might > reveal something. A bug in the firmware's programming of the FIFO or > GPIF engines might be to blame as well. > > The "601 line hack" might be a reasonable solution if you need a longer > exposure time than 1/40 sec. > If you need to diddle with the exposure timing, you can pad the line sync pulse with extra pixel clock intervals, plus pad the frame sync pulse with extra fake blank lines. Interestingly, as soon as you slow the 1600x1200 camera down much below 4.4fps, the FX2 seems to fall over, rather like you suggest. That indeed would seem to be firmware trouble, but not really do do with what I'm seeing here, which according to USB bus analysis really does seem to be down to linux choosing to ignore the endpoint after seeing a 256byte bulk packet. > Best regards, Nice to hear from you again, Mark. Steve. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
