I’m new to this group and would like to ask about the time of each image acquired through SGP. I intend to use this software to carry out astrometric observations and would like to know whether the time stamp of the FITS header refers to the start, middle or end when the exposure was taken.
To astro-photographers this is a trivial question but to astrometrists this is crucial as differences could be made out even if there is an offset of a second or two. This is very visible for fast moving asteroids. Most software records the time for the start of the exposure, however I could not find anything about this on this forum or on the manual. Can someone please shed some light on this issue?
SGP is a very comprehensive package and for this reason I would like to start utilizing it for scientific imaging.
I would not use the data from the Windows file system, but instead would use the standard FITS headers DATE-LOC and DATE-OBS. Both of these times reflect the exact start of the integration (and not the time the file was written to disk). We never really considered adding it to the documentation since the FITS documentation states these fields indicate the start of the observation.
Please let us know if you have any other questions.
Where are you getting the time from Ken? It doesn’t seem to be coming from the LastExposureStartTime provided by the ASCOM camera driver.
If you are using the time when you send the StartExposure command this could be incorrect because the camera might take a short time before it’s ready to start the exposure.
I agree that the windows pc time would introduce considerable error. All astrometric/photometric software look for the time in the FITS headers to ascertain time. To correct the PC time, I employ a program that synchronises the PC clock with an online atomic time server that also considers the lag time of internet traffic.
I will follow with interest the question posed by Chris as this could also be an issue in some circumstances.
So here is how we have now implemented this in SGPro (a few concerns and caveats that users should be made aware of):
The method that Chris suggests only works with ASCOM and QSI cameras.
This method is not guaranteed to work for all ASCOM cameras (driver dependent). If SGPro fails to query the camera for this time properly, it will default back to the current method.
SGPro is essentially “passing the buck” on this issue. While Chris is absolutely right about the current SGPro implementation being imprecise, we have no way to be certain that the camera driver author is setting it correctly either.
There does not seem to be an equivalent query for SBIG or FLI cameras so, seemingly, our only course here is to snatch the time immediately prior to sending the integrate command (just like we do now).
All ASCOM cameras should implement LastExposureStartTime because it’s part of the specification. An application can easily put the call in a try - catch structure and revert to using the system clock if it fails.
Exactly where the driver gets the time from is up to it. For example Apogee cameras use the system clock, read in the ASCOM driver, and the Atik camera driver reads it from the camera’s low level driver. I don’t know where that gets it from but the only source of time is ultimately the system clock. That’s going to be vulnerable to all the usual vagaries of time in a Windows system.
What this means is that you are probably not going to get precision to better than a second and the accuracy may be worse. Setting the PC time accurately will obviously help. Is that good enough for your application?
Chris
PS all this applies to the exposure duration as well, there’s a LastExposureDuration property in ASCOM.
Many thanks for your concern and will keep on the lookout for the 2.4.1. version. I suppose that I would not urgently need sub second accuracy as most of my targets are main belt asteroids that move much slower than NEO’s.
I have a Moravian G2 1600 CCD in the post and it would be appreciated if you could tell me what to expect with the function of SGP to this CCD. Is the Moravian driver up to the task when it comes to register the correct timing? In case, I may have to do some tests and will have to adjust the FITS headers manually for critical tasks Perhaps, as a future upgrade, SGP might allow users to insert a correction in timing through a dialog box and the program will modify FITS headers accordingly.
Yes, this mirrors the current implementation. If we catch, we default to the “usual” SGPro method otherwise we use what the camera gives us.
Using the property that Chris identified is even more important for Moravian cameras. Their driver implementation will not change filters until an exposure is started. This means that SGPro would grab a start time, then the camera would change filters (introducing a 3-5 sec error immediately) and then start with the exposure. Assuming Moravian sets this property after its FW change, you should get much better accuracy with this method.