Peter,

Thanks for the explanations!

Good to hear on the backlash... as you say, it shouldn't really matter with linear.

On focus with a SCT... I can understand the difficulty with the focusing mechanism. For me, it's all the more reason to keep it simple. First form a good curve on the first pass, then move out a large amount and back to that position.

On the polling time... This may be where I'm having issues. Mine is set at 1,000 ms (1 sec). Based on what I hear when it moves out and then moves in, it is nowhere near a 1 second delay. I'll need to check the messaging to see if it reports reaching the position. Next time, I'll try an exaggerated polling time (like 3,000) to see if I can discern a true delay.

Thanks again!

Ron

What I have found is that if the focuser was already near the best focus point to begin with, then the first pass (linear) calculates the best focus point quickly. The second pass is often worse. I don't know why.

But if the focus was off by a little, then the first one will get very close, but not perfect. Then, a second run of the Autofocus will nail it on the first pass.
But this is different than just letting the autofocus run two passes. With two passes in one run, the results are not consistent. Stopping the autofocus, and then restarting it after that first attempt is always better.

In all cases - the current routine always stops AFTER it detects an increase in HFR, but then uses that incorrect focus point instead of simply moving back to the best calculated spot and using that.

Peter, you nailed it! This is EXACTLY my experience. The 2nd run always stops too far on the "left side" and doesn't return to the point of best focus.

During the first run a vertical line is shown, together with a numerical focus position. Once the first run is complete, the vertical line and number show the best focus position IMO. Often times, after the first run completed, I just hit the STOP button, enter this number in the "desired absolute focus position" field and move the focuser there by clicking at the "go to an absolute focus position" button. Done!

Just to be clear Linear1Pass (L1P) is a new focus algorithm, so the existing algorithms will operate unchanged when L1P is released. So those happy with Linear or any of the other algorithms will be able to continue using them as they do now.

Linear starts the 2nd pass by going 2 * Initial Step Size further out than it needs to, to start the 2nd pass, then steps back in 2 * Initial Step Size and starts the second pass. If you have more backlash than this 2 * Initial Step Size then you might see a flat line at the start of the second pass whilst the remaining backlash is "taken up". Linear should be able to deal with this though.

L1P will operate like this if you set the Backlash field to zero. If its > 0 then the step out then in movement will use what you enter in the Backlash field, so you'll have a bit more control over it.

L1P will also compare the HFR prediction from the curve fitting process from pass 1 with the HFR measured after the focuser has moved to the solution (and an extra subframe taken and processed). It will put out a log message comparing the expected vs actual HFR. You will also be able to compare the 2 values on screen (the curve fitting prediction on the graph and the measured HFR in the HFR box under the curve.

Before L1P goes live you could compare these values for the existing algos by doing an Autofocus run and getting the HFR at the optimum focus point and noting the HFR. Then when Autofocus finishes, hit the "take a subframe" button, let the processing complete and see what's in the HFR box at the bottom of the graph. There will be some randomness so the numbers will never match exactly but will give you a feel for whether there's an issue or not.

The Linear 1 Pass focus algorithm has been merged into the code base and is now available in the nightly builds so if you are able to take the nightlies then you will be able to give it a go.

I have updated the document detailing the changes. It includes a section with suggestions on how to use it.


I'd be interested in any feedback. If you find a problem please send a log with "focus" messages enabled.

Nice work! It will be nice to see this included in the baseline. I've sent you a PM on another focus related subject that might be of interest. CS Doug

Does anyone know if this nightly update is available for Mac OSX as well?
EDIT: I just saw that it was indeed included in the latest Mac OSX nightly build. I will test it as soon we get a clear night.
It's monsoon season now here in NM.

Hi Peter,

This link is helpful for Mac nightly builds:
indilib.org/forum/ekos/11408-announcing-...-on-macos.html#83666

As you're probably aware the nightlies include the latest versions of s/w which may / may not work. I spent a few minutes with Build #1560 which appears to work from an L1P perspective. The latest version Build #1563 has problems with memory allocation somewhere and won't take any subframes so is unusable. Sure this will be fixed quickly.

Wow, this new algorithm fits perfectly what I was proposing here only 4 months ago (and you also had already in your mind by then) and even more that I didn't think of!! (different curves, weighting by HFR stdev, ...) Last night I gave it a try and it went quite smooth! I can afford to make focus exposures longer to get better SNR and even so, autofocus takes way less than before. Thanks so much for your effort, for me this is quite an improvement.

Playing with the parameters I occasionally ended up with a failed autofocus, that was quite expected as I pushed some of them. But although the log reflects the failure, it doesn't show why it failed:In this case, I guess it didn't meet the minimum R² I configured, but I think it would be desirable if the failure reason gets logged.

Also, the Analyze tab didn't plot any HFR measurements in the graph, and "Iterations: 0" is shown under Details (in the log I see that this particular autofocus run took 9 HFR measurements).

Thanks again!

Thanks very much for the feedback Sergio. If you configure logging like this:


Then you'll get all the focus related messages. For an R2 failure you should get:
2022-06-26 12:49:09.983722+0100 kstars[11402:2349276] [org.kde.kstars.ekos.focus] "Linear Curve Fit check failed R2=0.999893 R2Limit=1 retrying..."

After the rerun you'll get something like this...
2022-06-26 12:50:00.620048+0100 kstars[11402:2349276] [org.kde.kstars.ekos.focus] "Linear Curve Fit check failed R2=0.997972 R2Limit=1, but continuing..."

I suppose your point is that it could be a bit more obvious as to why the rerun happened (as opposed to having to go hunt through a detailed log file). Good point, I'll have a look at this.

In the Analyze tab you should get a focus entry for each autofocus run. If the run is successful it should log all the datapoints. If it fails, it will log the fact that there was an autofocus run but not the datapoints. L1P just fits in with the existing Analyze workflow here. This is how it works for the existing focus algorithms.

If you post the log here I can take a more detailed look.

Thanks John for your prompt answer. Truth is I even didn't think of enabling the debug logs... I was expecting these messages to appear in the status (bottom) panel of the Focus tab.
Yes, in the Analyze tab I do see the successful runs correctly. Sorry I didn't compare the failure case with the other algorithms, of course you're right.
Thanks for your time!

I've added the R2 fail messages to the status panel. I need to go through the other msgs and review where they are going. I don't know how long it will be before this gets into the nightly builds.