strange results with PVCAM library

[dzac]

Dear All !

I know this is not the best forum for this question..

I wanted to find out how mans milisecs passes between frames i can acquire from my CoolSnap HQ camera using PVCAM sdk library.

I use circular buffer mode (pl_exp_start_cont()). My circular buffer is 3x frame size but it doesnt seem to matter. The exposure mode is TIMED_MODE and exposure time is 100 milisecs.

The important part of C code:

pl_exp_start_cont(hCam, buffer, buffer_size );

while (i != SEQNUM) {
      while( pl_exp_check_cont_status( hCam, &status, &not_needed, &not_needed ) && (status != READOUT_COMPLETE && status !=            RADOUT_FAILED) );

if ( pl_exp_get_oldest_frame( hCam, &address )) {
   ftime(&tp[i]);
   i++;
   pl_exp_unlock_oldest_frame( hCam );
}

}

After this, i print the milisecs part of tp[i] array to see how many milisecs passed between the calls to ftime in the loop.

For a SEQNUM of 10, the result is something like this:

0. 640
1. 734 DIFF: 94
2. 828 DIFF: 94
3. 937 DIFF: 109
4. 31 DIFF: 94
5. 125 DIFF: 94
6. 234 DIFF: 109
7. 328 DIFF: 94
8. 421 DIFF: 93
9. 531 DIFF: 110

Now the exposure time is 100 milisecs ! First of all how can 94 milisecs pass between two frames that arrive ? Secondly, why does it vary ?

I tried to use pl_set_param with PARAM_SHTR_OPEN_MODE NO_CHANGE and OPEN_NEVER to rule the shutter out.

Is the code itself appropriate for this measurement ?

Im such a noob please help me 🙂

Cheers, Laszlo

[Neil.Pate]

Without really examining your code, my initial thoughts is that you cannot really rely on a non RTOS to give you accurate timing info. You didn't mention theOS but I assume its Windows?

My hunch is that if you average your times you will get 100ms over a longish period of time.

The camera is probably trying to provide you with snaps every 100ms, but Windows needs some time do process your function calls and to do everything else it does behind the scenes. It varies probably because of this very reason.

<disclaimer> I have no experience with the PVCAM sdk or really any of the vision stuff, but this kind of behaviour is quite common, especially with analogue input measurments that seem to jitter a bit if you try and rely on the OS timestamp.

Message Edited by nrp on 09-04-2009 11:16 AM

[dzac]

Thank you for your fast reply. Yes, it is windows. Having 107 ms between frames would be understandable with 100 ms exp time. What I dont understand at all is that how can 94 ms pass between two frames. It's ok that windows spends CPU time doing other stuff, resulting in random times but they should all be >=100 ms, shouldn't they ?

The code is realy simple it doesnt even read/process the input data from camera. The time is being recorded between every succesful return from the pvcam library call to pl_check_cont_status meaning the camera has a _NEW_ frame for me.

Thanks, Laszlo

[Neil.Pate]

My point was that if one frame takes 107 ms, then the next one has to be in less than 100 ms otherwise the average will be greater than 100 ms (and you hardware would then be working incorrectly). That is how these kinds of hardware buffers work. It fills up at a certain rate (usually quite accurately as its probably based on some internal clock, apart from the OS clock), the OS services the queue at a different rate, and there will be a bit of jitter between the two.

Its not like one image is actually taking 97 ms to obtain, its just that apparently its taking that long due to your timing routine. If you had a Real-time OS, or something with zero overhead you would probably find the images coming it at much closer to 100 ms each.

Try doing an average of the time for 100 frames and see what you get, my hunch is that you will get close to your ideal rate.

[Neil.Pate]

The bottom line is you cannot rely on a non-RTOS for millisecond accuracy.

[dzac]

thank you. i understand.