Difference between revisions of "Known problems"
| Line 23: | Line 23: | ||
hello -c d 3 | 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. | 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. | ||
| + | |||
| + | --[[User:Andrey.filippov|Andrey.filippov]] 19:10, 21 November 2005 (CST) | ||
Revision as of 17:10, 21 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)
