Adjusting sensor clock phase - Revision history

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2022-05-01T22:06:14Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 22:06, 1 May 2022
Line 16:		Line 16:
	=== Software interface for adjusting the sensor clock phase (firmware 8.0.x) ===		=== Software interface for adjusting the sensor clock phase (firmware 8.0.x) ===
	Open the following URL in the browser (replace 192.168.0.9 if camera has different IP):		Open the following URL in the browser (replace 192.168.0.9 if camera has different IP):
	192.168.0.9/parsedit.php?embed=0.25&title=Parameters+for+groups:+phase&SENSOR_PHASE&SENSOR_REGS7&SENSOR_REGS7__0310&SENSOR_REGS7__0307&WOI_HEIGHT&WB_EN&THIS_FRAME
			[http://192.168.0.9/parsedit.php?embed=0.25&title=Parameters+for+groups:+phase&SENSOR_PHASE&SENSOR_REGS7&SENSOR_REGS7__0310&SENSOR_REGS7__0307&WOI_HEIGHT&WB_EN&THIS_FRAME http://192.168.0.9/parsedit.php?embed=0.25&title=Parameters+for+groups:+phase&SENSOR_PHASE&SENSOR_REGS7&SENSOR_REGS7__0310&SENSOR_REGS7__0307&WOI_HEIGHT&WB_EN&THIS_FRAME]

	That page combines several controls:		That page combines several controls:

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2022-05-01T21:58:41Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 21:58, 1 May 2022
Line 16:		Line 16:
	=== Software interface for adjusting the sensor clock phase (firmware 8.0.x) ===		=== Software interface for adjusting the sensor clock phase (firmware 8.0.x) ===
	Open the following URL in the browser (replace 192.168.0.9 if camera has different IP):		Open the following URL in the browser (replace 192.168.0.9 if camera has different IP):
	~~http://~~192.168.0.9/parsedit.php?embed=0.15&title=Parameters+for+groups:+phase&SENSOR_PHASE&SENSOR_REGS7&SENSOR_REGS7__0310&SENSOR_REGS7__0307&WOI_HEIGHT&~~refresh~~		192.168.0.9/parsedit.php?embed=0.25&title=Parameters+for+groups:+phase&SENSOR_PHASE&SENSOR_REGS7&SENSOR_REGS7__0310&SENSOR_REGS7__0307&WOI_HEIGHT&WB_EN&THIS_FRAME

	That page combines several controls:		That page combines several controls:

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2009-09-02T02:57:37Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 02:57, 2 September 2009
Line 35:		Line 35:
	If at some point camera will stop responding to http requests (actually requests to PHP scripts) you may restart PHP by issuing		If at some point camera will stop responding to http requests (actually requests to PHP scripts) you may restart PHP by issuing
	killall lighttpd		killall lighttpd
	from the telnet session (it kills the web server that will be restarted together with the instances of PHP)		from the telnet session - it kills the web server that will be restarted together with the instances of PHP.

	The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)		The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2009-09-02T02:56:50Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 02:56, 2 September 2009
Line 32:		Line 32:
	#monitor image quality - look for horizontal color stripes		#monitor image quality - look for horizontal color stripes
	#repeat with different phase value		#repeat with different phase value

			If at some point camera will stop responding to http requests (actually requests to PHP scripts) you may restart PHP by issuing
			killall lighttpd
			from the telnet session (it kills the web server that will be restarted together with the instances of PHP)

	The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)		The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2009-09-02T02:40:40Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 02:40, 2 September 2009
Line 26:		Line 26:

	When you change phase and press "apply" the image would not reflect the new settings (changing phase requires complete sensor reset and the regular image acquisition sequence is aborted), so the following sequence is recommended:		When you change phase and press "apply" the image would not reflect the new settings (changing phase requires complete sensor reset and the regular image acquisition sequence is aborted), so the following sequence is recommended:
	#~~change phase~~ value		#modify SENSOR_PHASE value
	#press "apply"		#press "apply"
	#change WOI_HEIGHT (alternate 0x790 and 0x780 for the full frame)		#change WOI_HEIGHT (alternate between 0x790 and 0x780 for the full frame)
	#press "apply"		#press "apply"
	#monitor image quality - look for horizontal color stripes		#monitor image quality - look for horizontal color stripes

Andrey.filippov: /* Software interface for adjusting the sensor clock phase (firmware 8.0.x) */

2009-09-02T02:39:49Z

Software interface for adjusting the sensor clock phase (firmware 8.0.x)

← Older revision		Revision as of 02:39, 2 September 2009
Line 24:		Line 24:
	*SENSOR_REGS7__0310 (bits 12:10) is the drive strength of all other outputs - pixel data, horizontal and vertical sync		*SENSOR_REGS7__0310 (bits 12:10) is the drive strength of all other outputs - pixel data, horizontal and vertical sync
	*WOI_HEIGHT - window if interest height is not related to sensor phase adjustment, but it can be used to restore system (sensor to FPGA) synchronization after it is lost when adjusting sensor phase (that involves restarting the sensor). Just reduce/increase it by 0x10 and press "refresh" button - that should restore the "broken" image caused by losing system sync.		*WOI_HEIGHT - window if interest height is not related to sensor phase adjustment, but it can be used to restore system (sensor to FPGA) synchronization after it is lost when adjusting sensor phase (that involves restarting the sensor). Just reduce/increase it by 0x10 and press "refresh" button - that should restore the "broken" image caused by losing system sync.

			When you change phase and press "apply" the image would not reflect the new settings (changing phase requires complete sensor reset and the regular image acquisition sequence is aborted), so the following sequence is recommended:
			#change phase value
			#press "apply"
			#change WOI_HEIGHT (alternate 0x790 and 0x780 for the full frame)
			#press "apply"
			#monitor image quality - look for horizontal color stripes
			#repeat with different phase value

	The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)		The phase default settings in the camera are optimized for a short cable (30 to 50mm), for longer cable it may need adjustment. You may also need to replace /etc/x353.bit file with the one that is generated with higher drive strength of the clock line from the FPGA to the sensor (that will also cause increase of the radiated EMI from the camera)

Andrey.filippov: /* Software interface fro adjusting the sensor clock phase */

2009-09-02T02:26:56Z

Software interface fro adjusting the sensor clock phase

@@ Line 14: / Line 14: @@
 Sensor phase control in the camera is achieved with one of the FPGA on-chip DCM (digital clock management) blocks by combining the fine phase adjustment with 4-to-1 multiplexor switching between on of the four outputs shifted by 90 degrees. The fine shift is not precisely known, for these chips it is specified in the 20-40 ps/step, while guaranteed number of phase shift steps (for 96MHz clock) is +/- 140 (so more than +/- 90 degrees in the worst case.
-=== Software interface fro adjusting the sensor clock phase ===
+=== Software interface for adjusting the sensor clock phase (firmware 8.0.x) ===
 The phase adjustment value passed to the driver is split into two parts - lower 16 bits represent (signed short) fine shift in steps (20..40ps), next 2 bits - 90-degrees additional shift, higher bits are "don't care". In default configuration bit 18 (0x40000) is set, because only non-zero values change the phase, so 0x40000 means "set 90-degree phase to 0, fine phase - to zero", while 0x0 means "no phase changes"

Andrey.filippov at 07:37, 17 October 2007

2007-10-17T07:37:33Z

← Older revision		Revision as of 07:37, 17 October 2007
Line 1:		Line 1:
			=== Elphel cameras architecture - separate computer and sensor boards ===
	Elphel cameras are designed so they can support multiple different sensors, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.		Elphel cameras are designed so they can support multiple different sensors, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.

	The inter-board connection is made of the flex cables (that are available in different length) provide freedom in mutual orientation of the main boards and the sensor front end, allowing the smaller sensor board to get into the tight spaces. But that 30-conductor cable has not enough conductors to make nice transmission lines - there is not enough of the return wires, number of ground+power lines is much less than the number of signal ones, but that is not a big issue for most camera applications where the cable is really short - less than 2 inches (50mm) long, but still the signals (in 5MPix sensor the output 12-bit data has a 96 mpix/sec, the clock lines run at 96MHz both directions) are used with reduced drive strength to reduce the EMI. Fortunately both FPGA and the sensor allow control over the drive strength. With the low output currents on the pins, it takes some time to recharge the parasitic capacitance of the cable wires, and the signals look far from "digital" rectangular shape - it takes most of the pixel period to just transition from "0" to "1" or back from "1" to "0", so the data on ~~teh~~ other end should be sampled at a precise moment during each pixel period.		=== Inter-board cable ===
			The inter-board connection is made of the flex cables (that are available in different length) provide freedom in mutual orientation of the main boards and the sensor front end, allowing the smaller sensor board to get into the tight spaces. But that 30-conductor cable has not enough conductors to make nice transmission lines - there is not enough of the return wires, number of ground+power lines is much less than the number of signal ones, but that is not a big issue for most camera applications where the cable is really short - less than 2 inches (50mm) long, but still the signals (in 5MPix sensor the output 12-bit data has a 96 mpix/sec, the clock lines run at 96MHz both directions) are used with reduced drive strength to reduce the EMI. Fortunately both FPGA and the sensor allow control over the drive strength. With the low output currents on the pins, it takes some time to recharge the parasitic capacitance of the cable wires, and the signals look far from "digital" rectangular shape - it takes most of the pixel period to just transition from "0" to "1" or back from "1" to "0", so the data on the other end should be sampled at a precise moment during each pixel period.

			=== Phase shift of the sensor clock input ===
	In the camera it is achieved by adding controlled phase shift between the clock that synchronizes operation of the sensor-related portion of the FPGA and the clock signal that is sent to the sensor. The sensor output signals have certain delay from that clock (unfortunately in 5MPix sensor that delay is very different for the pixel data and sync signals), so by varying the phase of a clock to sensor it is possible to adjust phase of the sensor data with respect to the FPGA pixel clock. The sensor pixel output clock is not used - it is more convenient when the FPGA clock does not depend on the state of the sensor. But that sensor output clock is connected to the FPGA and is sampled at different phases of the FPGA clock - that data can (and will) be used for the automatic phase adjustment, but current software does not support that yet.		In the camera it is achieved by adding controlled phase shift between the clock that synchronizes operation of the sensor-related portion of the FPGA and the clock signal that is sent to the sensor. The sensor output signals have certain delay from that clock (unfortunately in 5MPix sensor that delay is very different for the pixel data and sync signals), so by varying the phase of a clock to sensor it is possible to adjust phase of the sensor data with respect to the FPGA pixel clock. The sensor pixel output clock is not used - it is more convenient when the FPGA clock does not depend on the state of the sensor. But that sensor output clock is connected to the FPGA and is sampled at different phases of the FPGA clock - that data can (and will) be used for the automatic phase adjustment, but current software does not support that yet.

			=== Effect of different cable lengths ===
	For the standard camera configuration the phase shift is programmed as a predefined constant, but that does not work when the cable length differs from the original one. If you try the camera with different cable length you may see image that looks like monochrome or purple - if the pixels are sampled at wrong time, red and green (also green and blue) pixels can swap, you may see horizontal lines when the sample moment is close to the pixel-to-pixel transition - in some lines pixels were sampled correctly, in some - colors are swapped (and remember - each pixel is represented by individual 12 bit lines, that can have slightly different delays to the clock). For some reasonable length cables (tested with 8" / 200mm) it is possible to re-adjust the phase shift, sample pixels in the middle of the pixel window and so restore the nice images.		For the standard camera configuration the phase shift is programmed as a predefined constant, but that does not work when the cable length differs from the original one. If you try the camera with different cable length you may see image that looks like monochrome or purple - if the pixels are sampled at wrong time, red and green (also green and blue) pixels can swap, you may see horizontal lines when the sample moment is close to the pixel-to-pixel transition - in some lines pixels were sampled correctly, in some - colors are swapped (and remember - each pixel is represented by individual 12 bit lines, that can have slightly different delays to the clock). For some reasonable length cables (tested with 8" / 200mm) it is possible to re-adjust the phase shift, sample pixels in the middle of the pixel window and so restore the nice images.

			=== On-chip DCM (Digital Clock Management) for sensor clock phase adjustment ===
	Sensor phase control in the camera is achieved with one of the FPGA on-chip DCM (digital clock management) blocks by combining the fine phase adjustment with 4-to-1 multiplexor switching between on of the four outputs shifted by 90 degrees. The fine shift is not precisely known, for these chips it is specified in the 20-40 ps/step, while guaranteed number of phase shift steps (for 96MHz clock) is +/- 140 (so more than +/- 90 degrees in the worst case.		Sensor phase control in the camera is achieved with one of the FPGA on-chip DCM (digital clock management) blocks by combining the fine phase adjustment with 4-to-1 multiplexor switching between on of the four outputs shifted by 90 degrees. The fine shift is not precisely known, for these chips it is specified in the 20-40 ps/step, while guaranteed number of phase shift steps (for 96MHz clock) is +/- 140 (so more than +/- 90 degrees in the worst case.

			=== Software interface fro adjusting the sensor clock phase ===
	The phase adjustment value passed to the driver is split into two parts - lower 16 bits represent (signed short) fine shift in steps (20..40ps), next 2 bits - 90-degrees additional shift, higher bits are "don't care". In default configuration bit 18 (0x40000) is set, because only non-zero values change the phase, so 0x40000 means "set 90-degree phase to 0, fine phase - to zero", while 0x0 means "no phase changes"		The phase adjustment value passed to the driver is split into two parts - lower 16 bits represent (signed short) fine shift in steps (20..40ps), next 2 bits - 90-degrees additional shift, higher bits are "don't care". In default configuration bit 18 (0x40000) is set, because only non-zero values change the phase, so 0x40000 means "set 90-degree phase to 0, fine phase - to zero", while 0x0 means "no phase changes"

Andrey.filippov at 07:32, 17 October 2007

2007-10-17T07:32:15Z

@@ Line 1: / Line 1: @@
-Elphel cameras are designed so they can support multiple different sensor, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.
+Elphel cameras are designed so they can support multiple different sensors, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.
 The inter-board connection is made of the flex cables (that are available in different length) provide freedom in mutual orientation of the main boards and the sensor front end, allowing the smaller sensor board to get into the tight spaces. But that 30-conductor cable has not enough conductors to make nice transmission lines - there is not enough of the return wires, number of ground+power lines is much less than the number of signal ones, but that is not a big issue for most camera applications where the cable is really short - less than 2 inches (50mm) long, but still the signals (in 5MPix sensor the output 12-bit data has a 96 mpix/sec, the clock lines run at 96MHz both directions) are used with reduced drive strength to reduce the EMI. Fortunately both FPGA and the sensor allow control over the drive strength. With the low output currents on the pins, it takes some time to recharge the parasitic capacitance of the cable wires, and the signals look far from "digital" rectangular shape - it takes most of the pixel period to just transition from "0" to "1" or back from "1" to "0", so the data on teh other end should be sampled at a precise moment during each pixel period.
@@ Line 9: / Line 9: @@
 Sensor phase control in the camera is achieved with one of the FPGA on-chip DCM (digital clock management) blocks by combining the fine phase adjustment with 4-to-1 multiplexor switching between on of the four outputs shifted by 90 degrees. The fine shift is not precisely known, for these chips it is specified in the 20-40 ps/step, while guaranteed number of phase shift steps (for 96MHz clock) is +/- 140 (so more than +/- 90 degrees in the worst case.
-The phase adjustment value passed to the driver is split into two parts - lower 16 bits
+The phase adjustment value passed to the driver is split into two parts - lower 16 bits represent (signed short) fine shift in steps (20..40ps), next 2 bits - 90-degrees additional shift, higher bits are "don't care". In default configuration bit 18 (0x40000) is set, because only non-zero values change the phase, so 0x40000 means "set 90-degree phase to 0, fine phase - to zero", while 0x0 means "no phase changes"

Andrey.filippov at 07:03, 17 October 2007

2007-10-17T07:03:27Z

← Older revision		Revision as of 07:03, 17 October 2007
Line 1:		Line 1:
	Elphel cameras are designed so they can support multiple different sensor, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.		Elphel cameras are designed so they can support multiple different sensor, including those that were not available when the particular camera model was first released. That is possible, because the camera functionality is split into the sensor-independent computer (see [[10353]]) and the sensor front end. This board is very simple for the CMOS images sensors, like [[10338]] - basically it includes just the image sensor itself, connector for the cable to the camera main board and the power conditioning circuitry. In other cameras (like Model 363) the high resolution CCD-based sensor front end is much more complex ([[10347]]+[[10342]]), but they all interface the main board through the 30-conductor flex cable that on the [[10353]] side is connected directly to the FPGA pins (all but power supply/ ground pins). That makes the interface universal, as functions of the FPGA pins can be changed with just a new code, no hardware changes are needed.

			The inter-board connection is made of the flex cables (that are available in different length) provide freedom in mutual orientation of the main boards and the sensor front end, allowing the smaller sensor board to get into the tight spaces. But that 30-conductor cable has not enough conductors to make nice transmission lines - there is not enough of the return wires, number of ground+power lines is much less than the number of signal ones, but that is not a big issue for most camera applications where the cable is really short - less than 2 inches (50mm) long, but still the signals (in 5MPix sensor the output 12-bit data has a 96 mpix/sec, the clock lines run at 96MHz both directions) are used with reduced drive strength to reduce the EMI. Fortunately both FPGA and the sensor allow control over the drive strength. With the low output currents on the pins, it takes some time to recharge the parasitic capacitance of the cable wires, and the signals look far from "digital" rectangular shape - it takes most of the pixel period to just transition from "0" to "1" or back from "1" to "0", so the data on teh other end should be sampled at a precise moment during each pixel period.

			In the camera it is achieved by adding controlled phase shift between the clock that synchronizes operation of the sensor-related portion of the FPGA and the clock signal that is sent to the sensor. The sensor output signals have certain delay from that clock (unfortunately in 5MPix sensor that delay is very different for the pixel data and sync signals), so by varying the phase of a clock to sensor it is possible to adjust phase of the sensor data with respect to the FPGA pixel clock. The sensor pixel output clock is not used - it is more convenient when the FPGA clock does not depend on the state of the sensor. But that sensor output clock is connected to the FPGA and is sampled at different phases of the FPGA clock - that data can (and will) be used for the automatic phase adjustment, but current software does not support that yet.

			For the standard camera configuration the phase shift is programmed as a predefined constant, but that does not work when the cable length differs from the original one. If you try the camera with different cable length you may see image that looks like monochrome or purple - if the pixels are sampled at wrong time, red and green (also green and blue) pixels can swap, you may see horizontal lines when the sample moment is close to the pixel-to-pixel transition - in some lines pixels were sampled correctly, in some - colors are swapped (and remember - each pixel is represented by individual 12 bit lines, that can have slightly different delays to the clock). For some reasonable length cables (tested with 8" / 200mm) it is possible to re-adjust the phase shift, sample pixels in the middle of the pixel window and so restore the nice images.

			Sensor phase control in the camera is achieved with one of the FPGA on-chip DCM (digital clock management) blocks by combining the fine phase adjustment with 4-to-1 multiplexor switching between on of the four outputs shifted by 90 degrees. The fine shift is not precisely known, for these chips it is specified in the 20-40 ps/step, while guaranteed number of phase shift steps (for 96MHz clock) is +/- 140 (so more than +/- 90 degrees in the worst case.

			The phase adjustment value passed to the driver is split into two parts - lower 16 bits