Thanks for taking the time to reply, Ferrante

I should have been clear - the log snippet was from when I was using an LED panel.
Ekos captured 80 images, but saved only 40 of them. The cycle is: Capture, check ADU and decide it is OK (this file is not saved), capture again (this file is saved)
Although the exposures are 1 second and the reported download time is just over 1 second, the total overhead of exposure, download and process adds up to ~ 5 seconds per frame. There is no intentional delay set.


With sky flats, I did try widening the acceptable ADU values. If the ADU range is 19000 +/- 1000 the procedure starts somewhere in the range. If the sky is darkening, once the ADU goes below 18000, the algorithm increases the exposure, but only a very small increment. This raises the ADU to something like 18030. The 'test exposure' decides that is OK, but by the time the next exposure is taken the ADU value is back down to 17980. So it increases the exposure again by a few thousands of a second, gets back up to just slightly above 18000, declares that to be OK, takes what should be the next valid image but the ADU is again slightly below 18000.

Widening the ADU range further will not change the behavior, it would simply change the 'cycling' from 18000 ADU to some other point.

I will try to find a log where this happened. The solution would seem to be to have the algorithm try to change the exposure to hit the *farther away* ADU limit, not the nearest ADU limit - but I do not know how the program is calculating its 'corrected' exposure time.

Read More...