×

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

Bi-monthly release with minor bug fixes and improvements

Adding option to enforce guiding (and align) to improve focus modul

  • Posts: 8
  • Thank you received: 6
Hi,

Using the autofocus routine to get an accurate focus can be difficult and slow for users with long focal lengths and slow focal ratios. There seems to be an easy solution that requries two additional checkboxes in the focus module.

When manually controlling all the modules, I can get the autofocus modul to find the perfect focus very reliably. This requires me to run the autofocuser while guiding is active. (Otherwise tracking imperfections cause issues with determining the correct star size). Also, autofocus works much better if I move to a bright star or rich starfield, instead of using the random dim stars around my DSO-target. To reliably get the specific star or starfield I want into the FOV, I need to do a plate solve before starting the autofocus routine. (I imagine a lot of users with long focal lenghts and slow focal ratios can improve their autofocus by doing the same.)

To automate this in the scheduler, I want to add a "fake" job before the actual imaging, that slews to my prefered bright focus star, runs a plate solve to center it, activates guiding to keep everything steady, and only then starts the autofocus routine. (The "fake" job then runs a short and almost empty placeholder sequence). Only then I found a reliable focus and can move to my actual DSO-target in a second "real" job.

Setting this up is currently impossible in the Scheduler, since the order of the four steps "Track, Focus, Align, Guide" is fixed. I have to find a compromise by using two "fake" jobs:
1) "fake1" job on bright focus-star: "track", "align"
2) "fake2" job on the bright focus-star: "focus"
2 "real" job on the DSO-target: "track", "align", "guide".
But even this compromise is not correctly working, because I am not guiding while focusing. (If I add "guide" to the first "fake1" job, it will automatically deactivate before the second "fake2" job ist startet).

A solution to this doesn't necessarily has to be implemented in the scheduler. There might be an much easier solution:
Currently there is already the checkbox in the focus modul "Suspend Guiding during Autofocus". Two similar checkboxes in the focus modul ( "Enforce Guiding for Autofocus" and "Enforce Alignment for Autofocus" ) could automatically run an alignment on the target and start guiding before starting the autofocus routine.

(Not important: Since I am refocusing like this every hour (slewing back and forth between my target and the bright focus-star close by), the job list in the scheduler gets full and confusing very quickly, but that doesn't bother me. A possible solution to make this method "focusing on an optimal focus-target instead of your DSO-target" easier to use or accessible would to implement it directly in the focuser modul. Then it would automatically move to the specified focus-target whenever an autofocus is triggered. In the Scheduler, one could define the focus-target independently for each job. For example the Job for "M1" would allow the user to input their prefered focus-target "Alnath" or "Tianguan". For a different job later that night, they can define another focus-target to minimize slew between DSO-target and focus-target. Default focus-target would of course be just the actual target of the job, since that probably applies to most users (and corresponds to the current behaviour of Ekos.)

What do you all think about this? Would you see the two proposed checkboxes as improvment to EKOS, or as something uneccessary that would cause issues when implemented?

Regards, Elias
The following user(s) said Thank You: Jasem Mutlaq, Magnus Larsson, Eric
4 years 4 days ago #51155

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

Thank you for the feedback... would adding a focus target make sense? i.e. once it gets to autofocus, then it slews to the focus target, and once done, it slews back to the original target?
4 years 3 days ago #51200

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

  • Posts: 1029
  • Thank you received: 301
See my reply to "For this with focus issues". I investigated that part and realized it would be far simpler for users to have a wizard in the scheduler than to add a specific target in the capture sequence. This also pulls more dependencies in the Capture module, while we should maybe be reducing them...

-Eric
4 years 3 days ago #51214

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

  • Posts: 1029
  • Thank you received: 301
(don't get me wrong, I agree with OP, we need a solution and the proposals are really good, but it appears we really need to think it out)

-Eric
4 years 3 days ago #51215

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

  • Posts: 8
  • Thank you received: 6
Thank you for your responses and feedback to this suggestion. To summarise and clarify these seem to me to be two more or less separate points:

1) Having the option to add a specific focus target for any job. From a users perspective, It seems to make most sense to place this option in the scheduler, after I select the target and sequence. Whenever it comes to autofocus, the mount would slew to this target, and then slew back to the imaging target afterwards.

2) Having the option to enforce align and/or guiding before autofocus. Choosing a specific focus target makes little sense, if it isn't ensured by the align module to actually be in the field of view. And starting guiding before autofocus can allow for longer exposures while autofocusing (most focusing issues seem to be from not high enough SNR on the stars). As a user, I would expect to find this option in the focus module, next to where I can find the "suspend guiding while focusing" option.

Stay healthy everyone, Elias
4 years 2 days ago #51240

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

  • Posts: 1029
  • Thank you received: 301
I agree, and my intent in the scheduler would be to make the order of steps completely arbitrary. However, in the current code, we're at the limit of what we may implement without introducing regressions...

-Eric
4 years 1 day ago #51322

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

Time to create page: 0.670 seconds