Re: [Itifg-tech] Camera readout using itifg 8.4

[Tim v. W. <T.I...@ph...>]

Hi Matthias,

On Apr 18, 2008, at 16:48 , M....@go... wrote:

> Perhaps You don't have specified the O_APPEND flag to open(2)!? You  
> can
> also set it later by fcntl(2). If this flag isn't set, only one and  
> the
> same buffer is filled all the time. Sorry, I have forget to mention  
> it.

Ah that worked for me, thanks. I noticed you used those flags in  
test_itifg, but it never occurred to me that those flags were that  
important.

Now that O_APPEND seems to influence the drivers behaviour quite a  
bit, are there other flags that are important? I see you also use  
O_SYNC which supposedly explicitly synchronizes the read/write calls  
in memory, blocking until the call is complete. Is this also necessary?

I also noticed by running test_itifg through strace and varying the  
size of the buffer (-n) and the number of frames captured (-t) that  
you do *not* use lseek(fd, +LONG_MAX, SEEK_END), but instead do  
something like lseek(fd, bufsize, SEEK_END). It appears that this  
gives new frames until 'bufsize' bytes are transferred, after which  
you restart the cycle by calling lseek(fd, bufsize, SEEK_END) again.  
How does this approach differ from lseek(fd, +LONG_MAX, SEEK_END), is  
there a lot of overhead in restarting such a cycle and in what  
situations would you recommend one of the two approaches?

Also, when I'm using +LONG_MAX to start capture, I notice that the  
values returned by SEEK_END and SEEK_CUR keep increasing with  
pagedsize every frame. Since the camera I'm using runs at about 1000  
fps, and pagedsize is 68 kb, this means that in about 31k frames,  
LONG_MAX bytes get transferred.

I notice this happens at frame 30839 for me, and the return value  
shifts back:
frame: 30835, seek_end returns: 2147172352, seek_cur returns: 2147172352
i: 30836, end: 2147241984, cur: 2147241984
i: 30837, end: 2147311616, cur: 2147311616
i: 30838, end: 2147381248, cur: 2147381248
i: 30839, end: 2147450880, cur: 2147450880
i: 30840, end: 1073778688, cur: 1073778688
i: 30841, end: 1073848320, cur: 1073848320
i: 30842, end: 1073917952, cur: 1073917952

while 2147450880/pagedsize == 32 768, 1073778688/pagedsize == 15  
420.7647, which is not an integer number. How does this influence the  
general operation of itifg and how should I take care of these events?

Also, is it correct that:
- the return value of lseek(fd, 0, SEEK_END) is the address where the  
next byte read from the grabber will be written, meaning that the  
newest byte in memory is located at the return value - 1?
- the return value of lseek(fd, 0, SEEK_CUR) is the address where the  
user needs to read next, i.e. the address up to which the user has  
processed data?
- the difference between the return values is the amount of new data  
waiting in the buffer for processing? In the test program this value  
is always equal to pagedsize, but will this increase to n*pagedsize if  
the program cannot keep up with the camera and the buffer starts  
filling up?

>
> No no, EXSYNC and PRI are two independed outputs at the PCDig's  
> connector.
> Most times the camera only needs one input: EXSYNC. As far as I  
> know, only
> Dalsa's line scan cameras needs additional PRI Signal.
>
> You don't see the 80ms readout not directy, You only see it  
> indirectly:
> 120ms - 40ms = 80ms.
> Means If You want 40ms Exposure and You know, that Your camera have a
> readout of 80ms, You can't go with Your cycle time below 40ms + 80ms =
> 120ms.
> Take care of a litte safety time of 1ms => 121ms.

Ok, so the 80ms is an empirical value, you know the readout time of  
the vossk-ccd1300b camera yourself. I've also found the dalsa camera  
manual now which makes things a bit clearer. I haven't tried  
triggering exposures myself yet, but it's something I'll try when I  
have time.

Again, thanks :)

Tim