Hi Jarno; I'll send you a PM to consider. Thanks, and cheers, Doug

I wonder if the original programmer doesn't use a long focal length scope.  The issue seems to be with seeing effecting very local lengths.   With my C11 I have NEVER been able to get consistent HFR values - even when I don't move the focus and just keep repeatably hitting the button to recapture and measure the HFR.  I typically get values like 2.56, 2.35, 2.61, 2.4..   it jumps around 0.20 t 0.40 points constantly.  I have tried fir two years with every suggestion, but unless I take 30 second exposures, or average 10 images - the values are never stable.  Thus, the current routine is not usable as it simply stops at a spot is 90% of the time off from the perfect polynomial calculated spot.   NINA is MUCH better as it ONLY selects the calculated spot.  

I have to wonder why EKOS goes through the trouble of calculating the perfect ficus spot - only to toss it out and use the last HFR change value instead.  In my system that is virtually always wrong, so I have to go back in and manually move the focuser back to the calculated value is always correct.  I have tested this many many times by looking at enlarged images taken after several minutes and the difference between a calculated focus spot and the selected one is very noticeable.

I am so glad though that I am not the only one that has seen this.  It is a consistent flaw in the system in regards to my optical setup and the ESATTO, and prevents any automation being

On a side note - while INDI allows me to set the ESATTO's backlash to a value over 1000 steps, EKOS rejects that value and limits me to only 1000 or less.  The Esatto has 420,000 steps - so a value of 1000 is not too large to consider.  Maybe whoever limited EKOS to only 1000 steps of backlash may be using a different focuser - where 1000 seems excessive.   In the ESATTO, I cannot see any focus difference within 1000 steps.

Same here. When I use my 10" RC or my 9.25 EdgeHD I get HFR values that are larger than my lower F number scopes. HFR is directly related to Focal Ratio. The larger the Focal Ratio the bigger the HFR values.

But I do get inconsistent HFR values, I end us using the 2 or 3 frame average, this makes focusing 2 or 3 times longer, but at least I get somewhat good focus.

I do agree that the Focus routine works much better at 200-600mm Focal Lengths, once you start going deep, focus becomes more problematic.

Yes it is problematic, but the calculated values are virtually always spot on. EKOS does a great job at calculating that curve and identifying the best focus spot. It just refuses to use it! And the really annoying part is that it can get that calculated value in about 6 exposures, but then goes on for 15-25 more exposures to only end up choosing the wrong one! What should have taken a minute now takes 10 minutes and then I have to go back in and manually move it anyway.

I would like to try your code. Where can I find it?

Hi Andrew, I sent you a PM..... check your forum email. Cheers, Doug

Ok

You wrote to me that " As a result, when an HFR measurement rises above the prior measurement while in the tolerance zone, he felt that measurement should be trusted, even over the set (possibly as many as 29) measurements."
Yeah, I would not agree with that statement either! All things being equal an HFR measurement taken at the same position should always honour the lowest value, as we can reasonably conclude that atmospheric distortion will only ever make things worse.

I am willing to fund an issuehunt.io to fix the focus problem.  I would really like this issue fixed.

Thanks.
 

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.