Hi all,

I'm looking at Ekos' periodic / in-sequence refocus functionality. Currently the following are supported:
1. Refocus after Meridian Flip - does what the name suggests.
2. Refocus every xxx minutes. Maintains a timer since last Autofocus and when the time's up the sequence is paused, Autofocus run, and the sequence resumed.
3. Refocus if temperature change > xxx C. Monitors current temperature vs temperature at last Autofocus and if threshold is exceeded, pauses the sequence, runs Autofocus and resumes the sequence.
4. Refocus if HFR > xxx pixels. Check every X subs on the focus HFR, compare to threshold and if above trigger an Autofocus.

(Note: I'm considering Adaptive Focus as something different to these items because the above items all have the potential to trigger an Autofocus whilst a schedule is active).

Points 1, 2, and 3 work I think well. If anyone has any issues with these please let me know.

Point 4... the implemented algorithm starts with the last Autofocus HFR but then calculates the threshold based on in-sequence focus frame data. I can see what the code does but I have to confess that I don't really understand why it does what it does. If anyone finds it useful and / or can explain what its doing that would be helpful.

I propose to change this algorithm in point 4 to allow a tolerance from the last autofocus (e.g. 10%) to be the threshold to trigger a new Autofocus. I think this is simpler and easier to understand. There are potential flaws in just relying on HFR drift to trigger refocus so I would value feedback on this from those with experience of it. For example, as you track an object through the night its elevation will change and independently of focus, the HFR will move. So should an Autofocus be triggered on a lower HFR and well as a higher HFR? Should 1 reading above threshold trigger an Autofocus or should there be a user tolerance? I think putting in a compensatory algorithm for HFR with altitude is probably going a bit far so there will always be false hits with this trigger, but if combined with other triggers, e.g. temperature or time, this functionality may still provide some useful functionality.

This trigger, as now, will be filter specific.

Once again, I'd appreciate feedback on this.

TIA

John,

I am surprised to see the current tooltip of #4. I think I remember it was much more detailed before. If the code has not changed (like your comment "...calculates the threshold" suggests), the current tooltip simply doesn't properly describe what the feature actually does.

I use #2, the fixed timer.

In my experience a notable change in HFR is caused mainly by two things: 1. Changing seeing, 2. Focus drift. As long as the HFR of incoming subs remains good, there is no need to check focus (or even trigger a re-focus run). Once HFR deteriorates (more than a user-selectable % threshold, as you suggested), a focus check should be performed. Since a focus check eliminates (most of the) bad seeing by taking short enough exposures, it should be able to determine whether the deterioration of HFR was caused by seeing or focus drift. Should the focus check detect focus drift, a refocus run should be triggered. So IMO this should be a two-step approach. 1. Check HFR of each incoming sub and only when HFR deteriorates too much, trigger a focus check. 2. In case the focus check detects focus drift, a full re-focus run should be started.

I think that we have discussed this again on another thread (in Discord too discord.com/channels/1155377982878273577.../1175913197270741054)

I use this function (#4) but I do not truly enjoy it.

My thought:

Let's say, that I do know for my sky, equipment, weather, etc. my worst HFR should be 1.2 and I set that to my limits. If my HFR is 1.6, 1.8, 2.0, is a crappy night I do not want to lose my time.

My session starts, my HFR is 1.15 and life is great.

Let's say that my first autofocus routine starts and the outcome is HFR 1.4, due to passing cloud etc. Now the limit has changed to 1.4. So from now on the autofocus routine will trigger only if HFR>1.4



But if there is a calculation with my initial limit of 1.2 again, it will reinitiate autofocus and my HFR will drop (probably). Otherwise, it could keep capturing with the wrong focus and bulky stars.


So let's say:

Calculate my HFR for every X frame.
If HFR is >Y initiate autofocus, else proceed. But Y is a "constant".

Alfred, Euripides,
Thanks very much for the ideas.

Euripides could you post an invite to the discord channel please (I can't join via the link you posted).

Certainly, it's Stellarmate's server

discord.gg/2GS2fSWjcS

Hi, I'm actually a long time user of HFR triggered in sequence autofocus, i.e., option #4.

From what I understand it is already working as you suggest.
Depending if "Save sequence HFR value to file", see attached image, is checked or not, the Y value of the algorithm that you described is either a constant ("Save... HFR..." checked) or not ("Save... HFR..." un-checked).
When "Save... HFR..." is checked, the value you put in the "Autofocus if HFR >" gets saved in the sequence file and stay constant for the whole sequence. On the contrary, if the option "Save... HFR..." is un-checked it gets updated at each autofocus run.

A modifier is alo present: "HFR treshold modifier"

At least this is how I understand it works.

Best
Massimo

Thanks Massimo. I initially thought this wasn't working but I think I see what its doing now. If "Save sequence HFR value to file" is checked then it uses the saved HFR threshold and doesn't update it for the first Autofocus, as you say. But this then gets ignored if there is a subsequent Autofocus and the check reverts to the algo as if "Save sequence HFR value to file" was set unchecked.

If another sequence is scheduled, then the "Save sequence HFR value to file" value is initially used and the above process repeats.

I wonder if this behaviour is by design to prevent an Autofocus loop where the file value is too low and an Autofocus is immediately triggered. If the file value was always used then the system would Autofocus on every frame.

Hi John, you are right the algorithm is not perfectly clear, and the description of the "Save sequence HFR value to file" function is a bit obscure.

Operatively what a do is to set the "Autofocus if HFR >" to 0.000. Then I save the sequence and run it in the scheduler. In that way the value gets updated by the first Focus sequence (which I select as a first step in the scheduler job). Then the HFR value is checked for each sub and if it is higher than the one determined + 10% a focus run is commanded.

I never actually thought about what happen for successive scheduled sequences...

In the end, I have never been 100% certain of what the hell it does, also because continuously checking the HFS Focus triggering value during a sequence is a bit too boring... according to me it should be made to work as Euripides was suggesting: either Y fixed and stay the same, or gets updated at each autofocus ... simple no?!?

Best
Massimo

Yes, I kind of think that would be simpler and would cover the use-cases that folks have identified so far.

I've tried this for months, maybe I get it wrong. This is my scenario and is not working.

1. I want a simple limit: If HFR is >1.25 then run autofocus. For that reason, I set my *.esq limit to 1.25.

2. My other settings are :



3. Every time that autofocus runs, the limit updates automatically to that value (here is unchecked cause I gave up with that)



So now I run autofocus no matter what every 30 minutes. 8-9 out of 10 times the calculated HFR is <1.3, so with that in mind, I spend time without any particular reason for autofocus.

From my point of you, those limits have to be dead simple:

- IF HFR > X then run (that value right now changes)

- IF Temp > 1 then run (that value doesn't change)

- Refocus every 30 minutes (that value doesn't change)

Hi Euripides, I think to understand your case: you simply want a refocus run every time HFR is above a certain fixed value X. Most sensible.
I was, and I'm still trying to implement an adaptive approach in which the "X" HFR value that commands the start of an autofocus run is continuously updated. I think that both options should be available, as apparently are right now. But maybe in a more controlled and transparent way. Now that I'm pondering about that, don't you think that beside an autofocus rule linked to HFR, temperature and time also one linked to the altitude value (i.e., sky position) would be useful? In the end in my limited experience , beside changing seeing, the thing that to me seems to change most the focus point is if an object is at the zenit or down at the horizon...

Hi Massimo,

I've been thinking about altitude a bit since your post.

I think Altitude is a little different because:
1. Unlike temperature, it is entirely predictable from the target's trajectory so time, to some extent, can already be use as a proxy. Although I understand the limitations.
2. The HFR change with altitude goes both ways, falling on a rising target and rising on a falling target. So, should a rising target and falling HFR trigger an Autofocus?

The simplest trigger with altitude would be:
Refocus if delta Altitude > X degrees, where X is entered by the user.

The holes in this are that on a falling target it falsely triggers Autofocus too often and on a rising target the altitude drop off in HFR is compensated for by focus going off so no Autofocus is triggered (when it should be).

Also as I understand things, near the zenith changes in altitude won't change HFR much, but for lower targets a similar altitude change would result in a much bigger HFR change.

So a simple altitude trigger doesn't sound that helpful, at least to me. A more complicated trigger could be done but would likely be more error prone.

Obviously happy to hear others' comments and discuss.