INDI Library v2.0.4 Released (Yesterday)

Bi-monthly release with minor bug fixes and improvements


  • Posts: 300
  • Thank you received: 57
I know it sounds weird, but my imaging desperately needs more failure!

What I really mean is that I want the SCHEDULER to KNOW when something has failed, so it can restart a job. 

Very often (like almost every night) when I use the Scheduler, something goes wrong. For me the most common problem is passing clouds that cause a temporary break in guiding. The internal guider tries and tries to re-start and after some minutes a new guide star appears. The guider latches onto that and drags the mount to a new position, then guides there. Or the focuser fails (again because of passing clouds). Or a meridian flip lands on the wrong position. Whatever.

The upshot is that I then get hours and hours of very nice subs of the wrong sky position. (see example below of consecutive subs of PK_164+31.1)

I know there's already discussion about enabling more low-level failure (e.g., in the Guider, Focus, and Capture modules). This is good, because a low-level failure can then cause a message to be passed up to the Scheduler to restart a job. If the job includes Align and Focus then the target will be recentered and refocused and the rest of the night saved.

But given the FANTASTIC image analysis already available in Ekos (especially since the integration of StellarSolver and the Analyze module), it should be VERY EASY for the Scheduler itself to detect failure at this higher meta-level!

In maybe 2 seconds following a capture, the Analyze/Schedule modules should be able to detect a badly out-of-focus, clouded, or misaligned sub. This detection should then trigger a FAILURE and a RESTART of the job. Alignment, Focusing, and Guiding would appropriately then SAVE THE REST OF THE NIGHT rather than mindlessly churning out dozens or hundreds of bad subs.

PLEASE consider USING the existing functionality of StellarSolver and the Analyze module in the Scheduler to get imaging back on track when low-level processes fail.

I understand and endorse the idea that failure should also be detected by the focus and guide modules, but the Scheduler should have the last word, calling a job failed even if no failure is reported at the lower-level.

Finally, THANKS for all the amazing hard work on this community project!

The following user(s) said Thank You: Sergio, Wolfgang Reissenberger, Hank
Last edit: 1 year 7 months ago by Scott Denning.
1 year 8 months ago #80174

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

  • Posts: 1105
  • Thank you received: 335
Fully agreed! Such a feature is quite high on my priority list as soon as the current refactorings have made good progress. The problem is that we also desperately need some code cleanup before adding more and more features, and the scheduler is already awfully complex.
ONTC 10"F4 Newton + FSQ-85 + epsilon-160 + FS-60CB + Dobson Factory 12" Voyage + TSA-120
Avalon Linear + M-zero + AYO II | ASI 6200mm pro + 294mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC
How to submit logs
The following user(s) said Thank You: Sergio, Scott Denning, Hank
1 year 7 months ago #80178

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

  • Posts: 402
  • Thank you received: 154
I regularly have the same sort of issues so would welcome some improvements as suggested in the OP. Would also be worthwhile IMHO, if the Scheduler is going to get some love, to consider exposing some of the logic via a Rules Engine to the end user. This way, the user could have more control over the scheduler, with for example, post-sub analysis and logic. Higher level logic such as a 3min sub not completing in 10mins could trigger further logic to, for example, reboot guiding or restart the schedule.

I understand retrofitting something like this into an existing complex codebase would be a very large task but would result in the power of the Scheduler going up a level, and it would put some of that power in the hands of the end user to tailor to their setups, weather conditions, etc.
1 year 7 months ago #80211

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

  • Posts: 938
  • Thank you received: 92
A work-around is to set a job for say, 6 frames and hit the scheduler 'repeat for' button. That triggers an align every 6 (or whatever) frames. If it's really cloudy, lower the number of frames.
Cheers and HTH.
lubuntu 22.04
700d, eqmod, 120mm
The following user(s) said Thank You: Wolfgang Reissenberger, Hank, John
Last edit: 1 year 7 months ago by alacant.
1 year 7 months ago #80222

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

  • Posts: 196
  • Thank you received: 26
I have the exact same problem and struggling to find a workaround for it. I have also added the Openweatherapi to warn of impending clouds but that doesnt always work. So short of having your own weather station or separate camera looking for clouds there doesnt seem to be a way around this :-( Atleast not one that I know of.

I will be a happy man when the scheduler has better control over error trapping and images stored remotely!
SW130pds on HEQ5 Pro mount, ZWO ASI533mc pro, 30mm guidescope with ASI120mm mini. All managed using Kstars/Ekos on RPi with Astroberry build.
1 year 7 months ago #80230

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

Time to create page: 0.468 seconds