Hi John, I recommend considering a quadratic over the linear. A linear will get you the core of any particular season, but probably won't suffice to handle a shoulder season or multiple seasons. The work to add the quadratic isn't much, and folks who want a linear can have it by setting the squared term to zero. Just a thought....

Hi Doug,

Thanks for the post. I did see from your data in the post you reference that the temperature data looks like it has a curve in it. The altitude data is a bit more random.

In future fitting a more complex curve would be possible providing I know the equation and its differentiable.

I would like to understand the physics behind this a bit more. I guess there are a couple of things going on with temperature:
1. Thermal expansion of the optical train. The telescope being the main component.
2. Refractive index changes of the optical components (e.g. lenses) vs air with temperature.

I don't know if you, or anyone else, is aware of any papers on this topic? Would be interesting to try and build a model.

As far as altitude is concerned I haven't thought much about it but presumably the effects could include:
1. Lensing effect of the atmosphere.
2. Gravitational effect on the optical train components esp. the telescope tube.

Again, if you or anyone else is aware of any papers on this that would be really helpful.

I haven't searched for papers. I suspect that won't bear much fruit as both astronomical institutions I've previously worked for elected to go the empirical route, measuring and building their own quadratic temperature curves. So, I thought some "wisdom" of the last 2 years using the software I built might help. Take as much or as little as you like.

a. My focuser has tended to drift in counts over many months. This puts a bit of stress on new calculations of function slope, but definitely affects the offset (the b part of mx +b). Allowing users to adjust the offset while retaining the slope will allow for multiple instances of where adjustments are needed but the basic slope stays the same.
b. You'll need to factor both filter offsets, and different gear profiles. Filters should be "zero offset" relative if possible, otherwise things get complicated quickly.
c. The elevation residual data is pretty noisy (as you noticed), but there is a definite trend in there. You may want to allow disabling elevation residuals as an option.
d. I wrote an analysis function that looks at the log and calculates/fits a trendline function. I don't automatically enable this calculation, but rather report it for inspection. It's helpful, and people may (or may not) want to update the function based on the calculation. Sometimes, it's best to just see it but leave it be.
e. There are times during processing when it's important NOT to auto-seed the focuser. Auto adjust is good after a slew without manual adjust, but if manual adjust is done after the slew but before imaging, the manual start position should not be overridden.
f. I'm not sure if you're going to use a summing integrator or not, but I advise that route for multiple reasons.
It's going to take time and patience for users to characterize their gear. I put a warning in the log for instances when there aren't enough data points. It may be required to automate turning OFF auto adjustments until enough data is present to actually validate using the function. Otherwise, it could actually be worse!

Hi Doug,

Thanks very much for the insights, much appreciated.

a) Drift. Yes, this is a problem. At the moment folks will have to manage their own data set to determine the coefficients of temperature and altitude so this will have to be taken into account. Can't think of a way to automate a compensator for this off the top of my head.

b) Currently the coefficients can be set per filter (or the same number entered against each filter). Different profiles will be managed by the Optical Trains functionality that was added a while ago.

c) Altitude (or temperature) can be disabled by setting the coefficient to zero.

d) Currently I haven't done anything on this. Folks will have to do their own trendlines with Excel (or other) on their data.

e) The Adjust Start Pos which adapts the start position for an Autofocus run based on temperature / altitude changes since the last successful Autofocus run for that filter, can be switched on/off in real time as needed.

f) Not sure what you mean by "summing integrator" but focus adjustments for temperature and altitude changes are calculated separately and combined before moving the focuser. My assumption is that these two effects are orthogonal (no influence of one on the other). In the absence of an analytical model its difficult to do anything else.

Getting sensible data in order to calculate the coefficients of temperature and altitude will be tricky for most people, myself included. I think a reasonable way to start will be to:
1. Just consider temperature (switch off altitude).
2. Get a series of measurements of focus vs temperature across a session being careful to make sure the equipment has had a chance to reach thermal equilibrium before starting.
3. Calculate the basic coefficient of temperature.
4. Try Adaptive Focus with this "crude" setup and see if there is any improvement in star HFR/FWHM between Autofocus runs with Adaptive Focus vs without.
5. Another way of looking at this is to compare the number of ticks of focus compensation across a couple of degrees of temperature change (or what you might experience in say an hour of observing) with the Critical Focus Zone. If they are comparable then Adaptive Focus might be worthwhile; if the CFZ is much bigger than temperature movements then its probably not worth pursuing Adaptive Focus.
6. If it looks like Adaptive Focus could be useful, then collect more data to refine the temperature coefficient and consider looking into altitude.

Thanks again, Doug, for all the insights. I think with your experience of this topic, your input is very valuable.

Hi John, It might be a good idea to look at the code I originally developed to see what you might learn from it. Here's the link:

invent.kde.org/dmsummers/kstars/-/commit...898eaca8e0dc9891582f

Note that the main section of code (focusCompensator.cpp) is collapsed by default due to its larger size. Just uncollapse. Hopefully a look will answer multiple questions. If it's still not clear what was going on, I'm happy to discuss. You can send me a PM or email to This email address is being protected from spambots. You need JavaScript enabled to view it.

Cheers, Doug

Thanks for sharing this Doug, I'll take a look!

If you're going to take a look at the code, I guess it would be helpful to have the config file that was used. Here's what the controls config looked like:

Hi folks,

The code is now merged so is available in master.

There is an issue with Autofocus when no filter wheel is connected so please don't try that until my fix for it is merged (hopefully soon).

The "Autofocus with no filter wheel" issue is now fixed.

Sweet. If you ever need a Mac OSX tester, let me know.
I have a C11 with a Moonlight Litecrawler.

Peter,

If there are nightly compiles for the mac (you probably know that better than me) then you can test out John's changes to the Focus tab and Linear1Pass scheme. Those changes are all in the latest software and latest nightly compiles. I've been running them successfully by compiling my own (on Linux). I'm sure John would appreciate any/all feedback.

Hy

I believe the Mac nightlies can be installed from binary-factory.kde.org/job/KStars_Nightly_macos/. There are occasional hitches in finishing the compile run.