My friend can’t get a sequence to finish, it ends right after it starts. None of the delay timers are checked. The computer time and date is correct, telescope via GPS has correct time and date, but FITs header from a saved frame and focus image shows the date and time as year 0001 and some different time. SGP is seeing this time from somewhere…try run run a sequence and it says it’s past time for this to run…manually change the delay time to something in the short future even though none of the delay settings are checked and the sequence will start, slew to a target, but then stop and say the sequence has ended without taking any images. I have looked at his settings…and set them like mine. They work on my setup, but we can’t get his running. This really has us baffled!!! Any thoughts???
Thanks,
John
I am that friend… and I might add that I did get sequencing to work again; don’t know what I may have changed to get it to finish a sequence. However, the FITS header from the “Frame and Focus” pics all have creation dates of 0001-01-01 at midnight, and the UTC date is 0001-01-01 07:00, a correct offset for my area (Arizona). Also, when I save the images that PHD2 utilizes for plate solving, the correct picture creation date is found, which leads to believe that there is not a problem with my computer and how it stores the date. My guess is that it has to do with the Meade I ASCOM driver (I have a LX-90 GPS) and maybe that field is not updateable through the SGP software?
Hello, in fact SGP gets times from the damera driver. Which is the only one “who” knows the exposure starting time.
SGP expect this time to be the UTC time, and adds the time offset to it and saves it also in the fits header as LOC time.
Now there is also something unclear about it, because several camera drivers reports the local time instead of the UTC time.
SGP has implemented a kind of detection of this and in the SGP traces, we can see that SGP detects that this is a local time stamp instead of an UTC time stamp, but does not correct it properly afterward. (at least avec the Moravian driver, which repports the local time, but I guess this is the same with QHY, or other)
So, if the time in the header is incorrect, it has something to do with the camera driver time only. If it is just a mater of local time offset, it is probably due to the driver which is repporting Local time instead of UTC time.
But if the minutes are also completly wrong, this is due to the camera driver which did not get a correct tome from the PC clock for any reason. In that case, a PC and camera restart should solve it.
I also faced the same issue few days ago.
Thanks for that explanation @olivdeso… If what you say is correct then it looks like my ZWO drivers for my ASI224MC are not reporting the correct time and the camera for my guide scope (ASI120MM), even though I thought they use the same ZWO drivers (?), is reporting the right time (at least to PHD2) as that FITS header in fact does report the right time. I will investigate this some more and let you know any details if I find anything else.