Last night I imaged both scopes for a lovely clear 11 hours. I had a serious problem with Temperature Compensation enabled. I have not used Temp Comp for a long time because of a serious bug that only shows up if you have both Temp Comp and Filter Offsets enabled. Since I can do Temp Comp with my focuser software, that is what I have been using.
Ken had mentioned that this bug was fixed in v307 so I enabled Temp Comp last night. Early on I noticed that the focuser was being erroneously moved out about 50 steps, putting it very much out of focus.
I also had Filter Offsets enabled, but this may not have been a factor since I was only using the L filter.
This issue happened several times before I turned off Temp Comp. Here is what shows for the last occurance:
[10/16/19 19:57:47.290][DEBUG] [Focuser Backlash Thread] Backlash thread has detected that movement to modified position (21468) is complete…
[10/16/19 19:57:47.290][DEBUG] [Focuser Backlash Thread] Moving focuser to original requested position (21318)…
[10/16/19 19:57:47.290][DEBUG] [Focuser Backlash Thread] Focuser backlash compensation needed. Steps: 150 Direction:IN
[10/16/19 19:57:47.290][DEBUG] [Focuser Backlash Thread] Focuser moving to 21318
[10/16/19 19:57:47.291][DEBUG] [Focuser Backlash Thread] Focuser move call complete
[10/16/19 19:57:49.293][DEBUG] [Focuser Backlash Thread] Focuser backlash completed. Focuser is at original request position (21318)…
Position 21318 is perfect focus.
The next Temp Comp or focus related messages are:
[10/16/19 19:59:53.407][DEBUG] [Sequence Thread] Temperature compensation: Adjusting for 0.0 degrees (end: 55.2; start: 55.2; coefficient: 5) for 0.0 steps…
[10/16/19 19:59:53.419][DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_ABS message received…
[10/16/19 19:59:53.419][DEBUG] [Focuser Thread] Focuser moving to 21366
A position of 21366 looks like a number picked from thin air. I can’t find any correlation with anything. It is badly out of focus.
When I then turned off Temp Comp, the rest of the night (about 10 hours) ran perfectly. Focus runs perfect. Slew and Center, perfect. I got great images. Other than this issue, v307 is running great for me. Unattended all night. sg_logfile_20191016165134.zip (295.1 KB)
I think I know what’s going on here. The reason that number seems random is because it really is… (ish). Note that when the request goes out to the focuser to move to 21318 it is at 19:57:45.263, but first, the focuser goes to 21468 for backlash comp, then moves in toward 21318. Just before the image starts, the current position of the focuser is marked at 19:57:45.652… about a half second later, which, I guess, happened to be 21366. Then temp comp uses this as the baseline for movement when it is applied.
This issue is actually more serious than just a temp comp bug… Not sure how many people it affects, but even without using temp comp, this creates a situation in which frame integration can start while the focuser is still moving. I’ll make sure the sequence blocks while the focuser is moving. In case this is not actually what’s happening, I added all the logging we would need to trace it.
That’s great Ken. An additional issue I noticed here. This appeared to me to be happening when the temperature had an increase, thus triggering a backlash compensation, which you are saying is the culprit here, sort of. Prior to one of the occurrences I noticed the temp had increased by 0.2 degrees which then required a backlash movement. It is really fairly useless to trigger a focuser change with backlash compensation for such a small change in temperature. Can we have a minimum temp change before temp comp does anything? Either set automatically, or user settable?
It would be better to set a threshold in focuser steps instead of temperature though. So the user would be capable of setting a threshold that is related reasonably to the Critical Focus Zone of the scope.
We all agree that temperature compensation movement for small values, especially when you have backlash compensation active is unnecessary and potentially harmful to focus. The question now becomes “what defines enough change to move?”. To the extent possible, we have always avoided adding user settings like this in SGPro because they are cryptic and not necessarily clear in terms of what you should put there. In the spirit of this goal, I decided to try and automatically determine this value based on user settings that are VERY clear. Specifically, your scope’s focal length and aperture diameter. As most of you know, proper focus defines an area called the Critical Focus Zone (CFZ). When you are at a position that is perfect focus ± CFZ, you are considered to be in focus. The CFZ is dependent on F#. If we can determine that, we can determine with a fair amount of accuracy if the error presented to the temp comp routine is significant enough to leave you out of focus (out of the CFZ). If it is, we incur the movement, if not, carry on.
Of course, if this proves to be inaccurate we can always default back to a user defined value…
This will be in the next beta. Requirements to use this are:
Focal length defined (mm)
Aperture defined (m) -> This is a new property on the Telescope tab
Your focuser must implement the StepSize property (you can see if it does in the logs when it connects to SGPro)
Awesome Ken! This is an excellent way to do this. Hopefully my focuser implements the StepSize property. If you need to go to (or add for those with an unhelpful focuser) a user set parameter, number of steps would maybe be better than a temperature increment.
Criteria for defining CFZ is variable. Will there be an option to input a parameter to adjust for the CFZ criteria that one would like to use?
In my case, f/6, pixel size 4,78 microns, from http://www.wilmslowastro.com/software/formulae.htm#CFZ , CFZ = 90 microns, but I use 50 microns so not to visually detect a focus change when accepting 90 microns (± 45)
After taking another look at CFZ, which I only now have calculated for my two scopes, I think we are probably going to end up needing a user parameter. There are different forumlas for CFZ. Actual focus on a given rig may not correlate that well with your formula. In fact, how are you going to convert CFZ into focuser steps? Somewhere we have to tell the program the resolution of our focuser, its microns per step. Is that not going to require a new user set parameter?
So just to make this as simple as possible, why not just let us specify a minimum number of steps that the focuser should be moved. If the user has not set this value you can use something like 20% of the user’s step interval as a default.
Unfortunately for me, my RigelSys focuser does not implement StepSize.
I expect there are other focusers that don’t. Thats going to be a lot of folks who won’t be able to take advantage of this feature.
How about this: If StepSize is not implemented by the focuser, just use the default of 20% of the user’s step interval? Simple and takes care of all of us.
We can try this and see how it performs. Also, do reach out to the driver’s author and ask for it… it is likely information they have on hand and extremely easy to add to their driver. I think I will also add an option for SGPro to shim this value in. I suspect a lot of focusers maybe even publish this data in their specs.
I will reach out to the Rigelsys guy. However, I think it may be unlikely. His focusers use a plastic gear that attaches to the hardware focuser focusing knob, either the high speed one or the slow speed one. So it just turns one of the two existing focuser knobs. That then depends on the model of focuser the gear is attaching to. So he will have dozens if not a hundred or more different combinations to deal with. His focusers attache to probably focusers from every focuser manufacturer. I don’t think that is feasible for him.
If you go with something like a default based on the users step interval, anything between 10% and 20% works well for me. That corresponds to a temperature change of between .5 and 1 degree F.
It would be good to have the option to enter the step size manually. If it is hard to get the specs, it is pretty easy to make an accurate measurement (within 10%) oneself. I did this on my own homemade focuser. Simply rack it out from lets say 10% to 90% of its total travel length, measure the distance traveled (can be made within 1 mm) and simply divivide the distance travelled with the number of total steps that racking required. That is your step size. I then used this value and the CFZ to estimate the step size for my focuser, and it worked first try.
Like Mikael I once calculated the step size of my focuser. Actually my focuser controller is independent of the focuser hardware. So in my case the focuser controller software requests the user to input the step size in µm/step, and the ASCOM driver (hopefully) will pass on this value to SGP.
Alright… here is how the beta will be released. We will try the method I detailed above and allow for an override specification of “step size (in microns)”. If your focuser does not define step size and you provide no override value, we will punch in 15% of the AF step size value. If you don’t have one of those, we just apply the change.
Ever wondered what the “custom vars” field is for (at the bottom of the gear list when you expand it)? It is for exactly this situation where we want to try some stuff, but aren’t necessarily at a point where we want to go through modification of the UI or maybe not even sure what we are after collecting.
In this box, you will need to type this:
focuser_step_size_microns=22
Obviously, replace 22 with your value as @mikaelA and @bulrichl describe above. Fear not, you can also add these custom variables to your profile so they will be in your new sequences.
Assuming a 1 degree shift downward with a temp comp value of -5 steps per degree, the resultant shift does not use the step size (at least not in 3.1)… just applies -5 steps. The step size is used to determine if the requested compensation meets a minimum threshold. In this case, you entered 30 microns. The scope you posted on that other thread is f/3.8. This scope is pretty fast and has a CFZ error of ± 24 microns.
Given all of this, we convert the requested movement to microns (5 steps * 30 microns / step) = 150 microns. Since this is larger than your CFZ threshold, it will be applied.
specify an objective size so you can calculate the f value for the scope, and with the pixel size which you already know, you will calculate the CFZ error value.
we then tell it our stepsize through either the focuser ascom, or your “custom vars” field.
we also need to turn on temperature compensation and provide our temperature compensation steps/degree.
Then the smallest T change that would move the focuser by the CFZ error value will be the threshold for applying the correction.
