> Re your 2nd question:
> I think the awkwardly named "out step multiple" in the Mechanics subtab is what you're asking for.
> Please feel free to suggest a better name.
I observed (not sure if I got it right) that the first outward movement seems to be equal to (out_step_multiple+5)*initial_step_size steps, then followed by a inward movement of 5*initial_step_size steps, so the complete outward+inward movement has a net outward shift of out_step_multiple*initial_step_size steps.
So I understand that this initial outward "overshoot" of 5*initial_step_size is a backlash compensation, is that so? In that case, the '5' value is configurable anywhere?
> Re your first request:
>
> - Are you saying that you have no issues with backlash (backlash is the reason for the 2nd pass),
> but still prefer Linear over Polynomial? Please explain.
Backlash is an issue but somewhat alleviated by my focuser internal backlash compensation. So if I do many changes in direction, the position error due to backlash may increase; but if there is no much back and forth, positioning seems to be quite acceptable. In my case the polynomial algorithm takes a few samples and then quickly finds a solution, but it's not very reliable, in part for the back and forth movements, but I think that mostly for the lack of proper sampling.
Linear does a very good sampling even in the first pass (also I can control the sampling with initial_step_size).
> When you say: "jump to the computed solution after first pass" (with compensation) if curve fitting is good enough.
> I don't really understand: "if curve fitting is good enough" and "with compensation".
Sorry for not being specific. By "compensation" I meant "backlash compensation" (like the first movement of the linear algorithm). So this final "jump" would be in the outward direction past the computed solution, then inward, to fall exactly on the computed solution.
"If curve fitting is good enough": I was guessing that the computed solution is derived from a quadratic regression over the samples. If that is the case, a goodness-of-fit metric, such as R-squared, may indicate our degree of confidence on the computed solution after the first pass. To be fair this involves an arbitrary threshold to specify what is "good enough" (R-squared should be greater than some arbitrary value). If the metric doesn't reach the threshold, maybe just flag the autofocus as failed (for the user to tune parameters in "interactive" sessions / rely on the scheduler error handling in automated sessions).
> BTW, how long do your focus sessions take? In my experience (ASI1600 on RPi4) I was usually completing
> the autofocus in under 2 minutes. It's true that that's time one could be capturing, but the flip side is if you rush
> things, then you might wind up with an hour of wasted images.
In my case, focusing is about 4 minutes in average. I image from an urban location with narroband filters and a USB2.0 CCD. Each focus exposure has to be somewhat long, at least 3-4 seconds to get enough signal to work with, and download time (bin2x2) is around 8 seconds. Currently (v3.5.6 and 3.5.7), the linear algorithm takes about 20 iterations in average.
> In any case, I'm open to suggestions/discussion.
And many thanks for that!
Sergio