Difference between revisions of "RTC"

Latest revision as of 07:23, 3 October 2010

RTC | 10331 | 10332 | 10334

Real Time Clock

Absolute date/time in Elphel cameras

Elphel model NC353L (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. (NC353L-369* models have cmos clock). 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). The frame size will not increase in that mode - timestamp will be embedded over the part of an image.

2 - timestamps are embedded after the sensor data in each column (sensor row), this mode is needed for the photo-finish application. The image size will be increased by 28 pixels tgo accomodate the timestamps.

There is a way to specify timestamp mode with the http request by adding &ts=<0..2> to the image URL, you may als..

Timestamping frame data

In 353 cameras now - starting from the fpga revision 0333100f (it can be read as "fpcf -r 13" from telnet session) the timestamp data is embedded into each frame transferred from the FPGA to the system memory. It comes right before the frame length data as 8-byte sequence - 4 bytes of seconds and then 4 of microseconds.

This data is also embedded as EXIF into the file header.

Free Software and Open Hardware. Elphel, Inc., 2005-2006