Difference between revisions of "Adjusting sensor clock phase"

Revision as of 23:32, 16 October 2007

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.

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 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 control parameter has index 513 (0x201), you may read the current value (see Driver_parameters) with the following command:

http://<camera_ip>:81/senspars.php?cmd=read&addr=0x201

Default value is:

513(0x201):327620(0x4ffc4)

That is: no 90-degree shifts, fine shift is -60 steps.

Supposing you would like to set new phase shift to +32:

1: Write data to the driver "write" parameter

http://<camera_ip>:81/senspars.php?cmd=write&addr=0x201&data=0x40020

You may verify it by reading

http://<camera_ip>:81/senspars.php?cmd=read&addr=0x601

it will return

1537(0x601):262176(0x40020)

2. Driver "looks" at the phase shift value only there is a request to change the sensor clock frequency. Even as we do not need to change it, we write 96000000 (frequnecy in Hz) to the appropriate register - it will be replaced with zero (no changes required) when applied:

http://<camera_ip>:81/senspars.php?cmd=write&addr=14&data=96000000

3. Now - apply changes:

http://<camera_ip>:81/senspars.php?cmd=write&addr=0&data=3

That will cause sensor to be reset and then re-programmed to the current parameters (current settings are erased during reset). The sensor has to be reset after any clock changes, as it "assumes" that clock is stable after the reset signal (input pin or software command) is released. Experimentally we've found that the Micron 5MPix sensor can be confused if the clock frequency changes and in 50% instances develops a 1 pixel delay in the pixel output (effectively getting wrong colors). Strangely that applies only to the real sensor data, simulated test patters in the sensor are not influenced by this effect.