SharpCap Forums

Hello,
I use SharpCap for occultations, and I have to make quite long exposure time for faint stars. I use the inserted timestamp, but I would like to know if the timestamp inserted is the beginning, middle or end of exposures?? Of course logicaly it should be middle of exposure, but...
Thanks
Michel Meunier
http://team-janus.astrosurf.com/index.p ... janus-sud/

Hi Michel,

Sadly the answer to this question is 'it depends'. Assuming that you are using a normal camera (not a QHY GPS camera), then the timestamp is usually the time at which SharpCap received the frame from the camera, which will be a point in time after the end of the frame.

Unfortunately SharpCap has no idea how long it takes for the image to be transferred from the camera to the computer and then handed over to SharpCap from the camera manufacturers code. Typically four USB3 CMOS cameras, the delay is small (much less than a second). For CCD cameras or USB2 CMOS cameras being run at long exposures the download time to the computer may be several seconds.

The exception to the rule about the timestamp being after the end of the frame is if you are capturing to FITS format in a recent version of SharpCap 3.2. In those circumstances, SharpCap will attempt to estimate the start time of the frame by subtracting the exposure duration from the time that it receives the frame and putting that value in the DATE-OBS header of the FITS files. This change can be found in SharpCap version 3.2.6131 and newer versions.

Hope this helps, Robin

Hi Robin
thanks for the precisions brought 2 years ago to Michel. I also use Sharpcap for occultations, but I use .ser files. We have to bring the more corrections as possible (some msec) to obtain the very precise time where the occultation occurs. So we have to evaluate each "systemics errors" generating a difference between the exact time of occultation and the time written in the file, for each frame. To evaluate the acquisition delay, we use GPS system with a LED blinking at very precise intervals. With ShapCap, we generate a .SER file. This file is analyse and the difference between GPS time and frame time is mesured. So it's very usefull to know what correspond to the written time. Is there the same reference as for .FITS (time where the data from camera arrive to SharpCap)? What is usefull else to know?
Thanks for your help, and bravo for SharpCap which is exceptionnal!
Cheers, Dominique

Hi Dominique,

I just checked the code for SER file writing...

If you have a camera with onboard GPS that is active then the GPS start time for the frame becomes the SER frame timestamp.
For all other cameras, the time that SharpCap receives the frame is written as the SER frame timestap, which is after transfer to the PC and any processing in the camera SDK.

As long as you are on Windows 8 or newer, SharpCap uses the high resolution time API (GetSystemTimePreciseAsFileTime), which should give a stable precision timer as far as is possible - see https://docs.microsoft.com/en-us/window ... asfiletime

cheers,

Robin

Hi,

Have a look: http://www.iota-es.de/SC-Timestamps_01.pdf

Cheers

Christian

A lot of thanks to both of you, Robin and Christian for your reactivity and yours so accurate informations!
I have now all the answers needed. I'll share these informations with 2 of my friends, also invested in occultations (Pierre et Jean-Baptiste).
Cheers, Dominique

Hi Robin,

I am doing GPS flash timing for occultation recordings and I am seeing some artefacts which I think could be caused by time aliasing or rounding when calculating acquisition delays to ms precision. This is the method I am using if you are interested:

http://www.nocturno.fr/acquisitiondelay ... 220915.pdf

I would like to know what rounding or other truncation there is on the millisecond timestamps in SER and FITS files. If, say, the windows time is HH:MM:SS.000000 how is the HH::MM:SS.000 timestamp generated?

Kind Regards
Michael

Hi Michael,

if the camera itself is non-GPS then the timestamp that is associated with each frame is obtained from Windows by calling the GetSystemTimePreciseAsFileTime function shortly after the frame is delivered to SharpCap by the camera SDK (see https://learn.microsoft.com/en-us/windo ... asfiletime).

Now, while that function should provide a timestamp that is precise (not accurate necessarily) to well beyond millisecond levels, the actual timing of the frame arriving at SharpCap may be biased towards certain intervals, depending on how the camera SDK (and potentially the code in SharpCap) waits for a new frame to become available. I can't give much information on how it happens inside the camera SDK, but if you let me know what camera you are using then I can review the code in SharpCap to let you know if I think that might be affecting the situation.

cheers,

Robin

Thanks so much Robin. I'm using the asi462mm.

I'm measuring acquisition delays of ~5-20 ms for typical exposure times of 10-160 ms, so understanding how the millisecond timestamp is formed will be helpful.

For occultations commonly used CMOS cameras are the asi174mm GPS or non-GPS and asi290mm. Newer cameras such as the asi462mm, asi220mm, asi432mm will I think become increasingly used. Also the QHY versions using the same sensors, and Player one mono cameras will become more common.

Using analog video for occultations is IMO on the way out - IOTA has just re-released their video time inserter after it being unavailable for about 2 years, and a new RunCam analog video output camera which I think is based on a color sensor. Suitable analog video cameras are increasingly hard to find (basically only used for expensive industrial cameras and POV cameras for drone racing) and are not keeping up with modern CMOS sensors which are getting surprisingly close to your hypothetical 'perfect' sensor. My asi462mm has >80% average QE, read noise < 1 e, very low dark current and very little amp glow - amazing! With my asi462mm the optimal sub-exposure according to your method is ~0.5s at f3.3 under bortle 5. It is a lot of fun for EAA!

Michael

Hello Michael,

asi174mm GPS ? really exist ?

Jean-Francois