[Elphel-support] Problems to detect timestamps

[support-list]

Jennifer,

In our records I found that your cameras all have 10369 I/O boards, ordered specifically for synchronization of the cameras so I suppose you or others in your team  know how to use them. 

Cameras should be placed in triggered mode, where they performs as two independent devices: one just generates periodic trigger pulses (with attached timestamps), and the other (the camera itself) waits for the trigger and then initiates frame acquisition sequence (so if individual cameras have different exposures, the _beginning_ of each exposure will match, not the center). The synchronization cable wiring defines the "master" - output pair of wires on its connector are soldered to all input pairs in parallel (including input on the master itself) - that means that all the cameras can be programmed identically as "masters" - outputs from all but the real "master" will be just not used.

The electronic rolling shutter sensors have two running (in scanline order) pixel pointers - erase pointer and readout pointer, and the delay between the erase pointer and the readout one define exposure time. In free running mode (not synchronized) the pointers can be in different frames - while the readout is in frame #0, the erase one may already be in frame #1 (next one ), the longest exposure time in that mode is just the frame period - as soon as pixel is read out, it is erased and exposure starts for the next frame.

In triggered mode this is not possible, so when trigger arrives the sensor starts erasing line by line, starting from the first line. Exposure time later the readout pointer starts, and erasing of the next frame can not start until the full frame is read out. This makes the minimal frame period (the value programmed to the FPGA sync pulses generator) equal to the sum of the exposure time (or maximal anticipated exposure time if you use the default autoexposure mode).

Sensor readout time can be calculated using sensor datasheet available for download on On Semiconductor web site. Pixel clock is 96MHz (96MPix/s). This time includes not just pixel readout, but also vertical (rather small) and horizontal (large) blanking;

 FPGA processes 53.33Mpix/s in JPEG mode and 80 MPix/s in JP4 mode (we recommend this mode that provides you with raw Bayer mosaic data), and FPGA has the full frame period to compress image - and there is no "blanking", so for the FPGA the minimal synchronization period is just slightly above total number of fixels divided by FPGA pixel rate (53.3M and 80M). JP4 mode is always faster than the sensor, JPEG is slower for large frames, but smaller for the smaller ones.

Other frame rate limiting factor is the network bandwidth and while sensor readout and FPGA processing do not depend on compression quality, the bandwidth sure does. Sending images over the 100Mbps Ethernet provides approximately 10MB/s of data. If you are trying to push as much data as you can, you can adjust image quality by acquiring a test image of the scene, looking at the file size - the maximal frame rate will be just 10MB/s divided by the image size.

10 MB/s is achieved if the network can handle 100Mbps from each camera. As you have 16 of them you will need to split them in 2 groups (if you are using GigE switches). On the host PC you need to run either multi-threaded or just run one script (that reads from the imgsrv) per camera simultaneously.

This will provide you with the sets of images precisely timestamped, each channel will have images with exactly the same timestamp value so you should not have any problems matching images from different channels.

There are multiple programs available to process JP4 format (an perform client-side demosaic) - in C, Java, and even JavaScript code that converts images using just HTML5 canvas.

Andrey


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20160110/ed74ceba/attachment-0002.html>