I also experienced this issue randomly a few times. I couldn't figure out why it sometimes happens. The easiest workaround is just to ALWAYS enable Timestamp (TS) in the filename for each sequence. Even if all frames have the same number 001, they still have different names because of the timestamp, so they won't override themselves.
I had very similar issues than you:
1.) The HFR values are "noise", so to get a reliable v-curve, I either had to use long focus-exopsures or averaging over many frames. This made autofocus very slow and not practical.
2.) When focusing with the full field, the different detection algorithms either detected to few stars, or to many "false" stars (noise, hot pixel).
3.) The the different focus algorithms move all very far out of the focus, so that eventually they don't recognize stars properly anymore. That gives completely wrong measurments for the HFR values at the edges of the v-curve.
All these issues prevented me from using autofocus automatically and without supervision.
I found a solution I am very happy with:
- Don't focus on your actual target, but focus on a bright star close to your target (really bright). (create a "fake" job in your scheduler, to slew to a bright star and focus, before slewing to your actual target).
- With a short focus-exposure time of 0.5 seconds, star detection "gradient", "Auto-select star" and "subframe", the algorithm reliably picks up the very bright star as the target to focus on. The short exposure time and the subframing means, that you can rapidly take many frames to get a more averaged (and less noise hfr measurments). (I average over 8 frames)
- The linear algorithm works best. Even if it moves far away from the minimum of the v-curve, the star is so bright that the algorithm still detects it reliably.
Because the v-curve is very clear and not noise at all, I can choose a tolerance of 0.5%.
With these settings, the automatic focuser works without intervention flawlessly and very quickly.
The only downside is the requirment to work with "fake" jobs in the scheduler, to slew to the bright focus-star of your choice.
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
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?