DATE-OBS Problem

This one has been going on for a while, but I just caught it when I tried to stack a set of frames of comet C/2013 US10 Catalina.

I could not get PixInsight to record the location of the comet on my last frame, when I noticed that all the DATE-OBS keywords were the same for all images…all zeroes. I had no problems when comet stacking other comets, but as it’s not something I do often, this may have been something “new.”

I looked back through images collected over the past year and found out that frames collected using 2.4.0.2773 and earlier were fine, but anything using 2.4.1.4 or later had this problem. I changed nothing else in my system (except changing my pc from using UTC to local time due to the start/end target issue, which was not a factor in this).

I did a little test and noticed that the DATE-OBS keyword is filled in when I save a frame/focus frame using the right click as noted with:

Frame/Focus Save

But when a file is saved during a sequence, this is what I get:

Sequence save

I’m using a QHY22 using the direct driver for camera control and that hasn’t changed for a while.

If needed, here is the logfile from a test this morning that I used to create the above files:

logfile

Thanks,

Frank Z…

It’s likely because this date is coming from your camera:

[12/20/2015 9:47:48 AM] [DEBUG] [Sequence Thread] DATE-LOC time provided by camera...

FYI DATE-OBS is this converted to UTC. Is there some where that this can be set in the camera? The camera driver is reporting that is has this data so we attempt to get it there first.

Thanks,
Jared

I’ve added some bounds checking to the date coming back from the camera. It looks like the date your camera was providing was way in the past. However if you were expecting this date to be coming from the camera might want to check your driver settings.

Thanks,
Jared

Jared,

I checked a few things and update my ASCOM driver for the camera, although date wasn’t an issue on the bug fix list.

I still get the same results.

I saved a few frames in another software and it correctly placed a DATE-OBS with the time adjusted for my time zone (Mountain…UTC-7h). I don’t know where it gets it’s time, from the camera driver, or PC. SGPro gave me time stamps similar to what is in the file in the original post. I set my pc time to UTC where there is no offset from UTC and the same thing in SGPro. So now, I’ll try to use any imaging software I have available to see if I can find another that has the same time stamp issue.

I did notice, that when I save a frame from frame/focus, it uses the current save time as the DATE-OBS, not the capture time.

When I looked at the dates from older files, it had both the DATE-OBS and DATE-LOC seven hours in the future from the windows file time stamp. My PC was set for UTC at this time…maybe something in the driver remembers old windows time settings and is causing problems. I’ll poke around some more.

Thanks,

Frank Z…

Jared,

Uninstalled and reinstalled all my drivers and still the same. Two other programs give correct DATE-LOC and DATE-OBS headers, but I don’t really know where they got the info.

Is it possible to put the time from the camera in the log so one can have some idea what is going on if you reject the time from the camera?

Thanks,

Frank Z…

I’m guessing that they’re getting the date from the system.

The change that I mentioned earlier should take care of this. Essentially if the camera gives a bad date we reject it and use the system time. Previously if the camera returned a date (any date) we would trust it. Should be out in the next beta.

Thanks,
Jared

Thanks Jared,

Would it be possible to place an entry in the logfile with the camera time and system time when this happens? I can then pass on the section to QHYCCD as a bug report.

Thanks,

Frank Z…