Difference between revisions of "Adjusting sensor clock phase"
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 |
Revision as of 23:03, 16 October 2007
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