Temperature Compensation Implementation


I have a Tak-85 scope and focusing is very critical, so I added an automatic focuser so I could implement SGP to help me keep focus. SGP has been working very well with my system overall. But I noticed that, for slower temperature drops, the focuser wasn’t changing at all. Upon quering the logs, it appears that SGP is basing the temperature compensation simply on the temperature delta during the previous frame (not since the last step change). So if the temperature delta results in a focuser change of 0.5 steps or less, it simply ignores it and moves on. This is an issue for a scope like mine which has a few number of steps per degree of temperature change. When I am imaging for an hour or more with subs of one minute each, the scope may need a 0.3 step change after each frame, but since each delta rounds to zero, there ends up being no compensation and the scope ends up being 18 steps off in an hour.

Is there some kind of workaround for this issue? If not, this seems like a simple fix for the next release. The program just has to measure the delta from the last step change.

Gary Imm
Onalaska, TX

Temperature Compensation Fix
Temperature Compensation Fix
OPTEC Temp Comp focuser
When will this bug be fixed eventually?
Update: Temperature compensation starting temperature doesn't update upon new auto focus

Hi Gary,

I did not observe such a behaviour.

Here are some compacted data which show that temperature compensation in SGP calculates what it is supposed to:

FSQ 106N
Canon EOS 600D, modified
External temperature sensor at the scope.

November 10th, 2017, 23:15 Uhr: TempComp enabled in SGP (temperature coefficient -8 steps/K, corresponding to -53 µm/k).
AutoFocus setting: AF at start of sequence and at temperature change by 1 K

Auto Focus.
Autofokus step size 25, 8 s, 2x2
Time, Focus position, HFR, Number of stars
23:48:33, 25013, 7,01, 12
23:48:52, 24988, 5,81, 21
23:49:11, 24963, 4,58, 26
23:49:29, 24938, 3,38, 51
23:49:48, 24913, 2,77, 71
23:50:07, 24888, 2,64, 75
23:50:26, 24863, 3,41, 46
23:50:44, 24838, 4,46, 26
23:51:03, 24813, 5,75, 19

[New auto focus method calculated focus at: 24901
Old auto focus method calculated focus at: 24888]

Result: New focus position is at 24888 (16,91 °C)

23:51:26 validation frame, HFR 2,01, 97 stars

Acquisition of 5 images with temperature compensation enabled in SGP:

HFR, Number of stars, Focus position and Temperature are saved with Image History. HFR und Number of stars are not saved in the FITS header.

23:52:27, Exposing for 300 seconds… 20171110_0001.fit: FOCPOS 24888, FOCTEMP 17,67; HFR 4,12, 217 stars
23:57:40, Temperature compensation: Adjusting for 0,7 degrees (end: 17,7; start: 16,9; coefficient: -8) for 5,8 steps…
00:01:41, Exposing for 300 seconds… 20171110_0002.fit: FOCPOS 24894, FOCTEMP 17,52; HFR 5,22, 178 stars
00:06:55, Temperature compensation: Adjusting for -0,2 degrees (end: 17,5; start: 17,7; coefficient: -8) for -1,4 steps…
00:09:06, Exposing for 300 seconds… 20171110_0003.fit: FOCPOS 24893, FOCTEMP 17,04; HFR 4,44, 178 stars
00:14:21, Temperature compensation: Adjusting for -0,5 degrees (end: 17,0; start: 17,5; coefficient: -8) for -3,6 steps…
00:15:31, Exposing for 300 seconds… 20171110_0004.fit: FOCPOS 24889, FOCTEMP 17,01; HFR 4,49, 154 stars
00:20:46, Temperature compensation: Adjusting for 0,0 degrees (end: 17,0; start: 17,0; coefficient: -8) for 0,1 steps…
00:21:32, Exposing for 300 seconds… 20171110_0005.fit: FOCPOS 24889, FOCTEMP 18,19; HFR 3,94, 164 stars
00:26:48, Temperature compensation: Adjusting for 1,2 degrees (end: 18,3; start: 17,0; coefficient: -8) for 9,8 steps…

00:26:48 Auto focus required (temperature change trigger). Last temp: 16,95; Current temp: 18,27
Autofocus step size 25, 8 s, 2x2
Time, Focus position, HFR, Number of stars
00:26:52, 24989, 4,73, 6
00:27:10, 24964, 3,89, 7
00:27:29, 24939, 2,99, 6
00:27:48, 24914, 2,67, 4
00:28:07, 24889, 2,72, 10
00:28:25, 24864, 3,57, 8
00:28:44, 24839, 4,92, 8
00:29:03, 24814, 6,26, 8
00:29:22, 24789, 7,88, 6

[New auto focus method calculated focus at: 24898
Old auto focus method calculated focus at: 24902]

Result: New focus position is at 24902 (18,50 °C)

00:29:43, validation frame, HFR 3,75, 24 stars

The order of decreasing sharpness of the images was:
0005 > 0001, 0004, 0003 > 0002
These results were poor.

My interpretation of these results is:
Temperature compensation in SGP (between frames) was working basically as expected. The corrections were calculated and executed correctly according to the equation:

fp(T) = fp(T0) + c * (T - T0)

(fp: focus position, T: temperature, T0: temperature of last AF run)

T	T-T0	dfp	dfp	fp
		abs	rel	
16.91	0.00	0	0	24888
17.67	0.76	+6	+6	24894
17.52	0.61	+5	-1	24893
17.04	0.13	+1	-4	24889
17.01	0.10	+1	0	24889
18.19	1.28	+10	+10	24899

(dfp abs. values relate to fp(T0), dfp rel. data relate to the actual fp, i.e.:
fp(T) = fp(T0) + dfp abs and
fp(T[n]) = fp(T[n-1]) + dfp rel

SGP outputs the dfp rel data to the logfile - so in my case all these values are correct.)

So my summary is: SGP does it right The representation of the operations in the logfile is somewhat strange.

I had a very good correlation of temperature and focus position in 3 nights before, when wind was completely absent, see Proposal of a "Quadratic Fit" Auto Focus evaluation method.

In the night of 10. Novemerb 2017 (data above) the observing conditions were especially poor: strong warm wind with some dust caused an increase of temperature during the night, poor transparancy. During the last focus run even the gude star was lost. So it was not surprising to me that my focus results were not satisfactory. However, I’m sure that this was mainly for one reasons: Temperature measurement at the scope was strongly affected by the unequal strong wind, and false corrections resulted from poor temperature measurements . What I learned from that experience is: It is indispensable to protect the temperature sensor from wind. This is a point that chasmiller46 and pscammp already pointed out in another thread:
Question for users of temperature compensating focusers and Question for users of temperature compensating focusers

For temperature compensation we want to measure the temperature change of the scope (in the case of an refractor it is mainly the temperature of the objective), not of the sometimes (especially when wind blows) readily changing temperature of the air. The temperature of the scope is always changing slowly, its mass has to be warmed up / cooled down. So it might be advisable to apply thermally conductive paste between sensor and scope, and cover the sensor with thermally insulating material in order to avoid the influence of wind. I hope these hints will be of help.


p.s.: I still wonder whether my questions Unanswered questions: AF methods "weighted average" / "best fit" will be answered by the developers some day.



Thank you very much for your detailed analysis.

I reviewed the data in detail and SGP is working fine in your case. However, I still believe that, for the case I described, SGP is not handling it correctly. That case is when there are repeated small temperature changes which result in the required step change each time to be between 0 and 0.5, in which case the movement gets rounded to zero. Last night I had a run where there were 25 consecutive subs of small temperature changes - the focuser wasn’t moved at all, but should have been moved by 7 steps total

Searching through the SGP forum again, I found this quote from the developer in response to a complaint that SGP was not working properly:

"Ken Founder & Developer Aug '16
Temp comp is working just fine. You have just run into an idiosyncrasy of the temp comp system that resulted in no movement because it has only ever considered temperature change between the last 2 frames. You never had a delta that called for any significant movement (mostly 0.2 steps). You must at least register a need to change the focuser’s position by 0.5 steps. Smaller values are ignored. It is unfortunate and could probably be done better to consider the temperature drop over the whole sequence, but this is not a very popular feature and hasn’t made the hit list.

So I think this confirms the issue that I was reporting. I am surprised it has not been fixed yet. This is a pretty significant error for anyone with scopes which do not change much with temperature, but which are focus sensitive.



if the cited text passage describes the current algorithm in SGP correctly, the algorithm is wrong - and you are right:

  1. Whether a movement is required or not must not be dependent on the “temperature change between the last 2 frames” as Ken wrote.
  2. If calculated as described in the cited text passage and the temperature gradient is flat enough, no temperature compensation will occur ever.
  3. If calculated as described in the cited text passage, cumulative rounding errors will falsify the temperature compensation.

For executing a temperature compensation one has to calculate the absolute position required according to equation [1]. The result has to be rounded, because the focuser only can be moved in an integer number of steps. If the current fp and the calculated, rounded fp are equal, no movement is required, else the focuser has to be moved to the calculated position. Note that no cumulative rounding error is introduced by this approach!

fp(T) = fp(T0) + c * (T-T0) [1]

Example: c = 8 1/K
T0 = 15.00 °C, fp(T0) = 25000
T1 = 15.06 °C => fp(T1) = 24999.52 rounded to 25000, calculated and current fp are equal, no correction required
T2 = 14.94 °C => fp(T2) = 25000.48 rounded to 25000, calculated & current fp are equal, corr. not required
T3 = 14.90 °C => fp(T3) = 25000.80 rounded to 25001, calculated & current fp are not equal, corr. required
T4 = 14.87 °C => fP(T4) = 25001.04 rounded to 25001, calculated & current fp are equal, corr. not required
T5 = 14.84 °C => fp(T5) = 25001.28 rounded to 25001, calculated & current fp are equal, corr. not required
T6 = 14.80 °C => fp(T6) = 25001.60 rounded to 25002, calculated & current fp are not equal, corr. required

Case 1:
At T2 a correction is NOT required: the calculated fp is 25000 which is equal to the current fp. However, the temperature change between the last frames was 0.12 K. If this (false) temperature difference was inserted into the equation, it would result in 0.96 steps, suggesting a correction by mistake.

Case 2:
At T6 a correction IS required: the calculated fp is 25002 which differs from the current fp. However the temperature change between the last frames is only 0.04 K. If this (false) temperature difference was inserted into the equation, it would result in 0.32 steps, not suggesting a correction by mistake.

Up to now I have no further data with Temperature compensation enabled, it is raining here (finally!) and I don’t know when the weather will be suited for astrophotography again. Perhaps you are willing to provide a logfile of the night in question? Then I will take a look at your data.

I hope that the question “What does the Temperature compensation algorithm really?” will be answered by the developers.




Here is a link to a log file from a recent night:

A good example is if you look at these two excerpts from the file:

[11/20/17 21:25:48.260][DEBUG] [Sequence Thread] Temperature compensation: Adjusting for 0.0 degrees (end: 10.3; start: 10.3; coefficient: -10) for 0.1 steps…
[11/20/17 21:25:48.266][DEBUG] [Focuser Thread] Focuser moving to 18887
[11/20/17 21:25:48.273][DEBUG] [Sequence Thread] Current event[4] frame count: 1/100…

. . .

[11/20/17 23:15:45.979][DEBUG] [Sequence Thread] Temperature compensation: Adjusting for 0.0 degrees (end: 9.2; start: 9.2; coefficient: -10) for 0.0 steps…
[11/20/17 23:15:45.987][DEBUG] [Focuser Thread] Focuser moving to 18887
[11/20/17 23:15:45.987][DEBUG] [Sequence Thread] Current event[4] frame count: 100/100…

The top is frame 1/100 (10.3 deg.), the bottom is frame 100/100 (9.2 deg.). The focuser position remains exactly the same (18887). So even though the temperature changed by over 1 deg. (should be over 10 steps) over a time period of almost 2 hours, the position has not changed because each frame delta was less than 0.5 steps.



Hi Gary,

thank you very much for your logfile, that is good data!

To make it short: you are right, SGP uses an algorithm for temperature compensation that yields totally wrong focus corrections. The SGP algorithm works as Ken described it. This means:
if the temperature change between 2 frames is small enough, it may happen that SPG does not correct for it at all. This will result in a considerable amount of cumulative error over time if it happens every once in a while.

I carefully analyzed the data in your logfile from 18:50 till 20:03, extracting the relevant data (time, temperature and focus position), transferring them into a spreadsheet software and calculating the “true” focus position according to the temperature. The result is best illustrated by the plot:

The correct algorithm for Temperature compensation is:

fp(T) = fp(T0) - c * (T - T0)

(There was a sign error in the equation I gave previously since (by convention) a negative temperature coefficient means that the focuser must be moved inwards as temperature drops.)

I noticed that you already put a Feature request about this issue Temperature Compensation Fix and I will second that.

Additionally I would like to put another Feature request related to Temperature compensation: it is not wise to execute each correction when the change is only 1 or 2 steps. The user should be able to define a minimum deviation between current focus position and calculated focus position. (This threshold is related to the Critical focus deviation (CFD) of the scope.) A correction shall only be applied if this threshold is reached or exceeded. This proposal is related to, but not identical with an older Feature request, see Temperature compensate tolerance . The reasons why one wants to have such a threshold are given in that FR. However, to my opinion it is not wise to take temperature change or time for that threshold. The number of steps would be a much simpler and better criterion. What do you think about that?




Thank you very much for your detailed analysis and graph of my log file. The graph is easy to understand and shows the nature of the problem very clearly.

Yes, your feature request is a good one. A correction should only be applied when it makes a difference, otherwise, it just adds unnecessary time to the process. Once you submit it, I will second it.