Lead Time acquisition

[lroussel]

Hello,

I use genika software since several years to do star occultations by astéroides and I have start to do some tests to pass to sharpcap.
I have difficulties to found a configuration that work well because of variation of the acquisition lead time.
To measure this lead time I register the blinking of a pps led and the issue is that I can have 1 or 2 time exposure of lags and the consequence is that the acquisition lead time change with time exposure.
With genika I don't have this issue, I have a lead time of only few ms and is it constant when I change time exposure.
I guess that this lag is due to to use of the buffer camera but I'm not sure.

Is there a way with Sharpcap to be sure to don't use the camera buffer?

An other thing I have found is that there is a lag of 1 exposure time between .ser or .Fits, for example if I have a lag of 2 exposure time with ser, I have only 1 exposure time with Fits.

For information I use ZWO1600 and 533, I have join an example of configuration I use.

Lionel

[admin]

Hi,

I would certainly expect some lag - with the ZWO cameras, SharpCap attaches a timestamp to the frame when the frame data is received from the ZWO SDK. To get that far, the frame has gone through the following stages

* Captured by the sensor
* Transferred over USB (while the next frame is being captured by the sensor)
* Put together from the USB packets by the ZWO SDK
* Handed over to SharpCap.

The time taken for transfer over USB may well be the biggest contributor here (although who knows what the ZWO SDK does internally - does it buffer a frame?). If the maximum FPS you can achieve with a particular resolution is 100fps (even with really short exposures) then you know that the USB transfer time is about 10ms, since that is most likely what is limiting the frame rate to 100fps.

There are no settings on the ZWO SDK (or in SharpCap) to control buffering when running in video mode.

On the SER/FITS difference, I think that the issue is that the SER file is using the timestamp when the frame was received from the SDK, whereas FITS uses that timestamp less the exposure (to try to correct for the length of the frame). Once upon a time the timestamp that SER uses was the only timing data and it looks like I have not revisited that code since to update it to use the slightly better estimate. I should fix that.

I wonder if the Genika software is estimating and correcting for the USB transfer time? I can't see how else it could work.

cheers,

Robin

[lroussel]

Hi,

Thanks for the answers

For the issue with .ser I have it for sharpcap 3.2, 4.0 and 4.1, on 3.1 it's OK (same timestamp than fits)

Genika is now an old sofware that is no longer updated by is author (Frederic Jabet)

Cheers

Lionel

[admin]

Hi Lionel,

if I had to bet then I would think that in 3.1 the FITS timestamp is the end-of-frame timestamp too (the same way that SER is now). In other words, back then they both had the same issue, but at least were consistent

I have just corrected the code in SER saving for SharpCap 4.1 so that the estimated start time of the frame will be used in SER files if available, which should put FITS and SER back in sync.

cheers,

Robin

[lroussel]

Hi Robin,

Thanks a lot I will testing that as soon as possible.

Cheers

Lionel