Hi Sonny, one of us doesn't understand. If you have a build environment, you can fix this yourself (I can send you a small code fragment that will do it). No need to pay anyone. If you don't have a build environment, but you're willing to pay to get this fixed, wouldn't it be better to just acquire your own build env with the fix? Finally, if you have neither the desire nor feel comfortable building the SW, you're stuck trying to solve a political problem of changing the developer's mind and/or getting the decision overridden by Jasem and/or others via GIT. There's no technical problem here....just politics. If you go the DIY build route and want the code fragment, send me a PM and I'll help you get past this "feature". Cheers, Doug

I wonder why the developer is so against fixing a problem that affects users with our specific set ups? If he spent one hour on my system he would quickly see there is an issue, and you’ve already done the hard work of solving it.

Hi Peter, this isn't about any specific setup. It's about a general failure to understand basic principles (e.g. averaged sampling, polynomial regression, and flawed reasoning regarding a single seeing affected HFR vs the entire autofocus measurement set). The developer has a fairly long focal ratio instrument (wide CFZ), so is less affected by poor final position than those with short focal ratios (narrow CFZ). As such, getting close was "good enough". Precision was never the goal. This is all-too-often a trademark of amateur / hobby development. All I can say is that it's fruitless to continue this discussion here in the forum. You (and others similarly affected) should send Jasem a PM if you feel strongly about having this finally fixed.

I can build on Linux, and I have a GitHub account as well. I cannot build a windows build, I get those from binary-factory (Jenkins).

I use the windows environment on my Home PC connected to my scope via Ethernet to an Ubuntu Build outside.

I have created an issue for this. I will keep you guys updated on its progress.

I would like to get a copy of your fix, I may run ubuntu inside instead of Windows to fix the focus issue for me.

Thanks!

Hi Sonny, I sent you a PM. We can deal with any questions via PM from here. CS Doug

Can I somehow specify the maximal number of steps during focusing? I am using Linear algorythm and yesterday something goes wrong. The focuser was focusing more thant13 steps during first set of steps (before changing to half step size). The V-curve was no more a V-curve as the HFR after 6th step turns lower. It seems that I have accidentally changed one setting in my DeepSkyDad AF3 focuser driver: step size from 1/8 to 1/2

I always get the same issue - in that EKOS calculates a good curve after 6 or 7 steps, but for some reason it continues to do a dozen or more additional steps that are never needed.  
In this attached screen shot you can see that by step 6 there is a good curve,  But it continues on for 10 more steps in the same direction needlessly.  How do I fix this?  

 

  

This the same problem I have observed. Thank you for the screenshot Peter

I think "Out step multiple" set to 2 is too few: you have only two shots on the right-hand side of the V. Have you tried with a value of 3 or 4?
My two cents.

My setting for "Out step multiple" is 3. But I don't understand why there is 10+ iterations for first right-left cycle? Is it possible to made it more "inteligent" and once there is an obvious curve, the algorithm will do second cycle?
Based on screenshot from Peter, the second cycle could start right after 8th iteration has been done.

That's how Polynomial algorithm behaves. I suppose Linear algorithm needs more data points.

Thanks Jasem, I will then try to switch the algorithm to Polynomial