It's not a position graph, it's a graph of the Index of refraction versus the elevation angle at standard temperature and pressure (STP). It is a number representing the angular displacement of incident light rays through the atmosphere showing the effect of thickness of the transited airmass between the observer and the celestial target. The calculated index is directly influenced by temperature and pressure (among other things, but these are the two largest factors), Elevation angle is a scalar value, and it's change due to earth rotation, is based on the location data, which doesn't change (or shouldn't)., so it has no mathematical relationship to temperature, and isn't a proxy value for anything. Unless your mount is on a moving object, it will not have have a direct impact of tracking error, unless .

Temperature has several effects. It causes the materials in the mount or gear to expand or contract, which can change the elevation angle slightly, and the error it produces will be relatively constant, and always in the same direction relative to the direction of the temperature change. So you wouldn't expect to see a lot of tracking error scattered about the regression line, instead you'd see the directrix of the parabolic regression line move up or down the Y axis, but the parabola itself doesn't change its shape.

The principle effect of temperature changes is that they change the index of refraction (RI), and thus change the apparent size of celestial objects. If the atmosphere were still and well regulated, then this wouldn't be a problem, but it isn't. It roils, changes density, and the stratification of the air changes, and this produces inherent error in the RI, and that translates directly to focusing, tracking and guiding errors, and those will be randomly scattered about the calculated RI.

In your post, you refer to Temperature Compensation as though it is a single term, but it's not. It's an ephemeral value calculated specifically for each value modified. There is no one "Temperature Compensation" value. Theres one for refraction, one for expansion/contraction, and probably others. A programmer would have to discuss how they used temperature in the various processes, to discuss it in more specific terms, but the main takeaway, is that temperature compensation is only a meaningful term when it includes the process or value being compensated. It will be different for every process.

It's not. The elevation is fixed (or should be) and does not change during a session. It is used for the initial calculation of the RI (and alignment, etc), but thereafter is constant, and so has no further effect on focusing or focus error. RI, on the other hand, continuously changes, and has a direct and pronounced effect of focus error.

With elevation is meant the altitude of the object (as if using an alt-az mount), this -does- change during a session.

Also, if you take refraction into account, will you then -not- take it into account when using narrow band filters? There the effect isn't measurable.

Now a question, would you consider to focus during imaging or quickly adjust the focus in between lights?
Personally, I don't use very long exposure lights, especially with Starlink up and screwing up our images.

Elevation usually refers to the geographic distance from the earths center, most often expressed as altitude above sea level. What you're referring to is most often called the zenith angle, or the angular displacement from zenith.

The Refractive Index applies to all electromagnetic radiation. It is usually calculated for yellow light for use in astronomy. However, the actual energy (frequeny and amplitude) of a received photon is an independent variable in the calculation for angular deflection produced by the refraction index.

I refocus on every 2 degree change in temperature, or guider crapout, or at the start of any sequence. Focus while taking lights isn't critical to the process, but shouldn't be changed between exposures.

Hi BDavis. Ok, we've come well off the intended scope of my post, and we disagree on too much in your latest posts for me to comment further. FWIW, I'll hold the line that Bennett's graph definitely plots refraction (in this context the true position offset) vs apparent altitude (in units of arcminutes). Refractive index is dimensionless, and is a term itself dependent on other terms (temp, pressure, humidity, etc). Main takeaway: I accept that you believe refractive index is the driving function changing focus. We just need to disagree amicably.

My original post is simple: Two readily available variables in Ekos (temperature, (target) elevation=altitude) can be used to dramatically improve focus control. I've shown a relationship of temperature to focus. I've also shown that once factored, residuals of a temperature function can be correlated to target elevation. The data speak for themselves. Anyone who wishes can verify or refute the suggested relations by characterizing their own focus behavior via the focuser debug log. I am not stating that these two functions are the perfect and complete academic explanation. Rather, these two variables are readily available in Ekos, and serve particularly well to prevent poor auto-focus starting position, offset focus position between exposures, or prevent poor focus position after slews of large elevation difference. We're trying to remain close to the focus caustic. KISS can work well here. Cheers, Doug

@Bart: Re: "would you consider to focus during imaging or quickly adjust the focus in between lights?"

Well, the data for my fast (f/2.2 setup) indicate that I "could" change the focus by 55 counts per degree F change, and ~21 counts per degree elevation change. It's tempting to think about an experiment with this and do a build where an auto update is done between exposures (but never during an exposure). I also do short (30-40 second) subs, so an autoupdate might keep me from having to do an autofocus run (expensive!) so often at the start of the night. Whether I'd trust it for a big elevation difference slew is debatable without a clipped higher order polynomial (to fit the low el data better), but it would be an interesting test. Eventually, and assuming a stable focuser with well controlled backlash, it might be quite effective at minimizing the need for autofocus runs. Right now, if I want to image for two hours on a target at the start of the night, I NEED to run autofocus every 20-40 exposures (or use the deltaT function). Would be nice to avoid that hassle....

Let me simplify then. For the telescope you used to generate this graph, calculate the width of the CFZ , and the focal length change of a single step (in microns). Now, in your graphic, how many CFZ widths error are contained in the extreme spread (roughly 1000 steps) of the values you generated?

Thus, estimating a step position based on that graphic, is statistically more likely to produce an out-of-focus image, than one in focus.

Giving this a little more thought, I can visualize a "predictive focus tool" that could set the correct initial position and step size based on local conditions and the parameters of the rig being measured, by using a feedback loop created by logging the values of the independent variables (that have a significant enough effect to bother with) of each focus attempt, including the available weather data, into a text file database. This would need to be performed against the same starfield for some base number of repetitions at different weather conditions. You'd need to input the measured step distance of your focuser assembly, and the tool would use the telescope parameters configured elsewhere to calculate things like step-width of the CFZ and use the curves generated by the data set at each variable point to build a mesh of actual resulting values, that could be used as a predictor for focus setting(s) that should be pretty accurate once it has enough training runs in it. So as a user, you'd do the measurement, configure the tool with it, and select a reliable and non-variable star (like polaris, for example), run "Train Focuser" (autofocus that saves values to training file). Then, every time you set up, point to Polaris, and run "Train Focuser" again. Do it enough times, and it should get pretty good at predicting focus position for a given set of conditions. The mesh generated, likely might have value elsewhere in the software as well, since it effectively models the performance of your rig at a given location over time.

Hi bdavis. I think you're driving toward a much more complicated automation regime than what I've suggested (i.e. elimination of existing autofocus loop). I fear that would be very unlikely to ever get implemented (unless you write and test it yourself). What I have suggested in this thread HAS been implemented at multiple large observatories. I know this because I personally worked on the temperature and elevation compensation model at the Large Binocular Telescope, and a similar strategy (lookup tables) was employed at Keck where I worked before LBT. I have used the data I posted for my own f/2.2 RASA 11 (highly sensitive to focus) and it works great. Whether I can convince you of the suggested approach is moot. The proof is in the results and is available to everyone. For the unbelieving, a better question might be: "how and why could this improvement approach possibly work?". So let me try and address that just a bit more.

The temperature component works because the dominant error we're beating down is structural (shift of optics due to changing temp of the OTA). The next component (residual of the temp function) has complex / multiple underlying reasons, but airmass (target el) empirically correlates with the residual to help beat it down. Together, these two available variables get us within the ball park to improve focus management. The key to why this simplicity works is that we're NOT doing a one-time blind position update. We're not replacing the closed loop autofocus routine. We're only "seeding" the autofocus loop's start position. The autofocus loop is still responsible for resolving best focus position. Therefore, all the discussion about spread and CFZ size is misdirected. Ok, now to the next suggested higher automation level (updates between exposures). In that scenario, any position update would use the function outputs as integration OFFSETS from the base position determined by prior autofocus. Those offsets are small and driven by trendline direction. Here, the spread isn't as important as having the trend SWAMP the spread uncertainty so the direction and magnitude keep us within the CFZ and REDUCE our need for another autofocus run. I mentioned to Bart that I'm not sure I would trust a blind update for a large elevation difference slew (and I still believe that). Bottom line: The work needed to do a one-time blind offset and ELIMINATE autofocus runs is well beyond the scope of this thread. So, whether or not I've convinced you, I hear you. I suggest if you want to discuss a "predictive focus tool" that eliminates the autofocus loop, please open a new thread for that topic. I'd like to keep this thread within the bounds of improving and reducing the existing autofocus loop interface (as opposed to eliminating it). Cheers, Doug

I plan to make progress on this little project in the new year. Adjusting the autofocus "seed" position should be simple enough; Everyone should be able to benefit. More complicated, but also more rewarding, is adjusting focus position between exposures to maintain more time on target (i.e. reduce autofocus runs). Currently, I've got a functional test stub that adjusts an autofocus position using an integrator offset defined from temperature and elevation trendline slopes/curves. l've already shown that for f/2 (RASA, Hyperstar, etc.), adjustments on the order of a full CFZ per degree(F) temperature must be done. Also needed is ~1/3 CFZ adjustment per degree of elevation change (below 45 degrees). This is a LOT of needed focus adjustment for beginning of night and low elevation scenarios! The need for adjustments in f/4 through f/8 systems is TBD, but I would expect f/4 and f/6 to benefit (39um and 87um CFZ size). At f/8 and f/10 (155um to 244um CFZ size), it's likely not important (beyond the seed update).

FYI (in case it wasn't obvious): if you have low elevation targets at the beginning of the night to image, it pays to image these EAST if possible! Needed adjustments for falling temperatures partially negate needed adjustments for rising elevation. On the WEST side, these factors are additive AGAINST you, possibly preventing good hold on focus. Something to think about in your planning until we have compensation in place!

Finally, a few requests. I need some 3.5.x focus log data for f/4 through f/8 systems. If someone can send me a debug focus log snippet (see OP) or better...trendline data, it would be helpful for sensitivity analysis. If you might be interested in discussions of the GUI requirements/design for this project, I am toying with the idea of hosting a Zoom call before implementation goes too far. If interested, send me a separate note. Finally, I am still looking to partner with a GUI developer. This isn't my primary skill set, so I could use some help. Hopefully someone who is in the f/2 to f/7 camp will see their own need and want to partner! We can get this done.....Cheers and thanks. Doug

I've updated the charts in the OP (now ~1 year, 350 autofocus runs at night). The temperature data now slightly favors a weak quadratic fit (but I'm still showing a linear). The temp ranges from 20F to 70F. I've also examined focus sensitivity for different systems against seeing (1.5 to 3 arcsecs, f/2.2 to f/10 setups). For ease of understanding, I have attached two graphs, one showing a CFZ perspective (microns), and the other using an EAF quality focuser (5760 counts per revolution) combined with a 750um focuser thread pitch (resulting in focus counts). In case it's not obvious, f/10 or f/7 setups won't need Adaptive Focus Control (AFC for you football fans). In good/best seeing, f/4 might benefit. In all cases, f/2 and f/3 need AFC. Those of us with f/2 or f/3 systems know intrinsically what the charts are saying; the current focus adjustment controls (think scheduler, time/temp deltas) do not suffice. I've also attached a temperature chart from this month to support that assertion (my site/gear).

This month, I used a stand-alone program to manage an autofocus "integrator", and manually offset focus between exposures as temperature and elevation changed. Manually intensive, but the results were very satisfactory! There appears to be no Ekos "gotchas" for updating focus between exposures. Adjustment can coexistent with download, dither, or exposure delay timing. I was easily able to maintain focus in my f/2.2 rig as temperatures rapidly changed. One good seeded autofocus and then occasional updates between exposures will keep focus well managed. Only 1 autofocus needed per target!

So a couple of thoughts. My 7 night January run had some bad seeing in it. Autofocus has difficulty when HFR readings are bouncing all over the place. This adds to spread in the logged data. Linear autofocus tends to pull up short of the bottom of the V curve in bad seeing, especially if the last HFR reading (averaged or not) is marginally higher than the prior HFR reading. Getting one good autofocus result (even if manually adjusted), followed by AFC updates, seems like a better approach to managing focus than risking N funky autofocus results. Finally, while I started this idea thinking that a seeded autofocus was the goal, it now seems clear that AFC between exposures IS the goal. A seeded autofocus start is desirable, but realized AFC between exposures is a "can't live without" feature for f/2 & f/3 systems! So work will continue.... cheers, Doug

Very interesting! Thanks for sharing.
One thing that keeps me from 'blindly' adjusting focus based on temperature is focuser backlash. How do you handle this, especially how did you measure it (assuming you do have some)? One of the reasons I do like Hys focus routine that is insensitive to (at least small) BL.
An EKOS module to automatically compute focus backlash would be a nice thing

I haven't yet measured my EAF focuser backlash, but it's on the list of things to confirm this month. I'll use a caliper and manually drive focus to check it. I'm a bit uneasy about the flexible coupler ZWO uses (between motor shaft and focuser shaft), but I think it likely is ok and shouldn't add significant BL. I suspect EAF, Pegasus, and other similar focuser offerings are going to be well enough behaved to ignore BL. Just thinking out loud, I would guess that BL related skew would bias measurements without altering overall trendline slope. The integrator already addresses prediction bias (back to autofocus position); it should cover BL bias too. It's a beautiful theory that could be wrong, but early testing seems to bear this idea out.

Honestly, I'm much less worried about BL than I am with position errors introduced when linear autofocus pulls up short. That kind of error needs to be addressed. Beyond the obvious logged position error, introducing AFC would have the effect of "freezing" that bad focus (relative position offset), resulting in AFC being less ideal than if multiple sloppy AF runs were done (assuming that some of those AF solutions would be good). I need to talk to Hy offline about what these charts suggest regarding sufficient precision of linear AF solutions, and how that might lead to some improvements. More later.... Cheers, Doug

Edit: One important thing to remember about AFC is that it's operating a trendline. Generally speaking, the temperature trend will be downward (bumps excepted). This means that BL isn't a factor because the adjustments are all unidirectional. If you were really worried about BL, you could avoid adjustments during reverse bumps (they typically don't last long). Guess: the magnitude of the BL probably needs to be less than 1/2 of the CFZ to be safely ignored otherwise.