[Elphel-support] channel switching and exposure question

[Andrey Filippov]

Andreas,

If you use current software it is better to avoid using direct register
access to the 10359 FPGA using i2c read/write - you may use camvs GUI or
parsedit.php (directly or from autocampars.php). Drivers keep track of the
register shadows and modify their values using higher level paramers. When
you write registers with direct i2c writes, the actula register values will
not match the driver shadows, so the software most likely fail.

 Exposure sittengs - you may try parsedit.php - last value is how many
frames ahead the parameter is changed, there is a "test" mode for testing
latencies - it starts compressor, sets new parameters according to the
specified values and delays,  then stops compressor (so the buffer will not
be overwritten). You can open link with "last 9 images" - it will show you
the frames themselves, frame numbers and parameters.

Default parameter change is 3 frames ahead (one more than the longest
hardware latency - sesnort exposure time) - you may try changing it in
parsedit.php (last column), the sesnor has it's own latencies, and it is 2
for exposure (at least in sensor free-running mode) In that mode sesnor does
not let you chnage exposure each frame -0 it should be the same for at least
2 frames. In triggered mode (the only supported for 10359 board in the
driver) you can change exposure each frame, but there is still latency in
the sensor.

You can get to the latencies at
http://192.168.0.9/tuneseq.php?mode=latency- page (you can get ther
from the camera home page), it allows you to
view/change pipeline latencies for different actions during runtime, but the
latencies are believed to be set correctly (according to the actual
hardware). The latencies depend on the current trigger mode - if you switch
to "TRIG=4" (default for 10359 board) and refresh that page - values will be
different.

Andrey


Is there a way to set the exposure for the next frame?
>

No, sensor has 2 frames latency from i2c command received to the new data
output (if you use TRIG=0). In TRIG=4 (default and strongly recommended for
multi-sensor operation) it is one sensor frame latency. Each driver
(/dev/framepars) write includes parameter specifying either absolute or
relative frame number (absolute is useful to avoid uncertainty caused by
frame sync interrupt taking place while your application is executing code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100905/7163931e/attachment-0002.html>