Difference between revisions of "Known problems"

Revision as of 00:10, 22 November 2005

Camera in Use

There probably could be different reasons why camera might get stuck and nothing but reboot helps. These can happen because of paricular camera hardware malfunction, FPGA code bugs, software bugs of combination of the above.

ccam.cgi lock file

ccam.cgi creates lock file to prevent attemt to simultaneously control the camera. And as we know these lock files remain sometimes when they shouldn't. It is possible to ignore lock file by adding "*" to the "opt=" parameter in the URL - open "new" image (it will show "Camera in Use" image), add "*" after "opt=" in the address line and try to load the new URL. Sometimes it helps.

Sensor stuck in wrong state

I just noticed that after some manipulations sensor can get to the wrong state and need to be reset before it can operate again. It is known at least for MT9T001 sensors with rev. 1621 (you may read rev number with

hello -IR ba 0

over telnet). The easiest way to reproduce that problem for me was to click "preview" button after changing exposure - about 10-20 times could do the job (maybe it should be fast enough - I did not try to vary all the parameters).

In that state

hello -z

will return

Cam-sequencer state - 7,  count= 2

That means that no frame sync pulses were ever received from the sensor after it was last programmed.

What to do about it? Two things: - find what exactly sensor does not like and try to avoid it and - add some code to recover if the sensor is stuck

It is possible to reset sensor with turning on the "mrst" signal with

hello -c d 3

and then turning it off again with the same command (it toggles the signal state):

hello -c d 3

After that the sensor should come back to life and "hello -z" will return "Cam-sequencer state - 7, count= ffffffff" The problem can later be that the sensor registers are reset to defaults that do not match the driver shadows, but that can be dealt with in software. For now - just try to acquire image with different frame size that last time.

Half fps !

Just noticed - all MJPEG versions of 333 code (at least from v 6.3.4) skip each other frame, so the actual fps is just 1/2 of that of the sensor. Theora version works fine, I also remember fixing that for the 313 cameras. And so far nobody (including me) noticed that (or at least told me).

I'll work full speed on this issue, it is most likely caused by missing interrupts.

--Andrey.filippov 19:10, 21 November 2005 (CST) Found it, will fix shortly. It was because only 2 extra lines were added to frame to accomodate 18x18tiles for 16x16 MCUs (how it was in 313), not 4 for 20x20 tiles. So compressor was waiting for the last 2 lines that came only with the new frame - too late.

So I'll test the fixed code, but still sensor driver need a complete rebuild - it is too messy by now after many modifications fro new sensors and cameras. So now period calculation is not correct when binning is used (and not all the data is in the Micron datasheet as actually binning works for up to 8, not just 3 as they write. We also need to make a cleaner driver as more sensors aree coming soon - and they will have different controls.

--Andrey.filippov 02:10, 22 November 2005 (CST)