Difference between revisions of "Programming 363"

Revision as of 00:26, 11 October 2007

Programming Model 363 Cameras/camera modules

This article reflects the current state of the software to operate Elphel model 363 camera, including synchronizing of multiple cameras. Not all the software is in the final state, but - anyway.

Sensor board control (10347)

CCD sensor front end in the model 363 camera consists of a sandwich of the two PCBs - 10347 - FPGA-based timing/interface module and 10342 - analog sensor front end. In addition to the 10342 board, 10347 controls optional mechanical shutters, it has interface connectors fro some 35-mm motorized lenses, opto-isloated I/O for synchronization and general purpose 5VDC output that can be used to turn on fan or drive other circuitry.

This board is controlled from the processor board ([10353]) through a 2-wire serial interface, there is init347.php (can be reached as http://<camera_ip>:81/init347.php) that sets initial values to the sensor registers (commented in the code), including main and mechanical shutter sequencers. This script is called automatically during camera initialization, it can be used as a sample for custom PHP applications to control the acquisition parameters, for manual changing parameters I would recommend copying it (or modified version) to RAM-disk based TMPFS (ftp to /var/html directory in the camera) - it will be availble as http://<camera_ip>:81/var/init347.php (or you may rename it as you wish, preserving .php extention, of course)

Process of acquiring images from the CCD image sensor is controlled by the sequencer with the program (manually assembled) in the register address space of 0x100..0x1ff (initialized by init347.php) ,the Verilog code of the sequencer that interprets this code is in the seq_cpu.v. Tricky part is that some loop count values (including exposure time) are embedded in the code and the absolute addresses inevitably change when the sequencer code is modified. These addresses are needed for the other scripts to change variable parameters (i.e. exposure), so we use the top sequencer addresses as a table of externally needed addresses, 0x1ff holding program address of exposure count, 0x1fe - delay between the start of additional mechanical shutter sequencer and the start of exposure. More entries may be added in the future (i.e. delay between exposure and readout start to give time for mechanical shutter to close and overall trigger delay)

Current version of init347.php looks for the mechanical shutter sequencer program (0x200-0x27f for odd/all exposures, 0x280-0x2ff - for even ones) and if it is empty - programs default sequence (will not change existent sequence). Mechanical shutter sequencer operates independently of the main one, it only starts at the moment defined by the main sequencer. There is a separate program mshutter.php that allows to edit the sequence(s) in a human-readable/writable form - the init347.php contains just codes for the shutter_seq.v - each word include the 8-bit output code for the shutter control board (10368) and duration that code should stay on the output.

Programming the CPU board 10353 to receive/compress images

This part of the code is not redesigned yet to support CCD imagers, it was intended for the CMOS sensors originally. So currently you may just use the ccam.cgi interface to acquire an image (the frame dimensions should match those specified for the sensor in init347.php or equivalents), some parameters currently have no effect (like "e=" - exposure time) - it will be fixed in the future, others are needed (JPEG compression quality, image size, bit width, color type (monochrome/color/jp4), gamma, color saturation. The following url should open the image and initialize 10353 board FPGA to acquire/compress images and place them into circbuf:

http://<camera_ip>:81/admin-bin/ccam.cgi?opt=*vhc&ww=4008&wh=2676&bit=8&iq=95&byr=0&gam=99&rscale=1&bscale=1&e=1

Acquiring images and transferring them to the host

After the FPGA is programmed to process the incoming sensor data you do not need to use ccam.cgi - only if any of the parameters above need to be changed, Later we'll develop new software to control acquisition process - most of the functionality can already be implemented in PHP, but several IOCTL-s (not PHP-friendly) are still required. Now the process of transferring images is separate from the image acquisition to the camera memory (a 19MB circular buffer circbuf). The acquired data can be asynchronously sent out as either individual JPEG images through imgsrv server or as RTP/RTSP MJPEG-ecoded stream (not sure if it still works with that large images, maybe a few fixes are needed)