×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Imaging during partly cloudy nights

  • Posts: 1185
  • Thank you received: 370
Many of us live in regions where pure clear skies are so rare that we would like to run astrophotography sessions although the sky is partially clouded. KStars / EKOS has meanwhile several robustness features that make it possible to run a fully automated session although the sky is not perfect.Since this question arises in this forum from time to time, this thread is intended to bundle all tips and tricks to make the session as robust as possible.

Problem detection
It does not matter how clouded the sky is as long as the small fraction of the sky you are capturing is clear. So the best approximation that capturing does not make sense is when guiding runs into problems with the guiding star. If there are clouds that are so heavy that guiding get's into trouble, the captured frame is worthless.

Reaction
If a guiding problem is detected, the best reaction is to immediately abort capturing. You can control this with the following parameters:
  1. Guiding options | Guide | Lost star timeout
    If the guiding star is lost for this period of time, guiding aborts and subsequently capturing aborts. A typical value is 20 seconds.
  2. Capture | Guide Limits | Abort if Guiding DeviationIt might happen that the guide star re-appears, but your scope is already to far off so that continuing would create elongated stars
Recovery
If you are using the Capture module standalone without the Scheduler, capturing will recover as soon as the guiding deviation is below the configured value. If this is unchecked, capturing will remain aborted.A more robust way for recovery is using the Scheduler. Its main feature is the "Aborted Job Management" that gives you the opportunity to try to restart capturing. There are two options that should be used, depending on the expected scenario:
  1. Aborted Job Management | Immediate
    This is the option that I prefer. If a job aborts due to guiding problems and restarting guiding fails for 5 times, the Scheduler sets the job state to ABORTED and will retry to start it after the configured amount of time. This will happen as long as the constraints of the job remain valid.
  2. Aborted Job Management | Queue
    Similar to 1., but the Scheduler will jump to the next scheduled job and tries to start this one. This variant makes sense if you expect that the clouds remain in a certain part of the sky and starting the other job increases the chances to find some clear sky. From my experience, that does not happen very often and it's better to stay a a certain target.
That's it, hope that helps, feedback warmly welcome.
Wolfgang

p.s.: Don't forget, this is not an approach for nights where the clouds are so heavy that rain is at risk. In this case, you additionally need safeguard measures for your observatory, which is not issue of this thread.
The following user(s) said Thank You: Jasem Mutlaq, Sergio, Scott Denning, Ron Clanton
2 years 7 months ago #74605
Attachments:

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

  • Posts: 225
  • Thank you received: 16
Thanks!

The only other thing to add is the bit about setting scheduler option to "Restart alignment on guiding calibration failure", as it will ensure that you have not drifted off the target.

Thank you!

Ron
2 years 7 months ago #74609

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

  • Posts: 1185
  • Thank you received: 370
If the job aborts and the scheduler restarts it, this option is not necessary (as long as you have selected the alignment step). I personally do not use this option, but it can only make things better if used.
2 years 7 months ago #74610

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

  • Posts: 225
  • Thank you received: 16
Wolfgang,

Okay... I do not understand. In the "guiding aborted" scenario, the job has not stopped... so does it still realign once guiding has resumed?

Appreciate your sharing this information!

Ron
2 years 7 months ago #74612

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

  • Posts: 1185
  • Thank you received: 370
The scheduler tries to restart guiding 5 times. If the option "Restart alignment on guiding calibration failure" is set, the scheduler will always start an alignment before re-starting the guiding. If restarting guiding fails for 5 times, the job is set to ABORTED.

If the job now gets restarted, alignment will take place if the alignment step is checked. For this case, "Restart alignment on guiding calibration failure" is not relevant.
The following user(s) said Thank You: Ron Clanton
2 years 7 months ago #74613

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

  • Posts: 225
  • Thank you received: 16
Got it!

Thanks!

Ron
2 years 7 months ago #74614

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

  • Posts: 15
  • Thank you received: 1
Thanks , clear explanation .
This post should be add to the documentation :)
2 years 7 months ago #74640

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

  • Posts: 225
  • Thank you received: 16
Wolfgang,

I was able to take some pictures last night and run KStars under the debugger (see attached log). The conditions were poor and I imaged too close to the moon, but it gave me a chance to try your settings.  There was no KStars crash.  I don't know if those changes helped... but generally pleased.  Here are some observations:
  • Everything started up fine, but I noticed that capturing starts immediately once guiding starts, ignoring RMS limitations, settle constraints, etc.  This only happens on the first capture.  Not a big deal because as soon as the guiding RMS records a larger number (which it did until it settled down), it aborted capture.
  • The parameters suggested by you worked well!  They should be a "best practice".  My only surprise is that the guiding RMS capture limitations are measure for each individual guide capture... not the accumulated RMS reported in the guide tab.
  • The auto focus at 120 minutes was successful!  This had been a problem earlier.
  • My only big problem was during the meridian flip.  The system successfully flipped the mount, but was unable to plate solve.  The images it was taking have a problem.  I attached a screen print.  I don't understand what's happening, as it worked fine on the original solve, focus, etc.  Anyway, the solver aborted.  The scheduler continued to work.  Unfortunately, the OTA was pointed incorrectly and off the object... so won't stack.
  • The object went behind trees around 2:17 am, but the system handled it fine and shut down/parked once the Alt hit the minimum.

So... the solver issue was the only big problem.  Hopefully, the logs/image will help solve the issue.  I sent all of this to Jasem on StellarMate support, but wanted tol also post this information on this forum to provide some feedback to others.

Thank you,

Ron Clanton
  

File Attachment:

File Name: kstars_log...0-01.zip
File Size:5,382 KB

 
Last edit: 2 years 7 months ago by Ron Clanton.
2 years 7 months ago #74641
Attachments:

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

  • Posts: 1185
  • Thank you received: 370
Hi Ron,
the log does not show any details why aligning failed, it simply ran into a timeout. In your screenshot, there is a big black stripe in your image. I wouldn't be surprised if that is the reason. And maybe you should increase the exposure time to 3-5 sec and the gain to 100 to increase the lightness of stars.

Regarding capture start: there is an additional option so that you can set the guiding limit that needs to be kept for capture start. But generally, why shouldn't capturing start immediately when guiding is running? If there is a guiding deviation, it could abort and wait for a better guiding.
2 years 7 months ago #74656

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

  • Posts: 225
  • Thank you received: 16
Yes, the big stripe is likely the reason. However, that is strange as I've never encountered any problems with those settings over the last few months. In fact, those were the settings for the first alignment that worked. I also got the strip on the autofocus that happened a few minutes before the meridian flip. So something change during the session. It almost looks like a connection problem... weird.

I do have the guide limit for the capture start. However, it starts capturing before the first guiding correction is calculated. It's not a big deal. I had a lot of aborts in the beginning until guiding settled down.

The only thing I didn't see is where the guiding failed five times, the scheduled job should have shut down... then restarted after the time set in the scheduler. Did you see any signs of that happening? It should have happened after 2:17 am when the target went behind the trees.

Thanks again for the setting recommendations... game changer!

Ron
2 years 7 months ago #74657

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

  • Posts: 1185
  • Thank you received: 370
Hi Ron,
there are plenty of lost star events in the log, but re-acquiring was always so fast that guiding never aborted. Typically, re-acquiring succeeded after a couple of seconds and did not reach the star lost timeout.
Wolfgang
2 years 7 months ago #74660

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

  • Posts: 225
  • Thank you received: 16
Wolfgang,

After about 2:17 the object went behind some trees and there was no guiding for a couple of hours until shutdown. However, the job never aborted (that I can tell). I wonder if I'm missing a setting?

Thanks,

Ron
2 years 7 months ago #74667

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

Time to create page: 0.457 seconds