I have updated everything and it shows "v3" and I still get errors in the log:
[2020-01-22T19:28:27.334 CET WARN ][ org.kde.kstars.ekos.focus] - Focus GSL error: invalid argument supplied by user

I also get these:
[2020-01-22T19:28:27.354 CET DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2020-01-22T19:28:27.354 CET DEBG ][ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ).
[2020-01-22T19:28:27.355 CET DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2020-01-22T19:28:27.355 CET DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded

The V-curve looks kind of strange, with two sets of points at the same two x-values. It also writes only
2020-01-22T19:39:27 Focusing inward by 1250 ms...
2020-01-22T19:39:24 Focusing outward by 2500 ms...

in the log window. It does not change these values (initial step is 250, but I think it would be better with a larger value. But then I get errors from fcusb like Error: Invalid range for FOCUS_TIMER_VALUE. Valid range is from 0 to 5000. Requested value is 20000").

And it does not converge.

Polynomial focusing seems to work OK.

Can you please include the log and I'll have a look?

Also let me know the kind of telescope and focuser you're using.

BTW, is yours a timer-based focuser (which focuser is it)?
I've recently discovered that there is an issue in the V3 algorithm with timer based ones.

Thanks,
Hy

The logs simply repeatedly displays the messages I have shown above, I dont think you will get much more out of it...

Yes, it is a timer based focuser, fcusb focuser, so that may be the issue.

Let me know if I should try something specific next time.

Got it. OK, I just sent Jasem the fix I had asked Jo to try out with his FCUSB. May as well have it in the nightly for others to test, as I'm pretty sure these FCUSB focusers won't work with the linear algorithm the way I wrote it.
If/When you see v3.1 as the linear focus version, you'll have my change and can test again. I'll try and email out on this thread when I see that this change has been pushed.

This is the same focuser I am using, Hy, so it might be informative to compare the logs from the different sessions. It is interesting that 'The V-curve looks kind of strange, with two sets of points at the same two x-values.' That is also what happened to me sometimes, but not all the time. Obviously, that would mess up the calculation of the curve.
Your revised version of the algorithm may already have taken care of that. I will test once the clouds are gone here, but currently it does not look promising for the entire next week.

Jasem pushed the change phabricator.kde.org/D26854 it looks about 12 hours before I'm posting this message. So, it's currently in the latest source code, and I'm not sure if it's in the nightly build now or will be tomorrow .
Let me know what you think.

The "two sets of points at the same x-values" issue is not surprising, given that for timer-based focusers like the fcusb, I believe the x-values were wrong, and often not changing without the most recent fix.
Hopefully this won't happen anymore. I don't have one of those focusers, so it's hard for me to test the change without your help.

Hy

Great! As I remember, the x values were in the order of 5000, so very far from the other focus algorithms. Sounds like you are on track.

I will test as soon as I get some stars. Next two weeks seem completely cloudy though. Fortunately, the metrologists are often wrong

Hy,
The latest focuser algorithm (v3.2) works GREAT with my analog 3D printed focuser based on the Shoestring Astronomy FCUSB focuser.
This is what I get with a 135mm Nikkor lens attached to a cooled ASI183MM. I have a deep red filter in the lightpath, which includes Ha, S2 and extends into the infrared.



This is what my rig looks like (taken this morning after a night of imaging using a 55mm Nikkor Macro lens).



Simple solutions, great results.

Happy to share the STL files for the 3D printed rig, if anyone is interested.

Jo

PS: Here another image of the Linear focus routine, v3.2, this time using SEP, not Centroid.

Thanks for writing this code, Hy!
It is very fast and works great with such a simple focuser. Takes care of common backlash issues.
Jo

Thanks Jo.

For everyone:  I'm happy to continue iterating and improving this scheme, but at this point have implemented most of what I planned. If anyone has autofocus issue with this algorithm, please send debug logs my way. Please also let me know if it does improve AF where previous focus algorithms didn't perform well.

FYI, the way I've been using autofocus (4" WO f/5.6 refractor with moonlight 2.5" focuser stepper motor and V2 controller) is:

• Step size of 25 (that's definitely focuser dependent)
• SEP detection algorithm (haven't carefully compared, but the HFR computation looks better to me this way)
• Full Field HFR measure with annulus of 20% & 75%.
• 5% tolerance
• Max Travel of 400 (probably irrelevant, but don't make it too small)
• no backlash compensation (the moonlight focuser driver doesn't support that anyway.
• 2x2 binning and 3s exposures for RGB and 6s for narrowband gain 200 for my zwo ASI 1600mm

Make sure you have logging set to: Verbose, File, and have at least Focus and Capture set.
Hy

A quick (I hope) question.
The name implies that the focus algorithm is linear but the display seems to show that the points are fitted to a curve. That looks more like the polynomial method to me.
I'm not objecting, some sort of curve fitting seems better to me because it uses more information.

Chris

I intuitively had the same thought initially. I believe the curve is naturally hyperbolic, but can be fitted near its minimum with good approximation using a polynomial algorithm. To obtain that curve and thus the calculated minimum, Hy’s algorithm will first focus out from a position near optimal focus by 10 steps, then move in by 5 steps (to fully engage the gears and removing backlash), then move past the starting point by 5 steps. The HFR values measured at each step are then used to calculate the curve (from watching it perform, I think that calculation is done after each step move). Then the algorithm will move back OUT past the minimum again and then move IN again using smaller steps toward the calculated minimum.

So the movement during which HFR measurements are taken always proceed in only one DIRECTION.
The advantage is, that this minimizes backlash error, as the gears are always fully engaged. By contrast, the “polynomial” method uses movements in AND out once it has calculated the minimum, which would yield the same result, IF there is no backlash.

So, I think you are correct, both methods use polynomial fitting to a hyperbolic curve, but the original “polynomial “ method uses a bidirectional iteration towards the minimum, while Hy’s method uses a UNIDIRECTIONAL linear iteration which eliminates backlash as a variable.

Perhaps the algorithm should be renamed to ‘Unidirectional’ to avoid this confusion, but Hy should weigh in on that one (and also on whether my account of how I think his algorithm performs is factually correct).

Jo