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.
_______________________________________________ Support-list mailing list Supportfirstname.lastname@example.org http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com