FYI, new code was submitted last night that adds the mount altitude angle to the existing kstars log and autofocus log. After merge, the altitude will now be at the end of each line:
autofocus log (located in .local/share/kstars/focuslogs/):
date, time, position, temperature, filter, HFR, altitude
2020-09-01, 22:35:46, 50100, 15.0, Red, 1.692, 37.5
kstars log has a similar, but different formatted entry:
Autofocus values: position, 50100 , temperature, 15.0 , filter, "Red" , HFR, 1.69168 , altitude, 37.4758

The prior version of the log entry already facilitated plotting temperatures against focuser positions. The new code provides users with info needed to find the altitude residuals trend.

For those that don't know how to process the data (but want to), do the following: (Note that your focuser should be well behaved...no major slipping or out-of-control backlash or your trendline functions will be suspect)
a. Import the autofocus log into your favorite spreadsheet or charting app and plot all temperatures against corresponding focuser positions. Set a linear or quadratic trendline for the data and display the equation.
b. Create a new column that subtracts the above equation from each focuser position (on the same row). This is the residual of the measurement after factoring the temperature trend.
c. Plot the residuals column (from b above) against altitudes, set a trendline, and display that equation. This is the elevation residual function.
You can now calculate your autofocus "seed" position for any temperature and elevation. Add the two functions together using the input temperature and elevation. I've provided a sample spreadsheet clip below that hopefully helps folks understand the setup a bit better. The top line shows the seed position calc for my gear (partial data). In my case, indications are that I must adjust my focuser ~75 counts for each degree (C) change, and also ~21 counts (+/-) for each degree change in target altitude angle. Running the focuser seed calc after a slew and setting the focuser position to the seed before running autofocus allows tighter parameters, keeps autofocus runs short, and increases successful outcomes. Automation (future) is certainly possible, but for now, I hope this info helps folks get a better handle on focus performance. Cheers, Doug

Is there a trick to enabling the focus logs? I did have some older ones, but I don't seem to be generating them at the moment.

Thanks

After selecting the main Ekos tab (wrench), the configure Kstars popup will have the settings. Set verbose, and focus. Cheers, Doug

I was just looking at trying to implement temperature compensation as well. I've been looking closely at my data, graphing FWHM and frame quality over time, and it varies a lot with my EdgeHD 11. But once I have this data and plot it, how do I get the information into EKOS to utilize it? I don't see anything obvious for inputting the temperature focus parameters. There's a refocus if temperature changes, but that seems like a brute force method. I'm looking to have something that will adjust automatically throughout the night.

Does this not calculate atmospheric refraction vs altitude in a linear relationship? Surely that is not the reality, as the atmosphere is more substantial at lower altitudes Especially below 30°.

@Andrew: There's nothing automated currently except the log entries (to help figure out the functions). I was hoping the idea would spark greater interest so automation could go further, but alas, it just didn't seem to extend beyond a few people. What I envisioned after logging was the ability to define the focus function terms (config file or gui update), and then have ekos auto-update the "seed" focuser position after slew so that a subsequent autofocus run would take advantage for efficiency. For my rig, having a temp function helps, but having both (temp and alt angle) makes autofocus runs really efficient. This idea may be implemented in the future if more interest develops. For now, not ideal, but I just manually update the focus position before running autofocus. It's much better than just running a blind autofocus and potentially having it wander.

@ihoujin: The example I initially used was simplified so that those who might not otherwise enjoy any discussion of math, would understand the basic concept of temperature and altitude angle focus compensation. It is definitely true that airmass (which is the function of alt angle we're most interested in), is non-linear. Temperature is most likely going to be linear for everyone. Fitting a linear function for alt angle would work better than nothing, but a 2nd order polynomial would likely work better than linear for folks who expect to "go low" often. Most folks won't go to the trouble to capture both temperature and altitude angle functions (even though it's easy enough to do...I gave the receipe in the OP). If you're one that want's both (as I do), then just trend the data and fit a polynomial you feel works for your data. cheers, Doug

It is a wonderful idea, certainly the next logical step ahead of refocus on temperature change. And an elevation criterion on its own would also be applicable to most astronomers, since a majority probably don't monitor temperatures.

FWIW, structure expansion/contraction as a function of temperature should be the dominant function, especially given that most folks will want to image in the lowest airmass (highest elevation) possible. This reduces the importance of elevation residuals to low south observations (northern observers) or low north observations (southern observers). For the greedy , I'm not sure I'd trust only having an elevation function (desert locations will have huge temp swings that should be factored), but the recipe would be essentially the same (swap el for temp, and just ignore the residuals).

Edit: I've updated the charts for my setup (updated in the OP). There are ~300 autofocus sequences captured from July to Nov. Based on the results, I've altered the elevation residual function to a 2nd order poly (still not quite powerful enough...but sufficient). The temperature function dominates (5 degree change drives ~400 focuser count shift), while elevations above ~40 degrees do not really drive noticeable offsets. Observations below 40 degrees elevation do drive significant offsets. Your gear & results will differ, but the trends will likely be similar.
Cheers, Doug

This is really cool analysis capability, can it be added somehow to Ekos internally without the need to export and load into a spreadsheet?

It's excellent as it is, but always thinking of better. I know the team are making loads of commits to get 3.5.0 stable, but this would make a worthy future feature.

Another update: I've now got ~300 on-sky linear focus runs analyzed (see chart in original post). I've driven my gear 3K miles over bumpy roads to setup/teardown in remote observing locations, so if there were a problem with focuser stability, I would have seen it. Data presented here were collected over several months this year, and represent 100+ images (10K+ subs). There is a 40 degree F temperature spread and a full set of elevations in the dataset. Any further updates wouldn't significantly change the findings.

I'll make the bold statement that temperature and elevation focus compensation could benefit everyone who takes the time to characterize their gear (via the existing focus log entries). This is especially true for faster focal ratio setups. I've seen the difference, and it's appreciable. Updating the focus position (seed) before starting autofocus always results in a minimized,symmetric V curve. I no longer worry about donuts or run-away anomalies, and focus updates are more efficient. For scheduled or remote/unattended observations, I would think this would especially add robustness and less overhead.

So, I'd like to ask if there's someone from the core developers who might want to partner with me to resolve final details, and modify the focus code for a future release. I've never been a GUI developer. I can definitely drive requirements and help with coefficients file logic and seed update logic. The GUI work should be minimal (enable switch for compensation seed auto-update). A minimalist approach now could be followed later with more sophisticated automation. Comments? Any takers? Thanks, Doug

Very interesting data. It would be interesting to map the two curves against the calculated refraction coefficient , since I think that's probably the largest part of the differentials you are seeing. Assuming a weather source is configured, Ekos should have that data somewhere, perhaps a script could be genned up to log the calculated R, temp, pressure, humidity, current step, elevation angle, and current HFR. This could be used by the focus module to maintain a quadratic that could be used to auto-configure R and the the focuser at runtime, and perhaps condition other activities as well.