This is to enable better support of programmes that require the accurate recording of exposure times in the filename. At the moment the ‘DateObs’ variable within FITS headers varies with regard to showing decimal seconds in the recorded time of exposure but it’s not clear whether or not it actually populated consistently. In addition the filename format tokens do not allow such accuracy.
Having the ability to include an accurate time in the filename will greatly enhance my local Astro Societies Pro/Am study contributions.
Have you have an opportunity to review this request at all? It all seems to have gone quiet albeit I appreciate that you going great guns with improvements in general. Having this option would help me and others in our current Pro/Am citizen science programme, and with future projects, I sure.
I don’t see how putting the exposure time in the file name will make any difference. The best source of exposure time is the LastExposureStartTime property in the ASCOM camera driver. SGP puts this in the fits file header. The value is provided by the driver as a string and the driver author can provide whatever is needed to satisfy the accuracy that the camera driver can provide. Putting this same value in the file name will have no effect at all on you, will impact everyone, and more difficult to implement.
I think your pros will be able to read the start time from the FITS header.
If you need a more accurate time then ask your driver developer to provide this information.
I guess this is some sort of occultation work; the asteroid occultation people have lots of experience with this, they seem to go to some lengths to provide accurate time synchronised image streams and have applications to record this. You may be better off talking with them.
Many thanks for your speedy response and associated information.
I can see your point of view, and indeed being able to have a high resolution time token for use in filenames can indeed be seen as a convenience for perhaps a limited number of users of SGPro. So, given your experience as an ASCOM developer and your association with SGPro, are you able to answer me this:
1 - Is the value written into the file header variable ‘DATE-OBS’ a direct transcription of the parameter ‘LastExposureStartTime’ property in the ASCOM camera driver, with or without any necessary formatting adjustments?
2 - If ‘DATE-OBS’ is not ‘LastExposureStartTime’, then why do I not see ‘LastExposureStartTime’ in the FITS headers?
3 - In the case of the SGPro ASCOM driver for QSI cameras, does the ‘LastExposureStartTime’ property facilitate millisecond resolution? If so why does it not appear in the FITS header?
4 - If the ASCOM driver does not facilitate this resolution of time, is it in your opinion a change that could be implemented, obviously by SGPRo or QSI, if requested to so, for the reasons I have already explained? I appreciate that in answering this question it in no way indicates that it will happen.
My local Astro society and associated Pros have spent considerable time and effort in establishing which proprietry applications that actually reflect time accurately dispite what’s written in headers, etc., not many if any. Until now the need for a comprehansive image capture application, like SGPro, has not proven necessary. Now however SGPro’s other capabilities are being put to great use, and hence my feature request to up the game in terms of the recording of high accuracy time.
Thanks you for your consideration, and I look forward to hearing from you again.
The time property provided by the ASCOM driver is called LastExposureStartTime and it returns a string in the FITS specified format. How this is handled by SGP is up to SGP.
It is up to SGP how they handle this but putting the LastExposureStartTime property in the FITS header with the DATE-OBS key would be rational.
You need to ask the authors of the QSI ASCOM driver. They are the ones who implement this. It is possible that they may not be able to provide this information with millisecond resolution. If they use the PC clock to provide this value to provide this value then one second may be as close as they feel to be reliable. But fundamentally they are the ones to consult about the time accuracy.
The ASCOM driver specification allows the resolution of the time to be whatever the driver authors are able to provide.
As I’m sure your research has shown getting millisecond timing precision is not trivial. Calling the .Net DateTime functions will not do it. People usually start with a GPS derived timing pulse. This needs to be integrated into the camera and it’s driver because they are the only ones who can synchronise the start of an exposure to a time.
Does your Camera have a time synchronisation input? Some GPS systems can provide a one pulse per second signal that has an accuracy of what you need, one microsecond seems typical.
But if your camera desn’t have a 1PPS input I don’t think there is anything that can be done. It’s accuracy will be no better than your PC.
Incidentally if the camera is synchronised to an external timing pulse then this could deliver the accuracy you want, even though the resolution isn’t. 15 secs could actually mean 15.000000 secs.
There doesn’t seem to be much point asking for better resolution in SGP until you know that your hardware can actually deliver it.
Thank you for your consider response, and I will be most interested to hear from whomever implemented the QSI ASCOM driver in this regard, if they are on this forum.
I do indeed utilise a GPS dongle and the NMEATime application to control my PC timing. This ensures that my PC is synchronised to within a few milliseconds of UTC after a period of continuous running.
We’ve then characterised our respective camera setups by taking images of a millisecond timer displayed on the PC screen that has been specifically written to run as a very high priority task to ensure adequately reliable data. The images versus header entries are then compared in order to characterise the system as having a known time delta per setup.
It is this analysis that I’m attempting to undertake and thus obtain the timing resolution for. As opposed to expecting to have a guaranteed millisecond perfect timestamp.
As I’ve said, I hope this explains things well enough and I hope to hear from anyone in the SGPro Development team that can clarify how this application handles time in this respect so that I, and others trying to do astrometric or similar such work can make better use of this otherwise great package.
You will probably need to be a bit more proactive than that, try contacting them directly rather than hoping they are lurking here.
This seems to me like checking a clock is correct by looking at it twice. Any error in the time the PC reports will not be detected.
What I’d do is run a counter driven by a 1MHz clock and triggered by the edge of a GPS 1PPS signal. Then the image of the counter display will show when the exposure was active.
I really think you need to talk to the asteroid occulatation people. They know about this sort of thing. Here’s a link that might help.