Suggestion: Trigger to Auto-Focus if HFR Exceeds a Specified Value

[Bill Richards]

As I was imaging last night, some wispy high clouds passed over my target causing my HFR to increase which in turn triggered an auto-focus (I had a trigger set to initiate an auto-focus if the HFR increased by more than 7%). Since the stars were obscured, the auto-focus settled on a position that was sub-optimal, and imaging resumed. The clouds quickly passed but since the new HFR was much higher than the original “cloudless” HFR, a new auto-focus was never triggered and I was left with nearly an hour of useless images (which would have been much more if I had not woken up and checked on the status of the session). See attached image of PixInsight SubFrame Weighting plot of FWHM.

That made me wish there was a way to trigger an auto-focus if the HFR ever exceeds a specific value instead of a percentage. If the auto-focus fails to achieve the desired HFR value, it could keep trying - either indefinitely or for some specified number of times. That way, once the clouds pass the auto-focus would achieve an acceptable HFR and allow imaging to resume. If the clouds don’t pass, there’s no point in continuing to image anyway.

I’m not a huge fan of auto-focusing every N frames or every X minutes because it is often unnecessary, resulting in lost imaging time and sometimes landing in a position that was worse than where it started. “If it ain’t broke, don’t fix it”. The HFR percentage trigger is great, but it doesn’t handle the passing cloud situation as described above - only a “not to exceed” HFR value would address that case.

I realize that the HFR value changes depending on the equipment used, target being imaged, and environmental conditions. But once everything is dialed in, my HFR normally keeps to a fairly tight range unless clouds roll in. It would be nice to have a means of handling a passing cloud or two that only obstruct the target for a few minutes.

[Ruediger]

I suffered from the same effect. Lost one complete set of exposures shot with one filter. Next filter change triggered then an AF, which corrected the wrong AF before.

Maybe also a fuse in AF routine could prevent this: if new AF result for the same filter is worse and exceeds a percentage thresholds it switches back to old AF position and discards the AF run.

[George Hilios]

I strongly recommend having at least one AF after X time trigger as a failsafe for exactly this sort of situation. We do have a feature to ensure HFR improves before and after an AF run is complete, but if you have clouds throughout the entire process you could still slip through this.

I’m not a big fan of the “AF automatically if HFR > fixed threshold”, because a single bad sub could trigger an AF routine. Some thought went into the HFR increase trigger to handle rolling averages etc, but even with that it’s flakey when seeing conditions are unstable.

[Bill Richards]

A single bad sub is exactly what triggered the AF in my case, and the result was a poor focus for an hour before I noticed it reran AF to correct it.

I used to trigger an AF after a specific amount of time but found that it rarely improved my focus and just wasted imaging time. I have an Esprit 100 refractor so my focus rarely changes much over the course of a night and often improves as the skies grow darker and atmospheric turbulence subsides. So forced, periodic auto-focus actions rarely improve anything and can sometimes make it worse if it doesn’t settle in exactly the right position.

So I prefer to do an AF only when absolutely necessary and right now that’s when the HFR increases by 7-10%. But if the result of the AF is much worse than where it was before, I would like it to keep trying until it gets back within an acceptable range. For whatever reason, that didn’t happen last Monday night - a small cloud passed over, AF was triggered, it landed in the wrong spot, and never returned to the previous AF position. And I lost an hour or more of good imaging time with a poor focus.

[George Hilios]

Can you share the saved AF report? In such circumstances I’d rather attempt to address the cause of the issue (bad AF) than the symptoms (triggering a refocus because of a prior failure)

[George Hilios]

Lastly, I understand you don’t want to do it based on time, but my recommendation still stands - this is an effective insurance policy. Setting it to something large like “1 hour” means it’ll run AF if nothing else caused it to run in the past hour. If you enable “Validate HFR Improvement” (if you’re using Hocus Focus, for example) than the AF routine will take an extra image before and after, and restore the previous position if HFR didn’t improve.

[Bill Richards]

I cannot seem to attach the NINA log file - the attachment button isn’t showing in the menu. Sorry for being an idiot - what am I missing?

[Bill Richards]

I posted it here.

[George Hilios]

Bill, you can find AF reports located in %LOCALAPPDATA%\NINA\AutoFocus. The file names correspond to the dropdown box in the AutoFocus tab for loading previous AF runs. I’d like to see the AF run that happened in the middle of the night that put you out of focus for a long while

‌

[Bill Richards]

I uploaded 3 AutoFocus reports: the one before at 21:32, the one that landed at the wrong position at 22:36, and the one where I corrected it an hour later at 23:22.

[George Hilios]

Thanks Bill. After seeing this, it looks like a single sub pulled the focus point away, but not by a large enough amount to cause an outright failure.

What is your minimum R^2 set to? I’d also recommend changing from parabolic to hyperbolic, based on the shape of that curve.

One feature I’m considering adding is outlier detection, which could run a statistical test to throw out individual points. I’ll use this data as a test case.

[Bill Richards]

My R^2 value was set to 0.7 (default) at the time, but based on things I’ve read and some YouTube videos, I changed it to 0.9. Please let me know if that is appropriate or if I should use something else. I’ll change to hyperbolic per your advice.

But something triggered an auto-focus at 22:36, right? I thought that was the one bad frame resulting from the passing cloud, no?

[George Hilios]

Depending on your settings, periodic clouds can trigger an AF run. Normally, that’s okay - the actual issue here is that the focus run landed you at a position that left you out of focus. By updating your settings to ensure the focuser is moved only during high confidence, you can reduce the chance of this happening. Then you wouldn’t even need the feature you’re asking for (AF if HFR > X )

I suggest looking at your AF history. Depending on the consistency for your setup, you may be able to increase the R^2 threshold even more (say to 0.95)

[Bill Richards]

I downloaded and installed HocusFocus and used it for the first time tonight. I’ve only scratched the surface of the tool but it seems to work pretty well. I confirmed that my EAF backlash is 130 in both directions, and I changed my step size from 30 to 50 to get a larger parabolic/hyperbolic curve. Most of the time, I got pretty good results, but the curve was asymmetrical on a number of the runs and I don’t know why. I’ve confirmed that there are no cable snags or pulls; just in case, I loosened the harnesses and that didn’t change anything.

All the AF log files are here along with a photo of the rig and cabling.

[George Hilios]

What kind of scope do you have that produces the asymmetric curves? Could you save an AF run for me please? It'll save every image taken to calculate the focus.

[Bill Richards]

SkyWatcher Esprit 100

I just came in for the night. Everything has been disassembled and tucked away. I normally don't have a symmetric curves. This is the part that is puzzling me. I don't know why that just started.

But for future reference how do you save an autofocus run? I've never done that and don't know how to do it.

[Simon Kapadia]

If you are using the focuser that came with the Esprit, it’s likely that it is physically slipping, which leads to asymmetric curves. I recently got an Esprit 100 and it’s taken quite a while to dial in the focuser so that it gives consistent results. You need to find the distance it needs to be for infinity focus, and then tune the focuser using the grub screws on the sides (above the focus rings) and the top (linear power rail) and bottom (rack and pinion) so that it works perfectly repeatably and is buttery smooth for exactly that portion of the focuser. It’s possible to do (I now get wonderfully consistent focus curves) but a real pain to get there. You can also buy your way out of the problem with a feathertouch or moonlite

[Bill Richards]

I have a Pegasus FocusCube 2 and it’s set to half speed (full speed was definitely slipping). Normally, my AF curves are pretty symmetrical, but occasionally they are not.

[Simon Kapadia]

If it slipped at full speed, it’s still slipping every now and again at half speed, you just don’t notice it — you only see inconsistent behaviour. I fought with this for a long while, as have others. Believe me, it’s worth investing the time to set it up well.

[Bill Richards]

I have spent hours disassembling and reassembling the FocusCube mounting to the telescope, ensuring the grub screws are biting the shaft properly and cranked down super tight. I’ve run many cycles of extension/retraction to ~5 inches and confirmed that it always seats right up against the telescope when it returns to the 0 position. I’m pretty sure that if there is any slippage, it’s insignificant.

[Simon Kapadia]

Actually tightness is not what you want for AF. Slippage with manual focus needs tightness — it has to hold the focuser in place even under load when pointing at zenith. With AF however the focuser is held in place by the focus cube being powered. The “slippage” that messes up AF is when the adjustment is too tight; the focus cube turns by some amount of steps but the focuser is too tight and doesn’t move by the same amount.

Note that this tuning needs to be done at the same temperature as your imaging. At one point I spent a lot of time setting the focuser up perfectly during the day, and then it started sticking at night!

[George Hilios]

Bill, in Hocus Focus Options → Auto Focus section, there’s a toggle to “Save” AF runs. When you enable it, you can input a directory. While that toggle is enabled, every AF will be saved. It takes a lot of disk space, so I don’t recommend leaving it on permanently. I’d appreciate seeing an example of the asymmetric curves to confirm detection is being done correctly.

The fact it is happening inconsistently does suggest to me this is hardware-related (ie, slippage).

[Bill Richards]

Here are a couple of Excel plots reconstructed from the AF logs from last night.

‌

[George Hilios]

Will you be able to get th3 saved af run next time this happens?

[Bill Richards]

Hi George,

Yes, the next time I have a clear night and set up the rig, I’ll run a few autofocus sessions and record everything.

[Bill Richards]

I spent some more time analyzing the 9 AF runs I did earlier this week. I wrote a Python script to read in the data from all the JSON files and generate a CSV file that I imported into Excel, then used the data to reconstruct the AF plots. I also generated chart that shows the AF solution vs time.

Overall, the “V curves” don’t look too bad. There is one exception (Run #6) where I experimented with the backlash setting (changed it from 130 to 300), which yielded ridiculously bad results. After setting the backlash back to 130, the plots returned to looking more normal.

The last plot below(AF Solution vs Time) is interesting if you ignore the outlier points resulting from my errant experiment with the backlash value. The computed solution shows a steady decline in the ideal focus position. It was unseasonably hot that day (95F/35C) and the temperature dropped quickly so the telescope could have been cooling. It was sitting in my hot garage all day so it was likely warmer than the ambient temperature when I started the AF runs (22C at the first run and 20.5C at the last). So cooling could explain the steady changes in the AF solution.

It’s also possible there could be some AF slippage, but when the FocusCube slips you can hear it - there is a very audible clicking sound, and I heard nothing but a smooth humming all night. Nevertheless, if my logic is correct, a continuously lower AF solution means that if it is due to slippage and not cooling, if would be happening during the AF retraction. [My logic: if the ideal position is 25 and the AF moves to 20 (retract) and slips 1 tick, then the focuser will actually be a 21 while it thinks it is at 20. Then it has to move 4 ticks up (extend) to get back to the ideal position of 25, but now it thinks it is at location 24.]

In any case, this is off-topic from the original post, and I’d like to get back to that. What caused the AF routine to pick the wrong solution last week and remain there if the HFR result was far worse then the prior AF run? And how do I prevent that in the future? Note that I was not using HocusFocus at the time (I am now).

‌

[George Hilios]

Bill, do you use Overshoot backlash compensation, or absolute? For overshoot, I would definitely not expect it to get worse if you increase the backlash amount.

Regarding your last question - I believe setting a high R^2 (like 0.95) along with HFR validation in Hocus Focus will give you a lot of insurance against that happening.

[Stefan B]

I would also recommend a focuser settle time of 1s when using backlash compensation, if not set already.

[Bill Richards]

George - I use Absolute backlash compensation, set to 130 in both directions. I arrived at this value by methodical testing - On a clear night, I achieved good focus manually, then moved the focuser out 200 steps. Then I moved it in 10 steps at a time until the HFR began to improve. That happened at 130. I repeated the process several times with the same result. Then I did exactly the same thing in the opposite direction and got 130 as well.

Stefan - Noted, and changed.

[George Hilios]

Bill, I think your AF will be much more reliable if you increase backlash to 300 and enable overshoot. It’s much more foolproof.

[Bill Richards]

George, I’ll take any expert advice I can get, so thanks for that. But I never understood the overshoot option. If it overshoots, how does it know how far to come back before it’s in the right position?

Also, I’ve seen conflicting advice online about whether to define the overshoot in one or both directions, and if only one, then which direction is better?

Lacking an understanding of how this feature operates, I’ve avoided using it for fear of making matters worse.

[George Hilios]

There is an excellent animation in the NINA Discord that is activated by typing “!overshoot”. The basic premise is that you go far past where you expect the backlash to be, and then go back the amount you overshot by. As long as each movement exceeds backlash you will end up exactly where you should be.

See the documentation here: https://nighttime-imaging.eu/docs/develop/site/advanced/backlashmeasurement/

Direction typically doesn’t matter, but for some setups can be useful. For example, the documentation calls out SCT and setting a direction to minimize mirror flop.

[Bill Richards]

Hi George, that overshoot video was very helpful; I now understand how it works and will give it a try.

[Bill Richards]

Hi Geroge and Stefan,

I wa able to test the overshoot method last night and it worked flawlessly. I achieved better and more consistent focusing than ever before. Thanks for your guidance on this matter. You guys are great.

Best regards,

Bill

[Stefan B]

Removing version: 1.11 Nightly (automated comment)