Difference between revisions of "RTC"

From ElphelWiki
Jump to: navigation, search
(Timestamps)
(Timestamps)
Line 39: Line 39:
 
0 - timestampos off
 
0 - timestampos off
  
1 - timestamps are embedded into the upper-left corner of the image. Currently while demosaic algorithm uses 3x3 pixel interpolation first row and first column
+
1 - timestamps are embedded into the upper-left corner of the image. Currently while demosaic algorithm uses 3x3 pixel interpolation first row and first column are skipped. When the 5x5 conversion will be implemented the time stamp will be in the very corner (or maybe not to simplify reversing de-mosaic processing of the timestamp data).
    are skipped. When the 5x5 conversion will be implemented the time stamp will be in the very corner (or maybe not to simplify reversing de-mosaic processing of the timestamp data).
 
  
 
2 - timestamps are embedded after the sensor data in each column (sensor row), this mode is needed for the photo-finish application.
 
2 - timestamps are embedded after the sensor data in each column (sensor row), this mode is needed for the photo-finish application.

Revision as of 22:23, 21 September 2005

Real Time Clock

Absolute date/time in Elphel cameras

Elphel model 333 (as well as older ones) camera does not have a hardware clock with battery backup so each time it wakes up it is January, 1 1970. We made a simple hack to automatically setup date and time - camera web interface uses javascript code that sends host computer time (UTC) to the camera as one parameters for image acquisitions (originally the purpose was just to make all URLs unique to prevent caching of images by the browser).

Timekeeping in Elphel cameras

After the date/time are set cameras use internal CPU timer (baased on the master crystal oscillator) to maintain current time. There are several restrictions of these method:

1 - the precision of the clock is limited to that of the crystal oscillator. Actually the clock IC allows fine-tune oscillator varying capacitance load but it is not really easy to calculate required change to apply;

2 - FPGA, that performs most of the data processing in the camera does not have direct access to the CPU timer. Precise timer in the FPGA might simplify image synchronization and timestamping with no uncertainty of the software responce.

FPGA Timer

Now FPGA code has a replacement RTC with digitally adjustable rate (so it is possible to calculate and apply correction). The timer data consists of 32-bit seconds counter and 20 bit counter from 0 to 999999 (0xf423f) of microseconds, provisions are made to freeze 52=32+20 bits during reading so seconds are not incremented between to reads.

Timer is be programmed by writing data to the FPGA registers Writing to X313_WA_RTC_CORR (0x46) sets the 16-bit (signed) correction value (positive - make clock faster, negative - slower). Correction work in the following way. Each 0.5 microsecond (10*period of 20MHz master crystal oscillator) 24-bit accumulator is incremented by 0x800000+correction_value (0x7f8000 to 0x807fff) and the carry out increments microsecond counter - that usually happens each other time.

Writing to X313_WA_RTC_USEC (0x44) presets microsecond counter. Actually it is applied to the counter only together with the write value to the next register - X313_WA_RTC_SEC (0x45) - seconds.

Output data needs to be latched in the registers before read out can be performed. It is accomplished by writing to X313_WA_RTC_LATCH (0x47).

After that microseconds (20 bits) are available for reading at X313_RA_RTC_USEC (0x44), and seconds - at X313_RA_RTC_SEC (0x45).

Currently timer is not generating any interrupts but it is not difficult to add such functionality if needed.

Timestamps

One of the main functions of the FPGA timer is to provide timestamping of the images, it especially important in Photo-finish mode. In that mode camera is rotated 90 degrees and the image consits of two pixel wide columns (two - for color filter pattern)acquired at several thousand fps. And each should be timestamped.

Time stamps currently consist of 52 binary values (20 - microseconds and 32 - seconds) and completely black (for 0) or white (for 1) pixels are embedded into the image. Because of the FPGA compressor architecture this embedding takes place before color de-mosaic algorithm is applied so the pixel values of the timestamps are distorted, but it is rather easy to apply image filter to restore original values.

Each timestamp is split into 2 lines. First line has bits 5..0 (LSBs) of seconds and all 20 bits of microseconds, the second - bits 31..6 of seconds (MSB first).

Time stamping embeds binary values of the 52 bits (20 - microseconds and 32 - seconds) to the image as white/black pixels (the output values are distorted by the bayer->YCbCr 4:2:0 conversion so some processing is needed to restore the bits). First line has bits 5..0 of seconds and all 20 bits of microseconds, the second - bits 31..6 of seconds (MSB first).

Writing data to X313_WA_TIMESTAMP (0x48) selects one of the two timestamping modes (or disables timestamping):

0 - timestampos off

1 - timestamps are embedded into the upper-left corner of the image. Currently while demosaic algorithm uses 3x3 pixel interpolation first row and first column are skipped. When the 5x5 conversion will be implemented the time stamp will be in the very corner (or maybe not to simplify reversing de-mosaic processing of the timestamp data).

2 - timestamps are embedded after the sensor data in each column (sensor row), this mode is needed for the photo-finish application.