Known problems

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.