[Elphel-support] Sensor Synchronization and Memory

Tue Jan 9 08:09:38 PST 2018

Hello Andrey,

thanks for your help. The issue with the trigger is currently on hold 
and I concentrate on reading out the raw sensor data from the video memory.

> One of the drivers provide raw access to the whole video memory as to 
> the large continuous  file. Other driver provides access to the actual 
> captured frame data.
Do you mean the x393_videomem.c driver? It seems this driver does not 
have the functionality implemented 
(https://git.elphel.com/Elphel/linux-elphel/blob/master/src/drivers/elphel/x393_videomem.c#L417). 

> In memory the frame width is rounded up, so there are gaps between 
> sensor pixel data.
This means that every scanline, independent of the width, is in a 8192 
byte region and the next scanline starts at the next 8192 byte boundary. 
Also the two frames for each sensor are also consecutive in the video 
memory without any gap, besides the round-up to 8192 byte. Is this correct?

Kind regards,

Fabjan Sukalia

Am 2017-12-15 um 17:57 schrieb Elphel Support:
> Hello Fabian,
>
> The sensors used in 393 have 2 major operational modes - free running 
> and triggered (there are mode details in 
> https://blog.elphel.com/2016/10/using-a-flash-with-a-cmos-image-sensor-ers-and-grr-modes/ 
> and in sensor datasheets). In free running mode the maximal frame rate 
> does not depend on exposure time (exposure can be up to the full frame 
> period). In the triggered mode (from the sensor "point of view", so it 
> does not matter if the trigger is received over the cable or generated 
> by the FPGA timer) exposure and readout can not be overlapped, so the 
> maximal frame rate is limited to 1/(T_readout + T_exposure). That 
> means that the trigger can be missed if exposure is set too high (for 
> example by the autoexposure daemon). Please describe what trigger 
> problems did you have so we can try to reproduce them.
>
> If your exposure time  is short compared to readout time, you just 
> need to slightly increase the frame period (so it will accommodate 
> both T_readout and T_exposure) and either use manual exposure or 
> specify maximal exposure time in autoexposure settings.
>
> If your exposure time is high (not enough light) it is possible to try 
> the following trick.
> 1) Run camera in triggered mode (FPS < 1/(T_readout+T_exposure)
> 2) Make sure the parameters that define the frame rate in free running 
> mode are the same for all the participating sensors.
> 3) Limit or set exposure time so it will never exceed frame period in 
> free running mode
> 4) Simultaneously (using broadcast mask) switch all sensors to the 
> free running mode
>
> Sensors should stay in sync as they use the same source clock and all 
> other parameters are the same.
>
> As for uncompressed data - it should be possible (it is tested with 
> Python test_mcntrl.py ) as there is DMA-based bridge between the video 
> memory and the system memory. There are drivers ported from the 353 
> camera that provide access to this memory, but we did not use them and 
> need to check operation.
> One of the drivers provide raw access to the whole video memory as to 
> the large continuous  file. Other driver provides access to the actual 
> captured frame data. In memory the frame width is rounded up, so there 
> are gaps between sensor pixel data.
>
> Next thing depends on 8/16 bpp modes. In normal JPEG/JP4 modes the 
> data in the video memory is 8bpp (after the gamma conversion), and so 
> it is possible to simultaneously get both compressed and uncompressed 
> output. In 16 bpp mode (with 12 bit sensor data is shifted left by 3 
> bits, so different sensors use full range of positive short int). In 
> that mode it is not possible to simultaneously get compressed and raw 
> data.
>
> Video memory buffering can be programmed to use variable number of 
> frames for each channel, by default it is set to 2, working as a 
> Ping-pong buffer. When using compressed output the operation of the 
> data acquisition channel (writing video memory in scan-line order) and 
> reading data to compressors (20x20 overlapping tiles in JPEG mode, 
> non-overlapping 16x16 in JP4 mode) are synchronized in the FPGA (read 
> channel waits for the sufficient lines to be acquired for the next row 
> of tiles), but that is not so for the raw data read from the video 
> memory. FPGA provides 8 individual interrupts for the imaging 
> subsystem - 4 channels for the sensor acquisition channels (frame sync 
> signals also internally advance command sequencers described here - 
> https://blog.elphel.com/2016/09/nc393-development-progress-and-the-future-plans/) 
> and 4 compressor_done interrupts. And there are userland ways to wait 
> fro the next frame (e.g. from the PHP extension - 
> https://wiki.elphel.com/wiki/PHP_in_Elphel_cameras).
>
> We will check (update if needed) the drivers that provide access to 
> the video memory.
>
> Andrey
>
>
>
>
> ---- On Fri, 15 Dec 2017 05:48:27 -0800 *Fabjan Sukalia 
> <fabjan.sukalia at qinematiq.com>* wrote ----
>
>     Dear Elphel-Team,
>
>     currently I'm working with the synchronization and readout of the
>     sensor on the 393. My first goal is to synchronize two or more
>     sensors so that the pictures are taken at the exact same time. To
>     my understanding the internal trigger could be used for this
>     purpose but I'm unsure if this produces a stable video stream with
>     the maximum frame rate. Currently I'm unable to confirm this as
>     the firmware that is provided by my colleagues has issues with the
>     trigger. Therefore I'm asking you if the internal trigger can
>     synchronize the sensors and still provide a video stream with the
>     highest frame rate possible. Also the maximal exposure time would
>     be 16 ms for a 60 fps video.
>
>     My second task is to access the uncompressed data of the sensors.
>     These data reside on the memory chip dedicated to the FPGA-part of
>     the Zynq. Is there some example code on how to access the
>     uncompressed data from a user-space program?
>
>     Thanks in advance.
>
>     Kind regards,
>
>     Fabjan Sukalia
>
>     -- 
>     qinematiq GmbH
>     ---------------------------------------------------------
>     Fabjan Sukalia        Millergasse 21/5      A - 1060 Vienna
>     Tel: +43 1 595 11 21-11           Mobil: +43 664 926 9277
>     www.qinematiq.com <http://www.qinematiq.com>
>
>     _______________________________________________
>     Support-list mailing list
>     Support-list at support.elphel.com
>     <mailto:Support-list at support.elphel.com>
>     http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
>
>
>
>

-- 
qinematiq GmbH
---------------------------------------------------------
Fabjan Sukalia       Millergasse 21/5       A-1060 Vienna
www.qinematiq.com

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