I wonder if someone can say how SGP puts the time into the fits header… Where does it get the time from?
I ask as my computer is accurately set to UTC+1 (Madrid time) and displays the time correctly when switched on. When I look at the fits header time of the image, it gives me a time that is wrong.
For example. I have a sub that shows in the Windows explorer as 01:20 and yet in the fits header it is giving a time of 17:19. Looks to me as though the fits header time is 6 hours short of where it should be. If SGP grabs the times from the PC, can anyone explain where I can even start looking for this discrepancy?
I am looking at the PC clock time, bottom right of the taskbar and also have ensured that the time on that is correct. I’ve also updated it via the windows protocol option it gave me and it’s not changed anything.
Madrid (Spain) is at present 2 hours ahead of UTC so your file time in Win Explorer showing 01:20 is actually 23:20 UTC. Fine so far - as you say - that it is different by 6 hours from the FITS.
Six hours might be an easy error to track down - but if this is one of your normal 30 minute subs…then it may not be that easy after all. As far as I can see Win Exp logs the time when the file is saved (or modified) which is going to always be 30 mins different from the FITS - which seems to log the time the sub was started. (I can see that 20 minute difference on my normal 20 min subs). The values on the FITS (only) might be a good place to start trying to track down the error you are seeing.
I have my obs computer on UTC so the capture below (from the FITS info) shows Date-LOC and date-OBS being the same. Perhaps you could verify what these show on any of your FITS headers…just as a first step to try figure out where the difference is.
We grab the system time and don’t modify it when putting it into the FITs header as DATE-LOC. For the DATE-OBS we convert to UTC.
The windows Created Time should be the same as the time displayed for DATE-LOC.
I don’t get what you mean about the system clock and the FITs header not matching. Are you watching the images as they come down and comparing that with the clock?
Here’s a copy of my fits header for a sub that I was there when it downloaded. This certainly doesn’t correspond to an actual time as it isn’t even dark here by these times!
Here’s a copy from explorer saying at what time this file was ammended - Presumably that means the download time … this is correct as this is the time that it downloaded and it was my first sub of the night.
Sorry I didn’t mean 6 hours difference, as I looked at the minutes and not the hours! So as it stands I am always getting a 2 hour difference between my actual PC time and the time that goes into my fits header.
The only thing I could think of is maybe you have multiple clocks enabled in windows? We grab the system time, but it is possible to have multiple other clocks. The minutes should be near exact (only off in the case of rounding on the windows explorer display).
To get the “Date Created” you can right click on the headers and select that as a display option. Windows does not show created date by default, only modified.
Modified can be updated pretty much anytime a file is open and is not a good indication of when the file was created.
Other than that if you want to attach a log and a fit that was captured in that run I can take a look.
I don’t have multiple clocks used - Brendan and I checked out my PC yesterday and we couldn’t really find anything that would indicate what was going on.
Interesting I did a run last night and the timings are still off despite changing one of the settings on the windows automatic time update that I read online can sort this out.
@Jared - I’d love you to take a look at this … The image I’ve uploaded is the first one from the night, so you can hopefully find it nice and easily. I’ve looked at the log and the times are just as the PC, so SGP is using the correct times… so I have no idea why it is writing a completely different time to the fits header…
[24/07/2016 22:50:43] [DEBUG] [Sequence Thread] DATE-LOC time provided by camera…
Does this mean that the time is read from the camera using the LastExposureStartTime property? This should return the time in the FITS standard of UTC but if it doesn’t then would this put the time out.
Good catch! I had forgotten that even existed! And yes, that’s correct. We do attempt to convert this to LocalTime but without knowing what the actual time is on the camera or what the time the camera is reporting it’s difficult to know what is happening. I’ll add some logging to this to see if we can figure out where the problem resides.
The ASCOM driver has a LastExposureStartTime property that returns what it says. It’s up to the driver author to implement this. You will need to ask the driver author about changing this; they need to know anyway because if they are returning local time they need to change it.
I’m using SGP 2.5.1.17 and I have a similar issue.
Has been fixed in the last beta?
I have a QHY9 camera, and I get:
File written at 22:47:47 (local time for Spain, that is 20:47:47 UTC)) — OK
File name: Wasp52b_Lum_-20,0C_120sec_1x1_L_frame1_2016-09-30_224718.fit ---- OK.
But the Fit header is wrong!:
DATE-LOC = ‘2016-10-01T00:47:47’ / Local observation date
DATE-OBS = ‘2016-09-30T22:47:47’ / UTC observation date
SGP thinks that UTC time is the actual local time!
It’s a really great problem.
In that case, I was imaging an exoplanet transit, and UTC time is really needed for working with images and use them with software like Fotodif. I have now to change manually the UTC time in more than 200 images!
I was very happy with 2.5.1.17, very stable for me and great results!
I’ll install next beta to see if that was fixed.
Thanks
Fernando
Yes, I think the camera is sending the Local Date to SGP, and SGP takes it as UTM time.
But there is no place at the QHY Ascom driver to set what Zone Time it has to use.
I’ve checked with a friend with same camera (QHY9) and SGP (2.5.1.7), and has the same issue.
In the meantime, I have found a solution: Setting the computer time at UTM.
As it’s a dedicated computer only for astronomy, doing that is not very annoying.
Indeed it’s a good practice thinking only in UTM.
Anyway, I’ll install and try 2.5.2 and post the results.
Thanks again.
