Known problems - Revision history

Andrey.filippov: Reverted edit of TzeNj6, changed back to last version by Andrey.filippov

2007-04-11T04:04:31Z

Reverted edit of TzeNj6, changed back to last version by Andrey.filippov

TzeNj6 at 19:25, 10 April 2007

2007-04-10T19:25:38Z

Andrey.filippov: /* Half fps ! */

2005-11-22T09:58:41Z

‎Half fps !

Andrey.filippov: /* Half fps ! */

2005-11-22T09:57:02Z

‎Half fps !

Andrey.filippov: /* Half fps ! */

2005-11-22T08:10:29Z

‎Half fps !

Andrey.filippov at 01:10, 22 November 2005

2005-11-22T01:10:55Z

Andrey.filippov at 23:02, 21 November 2005

2005-11-21T23:02:10Z

New page

== 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.

← Older revision		Revision as of 04:04, 11 April 2007
Line 26:		Line 26:
	== Half fps ! ==		== Half fps ! ==

−	gone in 6.4.12 of elphel333mjpeg [https://sourceforge.net/project/showfiles.php?group_id=105686	+	gone in 6.4.12 of elphel333mjpeg [https://sourceforge.net/project/showfiles.php?group_id=105686&package_id=151844&release_id=372883]!
		+	--[[User:Andrey.filippov\|Andrey.filippov]] 03:57, 22 November 2005 (CST)

← Older revision		Revision as of 19:25, 10 April 2007
Line 26:		Line 26:
	== Half fps ! ==		== Half fps ! ==

−	gone in 6.4.12 of elphel333mjpeg [https://sourceforge.net/project/showfiles.php?group_id=105686~~&package_id=151844&release_id=372883]!~~	+	gone in 6.4.12 of elphel333mjpeg [https://sourceforge.net/project/showfiles.php?group_id=105686
−	~~--[[User:Andrey.filippov\|Andrey.filippov]] 03:57, 22 November 2005 (CST)~~

@@ Line 26: / Line 26: @@
 == Half fps ! ==
-gone!
+gone in 6.4.12 of elphel333mjpeg [https://sourceforge.net/project/showfiles.php?group_id=105686&package_id=151844&release_id=372883]!
 --[[User:Andrey.filippov|Andrey.filippov]] 03:57, 22 November 2005 (CST)

@@ Line 26: / Line 26: @@
 == 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).
+gone!
+--[[User:Andrey.filippov|Andrey.filippov]] 03:57, 22 November 2005 (CST)

← Older revision		Revision as of 08:10, 22 November 2005
Line 31:		Line 31:

	--[[User:Andrey.filippov\|Andrey.filippov]] 19:10, 21 November 2005 (CST)		--[[User:Andrey.filippov\|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.
		+
		+	--[[User:Andrey.filippov\|Andrey.filippov]] 02:10, 22 November 2005 (CST)

← Older revision		Revision as of 01:10, 22 November 2005
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)