Hi,

I am trying to image several targets a night. The exposures are very short (only a few seconds up to 60 sec), hence I would like to use the feature to wait a while for making another shot.
This actually works well in the setup for the targets, but the calculation of the overall time for the series is screwed up. So , it did not switch to the next target as it was suppossed to in the target list but continued imaging its series.

I hope this can be easily solved in a minor update. Looking forward to this.

Regards,

Josch Hambsch

http://www.astronomie.be/hambsch
http://users.pandora.be/hambsch/

Josch,

Please post a zip of the relevant log, target list and system profile for investigation.

Sorry, but I had first to download all the relevant files from the remote observatory.
Here is the zipped file with the requested content.

Josch Hambsch

http://www.astronomie.be/hambsch
http://users.pandora.be/hambsch/

ccdap20070104_184315.zip (17 KB, 21 downloads)

The log shows all three targets trying to run but the target list shows only gsc1415-781 selected with a start time of 00:28 5 Jan. This does not agree with the log of course.

Do you recall your attempted start times for the three targets?

John,

of course I had to unselect two of the targets and had issues of strange behavious of CCDAP. So I had to restart twice, if I recall well (meaning also to save the target list).

I just restarted CCDAP with the targets list all checked and start time 6:30 pm. It immediately calculated the end times and start times of the next target, which where 20:21 for the first target and 20:21 to 21:27 for the second (I had to reduce the exposure for this taget, initially it was longer until about 22:35) and the third target from 21:27 until 2:54 next day).

However, if you take into account the delays the real running time is much longer. BTW it never gives a right estimate of the imaging run time after you start with Run Session.


Josch Hambsch

http://www.astronomie.be/hambsch
http://users.pandora.be/hambsch/

Josch,

quote:

I just restarted CCDAP with the targets list all checked and start time 6:30 pm. It immediately calculated the end times and start times of the next target, which where 20:21 for the first target and 20:21 to 21:27 for the second (I had to reduce the exposure for this taget, initially it was longer until about 22:35) and the third target from 21:27 until 2:54 next day).

I don't understand what you are saying. With all the targets activated, the start and end times on the target page are consistent with your exposure time, number of exposures and 3x3 download times. I see no problem with the results you reported above and I got the same results here. BTW, you have other delays set to 1 sec.

Insert WCS adds a variable amount, depending on the camera FOV and plate solve technique. Since your exposures are short and numerous, Insert WCS adds significant time per exposure and therefore per session. You need to estimate this and enter it in the other delays section. I have found it takes 9 sec. here with a 19 x 29 a-m FOV and PinPoint. You will no doubt need your own estimate for your FOV and CCDSoft/TheSky plate solving.

quote:

BTW it never gives a right estimate of the imaging run time after you start with Run Session.

What 'it' are you referring to - log entry or status window entry?

John,

yes, that is what I expected, however, as you can see from the log the first target was imaged until 22:35 until I aborted the session. It should have ended around 20:35 as from the calculation. If you count, the 7 x 50 x (10 + 8)s = 6300s = 1.75h, which is the time I got in the target info screen. If you check the time it took to get the first 50 images (incl. download) then you see that this already took more than 1 h. It shows about 1 min delay in between the different exposures, which is not counted in the calculation. So sometihing is wrong.

I did not had WCS checked (saw it only after I had restarted CCDAP again this morning). So if you say that adds some delay, I will uncheck it.

The time info works when I have the delay set to zero. I did several runs with this settings and longer exposures (40sec) and two targets without problem.

To my feeling it is connected with the delay set in the light frame screen.

Josch Hambsch

http://www.astronomie.be/hambsch
http://users.pandora.be/hambsch/

Sorry I forget to reply on the second point the overall time calculation. IN my case the info given in the status window after you hit run session so far never coincided with the real imaging time. Anyway, that is not so much of importance here. The right time calculation with multiple targets and delays is more important.

Josch Hambsch

http://www.astronomie.be/hambsch
http://users.pandora.be/hambsch/

Josch,

Yes, that is exactly it. You have selected unguided operation but entered a guide exposure delay factor of 30 with a guide exposure of 2 which adds 60 sec. to each exposure cycle. In looking at the first 50 exposures in your log, the elapsed time from 18:45:19 to 19:52:40 is 4041 sec or 80.8 sec./exposure cycle. Deducting your guider exposure delay of 60 sec., gives 20.8 sec. per exposure cycle. With a 10 sec. exposure and 8 sec. download time, this is certainly in the ball park.

Conceptually, I could ignore the guide exposure delay when imaging unguided but there could be some cases where an inter-exposure delay is helpful, e.g. with a slow or mis-behaving filter wheel. Therefore, I will not be changing the code but suggest you set the guide exposure delay factor to 0 for your photometry runs.

PS The exposure delay was not being properly reported to the target start and end times for unguided operation. This will be corrected in the next maintenance release. Had this been correct, you would probably have been alerted to the issue.

John,

that is just the point. If the delay time would have been reported properly than I would have had the number of exposures adjusted.

I actually wanted to have a delay if the exposure is only 10 sec.
Otherwise I get a huge amount of images, which I have to download to my home PC.

Thank you for taking this up in the next release.

Josch