Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.
Request new focuser tools: focuser characterization, focuser backlash, focuser temperature compensation
Point 2: While I concur that the method of measuring HFR can be a step in a better direction, HFR readings can be very suspect to momentary bad seeing variability. A slightly more rigorous approach would be better. IMO, it was a mistake to allow users to set a step size directly in the GUI. This info should have been automatically calculated from known parameters of the optical system and a user estimate of best seeing and acceptable focus tolerance. See this reference for details: www.goldastro.com/goldfocus/ncfz.php
Folks who take the time to read the above will know the size of their gear's CFZ. A 1/3 CFZ stepsize would ensure the right focus is always obtained (for well functioning focusers). The most difficult aspect of the above is that the Ekos step size must be known in motor counts, not microns. To find the correct step size in motor counts, a user must drive the focus motor through some measured focuser travel (or know the thread pitch of the internal focuser's drawtube and motor counts per rev). Many refractors have a scale right on the focuser to make this easier, so the #counts per mm (for instance) can easily be found. In the end, the # of motor counts per micron yields a correct mathematical answer for step size. IMO, the GUI should have been better thought out and is at the root of much of the confusion.
On point 3: I've been using a developed temperature based focus compensation (also with altitude residuals) in my own Ekos branch for many months now (search temperature compensation for postings). I have reduced my autofocus runs to a minimum. I don't waste precious observing time on focusing any more. I offered the code to anyone who wanted it and suggested it could help the community. I made clear from the start that I wasn't a GUI developer, and I developed the feature with a config file. Some suggested a GUI was desirable (I didn't disagree, but it isn't necessary strictly speaking). Unfortunately, no volunteer was found to develop the GUI to replace the config file (used for controls and function(s) definition). So, the community wide effort was abandoned for lack of interest. Some folks actually prefer the simplicity of repetitive focusing. For my f/2.2 rig, this was too much of a waste of time to bear. To each their own! Cheers, Doug
Doug, thanks for chiming in. This is the type of feedback that will aid in making this stuff a reality.
Regarding your comments on Point 2, there is already a mechanism in place to average seeing by taking multiple shots. Wouldn't this go a long way in making these readings more accurate? I think for most users, as you say, would benefit from some form of automatic characterization. Unless those users are familiar with their focus system and it's characteristics and what will work best for any given focus algorithm, there is no way for any beginner to read the existing tool tips and understand the correct parameters to plug into the software interface.
On point 3, I love that you've done this. I know you send me a message offering access to the code, but I don't have the technical fortitude to apply it. Would be happy to test it out though if it gets merged into the system. But at least in the beginning, I think all you would need in the interface is a simple field on the capture/sequence tab below the existing refocus parameters to input a #steps to move / degC. Of course, this leaves it up to the user to manually plot out and note focus positions during temperature drops to characterize their system, but it's a start. Longer term with the analytics tab, temperature and focus position could be plotted over a nights run (even multiple nights) and that step change/degC could be automatically populated into the field for a user.
I am not sure I see the point of not allowing the user to set step size in a GUI. It is very easy to determine the optimal step size by just running a couple of test runs using the linear focuser and inspecting the V-curve. As you write, the main issue is variable HFR due to seeing changes. This is obviously a much bigger problem the larger the aperture and the smaller the f-ratio is. For my systems, i.e. a short wide-angle WO refractor (250 mm FL at f/4.9) and an ES102ED-CF, the manual step selection is completely sufficient. I have simply set my autofocus routine to run as soon as Delta T is > 1.5C. Anything below that does not induce a focus shift greater than the tolerance of 5% I have set for the linear focuser.
However, focus shift is a much more critical issue for your RASA, of course. Still, the GUI option of setting the step-size ourselves remains a fast, effective and practical solution for the majority of users, IMO, especially for those of us who clobber together their own aufofocusers.
Atlas Pro AZ-EQ, ASI1600MM-Pro, ASI120MM-S, ES102ED, WO-Z61, Nikon D3300, ASI-EFW, ZWO LRGB,Ha,O3,S2 filter set
Hi Jo, I accept it's ok to allow the step size to be user set, but I don't think it's optimal. There are many users who will not get this set right (and there is a "right" setting to within a tolerance). It's true that you can experiment with a V curve to iterate/guess at step sizes, but I prefer a measurement that relates to CFZ and the motor/drawtube relation. That prevents jumping over the CFZ and not achieving best focus (i.e. step size too big), and wasting a lot of time (iterating through measurements where the step size is too small).
Hi Andrew, yes, multiple measurements makes for better averages, and I do this as well. It takes longer, and this is part of the reason I like having a solution to OP #3. I'll note too that there is already a log that captures the temperature to focus position relation (as well as altitude). The details of that log are found in the posts related to temperature compensation. Much of the automation (calculation of the function coefficients) was done in the code, so there shouldn't be a need to have much user interaction (other than to apply or not).