×

INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Flats - a minor issue and a less-minor issue

  • Posts: 131
  • Thank you received: 20
Less-minor issue: When I try to take sky flats anywhere near twilight, the auto-expose routine always gets stuck in a loop chasing the correct ADU value. It will capture an exposure that will be a bit outside the acceptable ADU-value window, adjust to a new exposure time that gives an ADU just barely within the acceptable range, take another exposure but now it is again just outside the acceptable range. This cycle continues until I give up. Is there some strategy I should use for sky flats that I'm missing?

Minor issue. Is there a reason why it takes two images for every one that it keeps? As this log snippet shows, Ekos double-checks the exposure every time. I'm pretty sure it did not do this in the past.

[2022-04-14T10:29:28.432 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 4 out of 40."
[2022-04-14T10:29:28.437 EDT INFO ][ org.kde.kstars.ekos.capture] - "Captured /mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_004.fits"
[2022-04-14T10:29:29.179 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:34.533 EDT INFO ][ org.kde.kstars.ekos.capture] - "Current ADU 30020 within target ADU tolerance range."
[2022-04-14T10:29:35.617 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:40.610 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_005.fits"
[2022-04-14T10:29:41.046 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 1.11 s, New Download Time Estimate: 1.13 s."
[2022-04-14T10:29:41.061 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 5 out of 40."
[2022-04-14T10:29:41.065 EDT INFO ][ org.kde.kstars.ekos.capture] - "Captured /mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_005.fits"
[2022-04-14T10:29:41.947 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:47.204 EDT INFO ][ org.kde.kstars.ekos.capture] - "Current ADU 30019 within target ADU tolerance range."
[2022-04-14T10:29:48.074 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:53.047 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_006.fits"
[2022-04-14T10:29:53.455 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 1.03 s, New Download Time Estimate: 1.13 s."
[2022-04-14T10:29:53.466 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 6 out of 40."
3 months 4 weeks ago #82439

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 55
about the first issue, the 'Tolerance' allows to adjust the valid ADUs range. Have you tried to increase it?
Sky flat ADU values change rapidly so having an higher tolerance should help preventing the issue.

The log that you attached seems to show a correct behavior, it captured 3 out of 40 images and it's not in a infinite loop.
To me the double image in the log seems to be caused by a double logging of the same image but to be sure it should be looked into the source code.
Do you get 80 images instead of 40?

The log shows an interval of about 12s between a capture and the next, while the exposure is only 1s.
Did you set a 'delay' of 10s? if this is the case, I would decrease it, it will help to have ADUs in the correct range.

Ferrante
3 months 3 weeks ago #82464

Please Log in or Create an account to join the conversation.

  • Posts: 131
  • Thank you received: 20
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 thousandths 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.
Last edit: 3 months 3 weeks ago by Ron DeBry.
3 months 3 weeks ago #82466

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 55
ok it's more clear now and it's quite an odd behavior that I didn't experienced when I was using sky flats.

But increasing the tolerance should lower the chance of hitting the threshold during a entire session of flats (at least for each of the filters).
I mean, if you set 16000 +/- 4000 the chance that all the 40 (maybe better to lower to 20) flats ADUs are in the 12000-20000 range is greater. So no need for 'cycling'.

And having flats with a wide range of ADUs is ok as long as they are normalized during integration.

I see that this is not a solution to your issue but more a workaround to avoid it.

Ferrante
3 months 3 weeks ago #82467

Please Log in or Create an account to join the conversation.

Time to create page: 0.355 seconds