TimeStamp

[jtagg]

You can test that value and try acquiring at different rates. You can then see whether it is still correct, or whether that constant isn't anything special.

If it still works across rates, then the value can be used to generate correct timestamps.

Hope this helps.

[ratus]

Found !!!! I have to take into account the GevTimestampTickfrequency value.
Thanks for your help....
I still have one more question (see next reply in a few minutes).

[ratus]

Last question.
It looks like the time between frames is not constant. 

On a total of about 10000 acquired frames, 50 frames (0.5%) have a larger delay.
Is this normal?

[jtagg]

How big is this extra delay?

[ratus]

Sorry, I forgot to attach the file

[jtagg]

There is always a certain jitter when working with software, more especially a standard OS like windows, where timing cannot be guaranteed to be correct and can easily vary by several milliseconds. This does not surprise me.

[ratus]

Even so when you do a buffer acquisition and ask to retrieve the exact next buffer ?

[jtagg]

The driver software is still software and so subject to the timing of the operating system.

[ratus]

Ok ... This looks strange.
Anyway thanks for your great support.

[BlueCheese]

For a GigE Vision camera on IMAQdx there are potentially two timestamps available. There is a *relative* timestamp sent by the camera with each image corresponding to the acquisition time. This is optional for the camera to support and is represented by the IMAQdxTimestampLow/High data. This timestamp is not subject to any jitter of the PC, OS, or driver, only the camera's internal clock. Usually this is a multi-Mhz clock (125Mhz on many cameras) and the accuracy is quite good. If you are triggering the camera at a constant rate and seeing gaps in these relative timestamps, I suggest verifying the buffer numbers being grabbed. You may be skipping buffers and seeing gaps that way.

The second timestamp is an *absolute* timestamp that is recorded by the system when the image is finished being received. This one is subject to whatever timing jitter is present on the OS/system as well as jitter caused by the network or lost packets. This is represented by the IMAQdxReceiveTimestampLow/High data and must be enabled by the user via an attribute for it to be present in the image.

Hope this clears things up,
Eric