Well, I have made some tries changing the PC time to UTC and another one in Local Time (Madrid).
In both cases, SGP takes the time sent by the QHY9 as a UTC time, and writes the FIT Header accordingly.
In the case of PC at Local time it adds 2 hours to the time read.
I am not sure really. The most I can say is that there have been no other reports of this behavior (and also that my QSI returns UTC). Then again, most folks probably don’t really care too much if this value is incorrect.
The logging in 2.5.2.2 confirms that SGPro is receiving a local time from the camera, then we apply your PCs time zone to that to get local time.
Patently untrue. Moving to London will also fix this issue.
SGP passes the time transparently from the camera. It is supposed to be UTC according to the soecification. This will need to be changed in the QHY ASCOM driver.
I wonder about that. If we are talking about Camera.LastExposureStartTime, the ASCOM documentation reads:
“Reports the actual exposure start in the FITS-standard CCYY-MM-DDThh:mm:ss[.sss…] format.”
It doesn’t say it has to be UTC - perhaps it is documented somewhere else or perhaps “FITS-standard” implies UTC?
In any case, I imagine getting the UTC from the telescope is generally more reliable.
The telescope doesn’t have to be any more accurate than the camera. Same problem…drivers out of our control. Unfortunately to have the accuracy that some need we have to rely on the camera for this time as it’s the only one that precisely knows when an exposure starts and ends. We can request an exposure but the precise start time is unknown to us as the camera may take some time before the exposure actually starts. When doing some measurements I believe this is an issue. I just make pretty (generally not so pretty) pictures so this isn’t a concern of mine. But those doing scientific measurements seem to need this precision.
I have no skin in this game but it would be possible to determine the offset of the camera (e.g. time zone) by comparing it to the telescope since the telescope is supposed to return UTC while the camera spec seems to be ambiguous. Besides that, a telescope driver is obligated to return UTC while a camera might not supply the time (per the ASCOM spec). So what does SGP do for a FITS header when a camera does not supply the time? I assume it may be using the telescope time or the PC time. It may be reasonable for SGP to do some sort of sanity check for any time it gets from the camera. That could circumvent the issue reported by @swag72
Hahahaha… It should be great!
But I have some english friends here who moved to Alicante for having more clear skies!
After that issue, I have contacted some friends with permanent observatories and all of them set the PC time at UTC time.
I think is a good practice. You don’t have to bother with driver problems…
“Off-topic”:
It’s incredible, but looking for a solution in QHYCCD forum, I found that the developer of QHY10 drivers has abandoned the company, and nobody knows where is the source code for developing or fixing new versions!
Mine is QHY9!! I hope the QHY9 guy is OK and still working there!!