[Elphel-support] Understanding camera-sensor interface

Mon May 11 10:06:35 PDT 2015

Hello colleagues!

Simultaneously to approach of 3D measuring which is used stereo-matching 
we are also working on another method of 3D measuring based on optical 
triangulation. For this application we try to apply 353 camera too. The 
main idea of this method is in determination of the object shape due to 
transformation of the structured light in a case when light search and 
observation point are in different points:

There are several constraints which that must be taken into consideration:
1. speed of scanning must be about 50 shapes per second;
2. scanning system must work at the outdoor conditions with strong 
lighting of the object by direct sun light.
3. power of the structured lightning search (probably NIR laser type) 
must be limited to satisfy safety requirements for human eyes.

So the main challenge here is to increase signal/noise ratio that means 
increasing amount of structured light energy scattered from measured 
object and decreasing light energy of the sun and others unwanted 
sources. To do this it is possible to make narrow-band spectral 
filtering of the lighting search as well as minimize the time of 
exposure and to use synchronous high power pulse lightning. To do 
spectral filtering I have got narrow band interference filters at 850 
and 900 nm. Experimental investigation of these filters shown the 
bandwidth of half power is about 50 nm. I intend to replace in the 
camera your stock short pass IR blocking filter by this NIR narrow-band 
filter. Bitwise, I have measured your stock short-pass filter which is 
installed in the camera as well, if you interested in this data I will 
send you.

Now is about time-domain processing. Actually, this is my first 
experience with hardware of digital camera. At the begin of my 
investigation I thought that all pixels in sensor start/stop exposure at 
same moment. This suggestion makes possible to do one short pulse of 
lightning search, which exposures all pixels at the sensor at same 
moment. If we apply as such lightning the high power ultrashort pulse 
search (I am going to use Osram laser diodes SPLLL85 or SPLLL90 with 
20..50 watt of optical power and pulse width about 50 ns) and setup as 
short as possible pixel's exposure time then we can increase 
signal/noise ration very strong. Unfortunately, in real MT9P001 sensor 
this idea does not work because of shifting of the exposure time of rows 
in sensor, so it is needed to do independent flashes of light for 
neighboring rows. As I see a solving of the problem may be in use of 
global reset release mode of the sensor, but as I know in this mode 
every pixel continues exposure till the moment readout of it.

If we consider WOI with size of 100 x 2000 px then total read out time 
is more than 10 ns x 200.000 = 2 ms. That is mean that exposure time of 
lasts rows will be as high as 2ms. This is not good because these lasts 
rows will accept a lot of unwanted light. Anyway I can not to find how 
to set up this mode (GRR) in the camera. Is it possible to setup GRR 
mode using this script 
http://192.168.1.9/index.php?site=autocampars.php? If not - how can I do 
it?

There is a way to reduce total readout time by skipping of readout some 
rows, for my application it is possible. For examples, we can readout 2 
lines and skip 14 lines, this leads to decreasing maximum total exposure 
time in GRR mode. I found that MT9P001 has such possibility:

As I see to setup row skip mode it is needed to modify  Row_Skip bits in 
R34 register.

Is possible to alter sensor registers directly via PHP API of the 
camera? I tried to found some PHP routines to do this but have not found 
any. Please explain how I can do so.

At this moment I am experimenting on synchronization between lightning 
and row's exposure in ESR sensor mode with FPGA timing (TRIG=4). I guess 
that for my application WOI with height about 2000 px and row length 
about 100-150 px is enough. I tried setup various sizes of WOI but some 
things are not clear for me. At datasheet it is pointed out that:

- I consider it that region of interested of the sensor may be directly 
specified, and there is no any extra data will be readout. For example, 
if we consider WOI with WOI_WIDTH = 128 and WOI_HEIGHT = 32  then 
readout time of 1 row is:

that leads to Trow = 10,79 us.

I setup 1 us exposure time:

Actual signal timings correspond to calculations above:

where: Yellow signal is TRIG_OUT (J15 connector) and Green signal is LV 
signal from sensor. Totally there are 32 periods of LV that corresponds 
to WOI_HEIGHT = 32. More detailed observation of the Line_valid signal:

Here it is clear visible that period of LV is about 10 us. My question 
is - how determine actual time of start exposure of every row? Values of 
EXPOS is 1 us. What is the real exposure time and how to determine and 
measure it? I read that actual exposure time is divisible by Trow, is it 
correct? And if we setup 1us exposure time then real exposure time is 
about 10 us for this case, correct?

Another questions: as I know so big interval between leading edges of 
Line_Valid signal (about 10 us) is due to horizontal blanking. Is it 
possible to minimize this interval?

What do you think about such application of the 353 camera at all? Is 
there some compatible with MT9P001 sensors with true simultaneous 
exposure of all pixels?

Thank you in advance!
Best regards, Anatoly.

-- 
С уважением, Клещенков Анатолий.
г. Ростов-на-Дону
теп.: +7(863)275-95-05
e-mail: aktech at inbox.ru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jfiejbba.png
Type: image/png
Size: 404241 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acacjagj.png
Type: image/png
Size: 170367 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gjfhjibh.png
Type: image/png
Size: 39841 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgbdidjf.png
Type: image/png
Size: 67147 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dehiiabb.png
Type: image/png
Size: 38643 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ajhacjje.png
Type: image/png
Size: 35943 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfbeibgf.png
Type: image/png
Size: 13456 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eiaibcbf.png
Type: image/png
Size: 25489 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hgedihee.
Type: image/bmp
Size: 149814 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment.bmp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cgjgiijb.
Type: image/bmp
Size: 149814 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150511/132d1cf4/attachment-0001.bmp>