×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Request new focuser tools: focuser characterization, focuser backlash, focuser temperature compensation

  • Posts: 398
  • Thank you received: 117
regarding OP points 2 & 3:

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
The following user(s) said Thank You: Jose Corazon, Andrew Burwell
Last edit: 2 years 10 months ago by Doug S.
2 years 10 months ago #70780

Please Log in or Create an account to join the conversation.

  • Posts: 527
  • Thank you received: 139
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.
The following user(s) said Thank You: Jose Corazon
2 years 10 months ago #70782

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

Hi Doug,

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.

Cheers,

Jo
 
2 years 10 months ago #70783

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
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).

Cheers, Doug
The following user(s) said Thank You: Jose Corazon
Last edit: 2 years 10 months ago by Doug S.
2 years 10 months ago #70797

Please Log in or Create an account to join the conversation.

Time to create page: 0.389 seconds