Difficult weather conditions last night with passing thin cloud in patches. A good time to test.
I have problems with Linear 1 Pass focussing during an imaging run.

The above image shows a focus near the start during a period when seeing was a little better than other times. I know the focus position for all 3 filters is similar at step count 25,000 +/- 300.

Above shows an auto focus during poorer seeing conditions when the focus position was determined at 23,750 way outside the actual focus position. Inspection of the image taken immediately after the auto focus shows star images as small discs. I have a RC telescope. This happened about midway through the job but its game over now because the next auto focus starts from this erroneous position and this continues for all subsequent auto focussing with the focus position getting further off.
Would appreciate any help answering these questions:
1) How can I stop auto focussing having a successful result when clearly to the human eye they are not in focus? Is this a fault with the software or is there a better setting for star detection for a RC telescope.
2) The focussing mechanics has a max travel set of 2000 but focussing often exceeds this. In the example above the steps went from 23450 to 26550, a travel of 3,100?
3) As I know the optimum focus position +- a tolerance would it make sense to modify the interface to allow these values to be entered and if the focussing algorithm exceeds the range it defaults back to the known optimum position and tries again. Maybe after 3 attempts just reports a warning and carries on at the optimum position.
4) Warning in log: [2022-09-06T02:06:05.055 GMT Summer Time WARN ][ org.kde.kstars.ekos.focus] - Focus GSL error: invalid argument supplied by user. What did I do?
Out of focus image taken after poor focus.

Here are my focus settings:


Suspend guiding is selected but analyze bar chart shows this didn't happen? Trying to puzzle this out. Actually I don't know if its a good idea to suspend guiding whilst focussing. Mount is well aligned and no appreciable drift over the 3 second exposure.

I am also trying to understand what triggers the in-sequence auto focussing but will raise another Topic.

• disable the guide. somethimes with KStars 3.6.0 it run during the focus procedure
• remove the flag on the Full width. Use auto select star or select a star near the center of the frame. wide focus it not muth accurate
• reduce the initial step size to a value near 50 or less
• change the Out step multiple to the lowerst that is 1.0
• change detection to SEP
• change the curve fit to the last option in the dropdown

always take a look at the procedure because in my case the result is not the correct focus, i correct it manually and/or i change thje algorithm to Interective

Thanks Alessandro. Interesting to hear what settings you use. I will check out the settings you suggest next clear night. Interesting to hear suspend guiding doesn't work for you either. I need this to work reliably and automatically because I will be tucked up in bed! My step sizes will be larger because using fine focus. I have alternative 3D bracket to fit the ZWO EAF to course focus. Not worked out which is best yet.

Hi David,
I'll try and answer your questions...
1) How can I stop auto focussing having a successful result when clearly to the human eye they are not in focus? Is this a fault with the software or is there a better setting for star detection for a RC telescope.

I don't have an RC so others with one would be in a better position to comment.

2) The focussing mechanics has a max travel set of 2000 but focussing often exceeds this. In the example above the steps went from 23450 to 26550, a travel of 3,100?

The 2000 refers to travel from the start point. So if you start at 25000 and have a setting of 2000 you can go from 27000 to 23000.

3) As I know the optimum focus position +- a tolerance would it make sense to modify the interface to allow these values to be entered and if the focussing algorithm exceeds the range it defaults back to the known optimum position and tries again. Maybe after 3 attempts just reports a warning and carries on at the optimum position.

Looking at your data it looks to me like you are moving the focuser too far away from optimum focus and probably getting donuts that are confusing things (datapoints at either end looks wrong). So you have 2 parameters here to play with... number of steps and step size. I would start with 4 or 5 as the number of points. As you're on an RC lets say 4. So you need the step size to be something that a) is big enough to give a different HFR but b) small enough that 4 * step size still gives a good solid datapoint. If you go to this position manually and hit the "take a frame" button you can see the detected stars and the HFR average. Do this a few times. It should be stable and consistent. If not your step size is too big.

You need a reasonable number of stars. If the number is dropping too small when you're out of focus you're travelling too far. Hard to put a figure on it but <5 I would say expect problems. If you need more stars: increase exposure time, increase gain, try binning, increase annulus, etc.

I would also suggest trying a Weighted fit. It gives better results on my refractor (hopefully will work an an RC too).

4) Warning in log: [2022-09-06T02:06:05.055 GMT Summer Time WARN ][ org.kde.kstars.ekos.focus] - Focus GSL error: invalid argument supplied by user. What did I do?

I would suggest changing the Curve Fit from Quadratic to Parabola. This will use newer curve fitting logic but will fit the same type of curve. This should make this error go away.

Hi John. Thanks very much for your response. As it happened, I started to experiment last night with settings as you suggest before I read your response. Last night was tricky with passing high cloud and in the end the thick band of cloud arrived so had to abandon for the night. Thanks for clarifying the max travel distance is +/- from start point.

When you have varying amount of cloud during the focusing exposures, does the algorithm in some way compensate for this or do we expect the points to be scattered further from the best fit curve? When I say compensate, are the hfr values adjusted to a mean sky background using photometric methods? In short can we expect focusing to work during the passage of high cloud (when varying but sufficient stars detected)?

Turn guiding off whilst focusing in the focusing module doesn't work. I watched the clouds pass by in the guiding module whilst focusing was happening but guiding continued. Without testing I am not sure I want to turn guiding off anyway but none the less it should work?

During a passage of time when cloud prevents sufficient stars to be detected, focusing fails and focuser is put back to last known focused position, what happens next? Does the mount continue to track with image capture suspended? Does the focus module pause for a short while then attempt a further focus repeating focus attempts until either sky clears sufficiently for a successful focus or job end condition is reached.?

Still trying to understand how capture, focus, guide and align modules interact and what triggers what especially during periods of passing cloud.

Hi,

Answers below…

When you have varying amount of cloud during the focusing exposures, does the algorithm in some way compensate for this or do we expect the points to be scattered further from the best fit curve? When I say compensate, are the hfr values adjusted to a mean sky background using photometric methods? In short can we expect focusing to work during the passage of high cloud (when varying but sufficient stars detected)?

Generally cloud will cause problems. Although SEP background subtracts object flux as part of its processing you will unreliable results when it’s cloudy.

Turn guiding off whilst focusing in the focusing module doesn't work. I watched the clouds pass by in the guiding module whilst focusing was happening but guiding continued. Without testing I am not sure I want to turn guiding off anyway but none the less it should work?

The idea is that if you have a separate guide scope then no need to turn guiding off. If you have an OAG then it will move out of focus and potentially cause guiding issues, hence the option to suspend guiding. The option checks that the imaging and guiding scopes that you setup in Ekos are the same. If not, it will not suspend guiding, even if option checked.

During a passage of time when cloud prevents sufficient stars to be detected, focusing fails and focuser is put back to last known focused position, what happens next? Does the mount continue to track with image capture suspended? Does the focus module pause for a short while then attempt a further focus repeating focus attempts until either sky clears sufficiently for a successful focus or job end condition is reached.?

When focus fails it retries. On 3 fails it returns control. If you run focus from the GUI then you have control. If it’s running from the scheduler then the scheduler has control. It usually will just retry focus again.

Usually, when focus is running, tracking is running, capture is suspended and guiding may be suspended (see above).

Hope this helps.

I am still a bit woolly on focus failure. I have seen focusing repeat another pass, I guess its failed and trying for a second or third time. I am trying to run imaging as Jobs so will try and work out what the job does if focusing returns control. There are limits that can be set in the capture sequence and maybe some in the job so need to study this.

Thanks for the OAG explanation. I hadn't picked that up. The EKOS documentation takes a slightly different approach:
Suspend Guiding: Suspend Guiding while autofocus in progress. If the focus process can disrupt the guide star (e.g. when using Integrated Guide Port IGP whereas the guider is physically attached to the primary CCD), then it is recommended to enable this option. When using Off-Axis guider, then this option is not necessary.

Would be handy if Dialog label or hint text gave a clearer explanation. Suspend Guiding option box not ticked and greyed out if using a guide scope or allow suspend guiding to work with a guide scope and let the user make the call. It's a confusing dialog if nothing happens when clicking this option.

I have downloaded code from github onto the PI and compiled my own copy of a driver. I need to get into the code more and need find the best place for help and documentation. I could answer my own questions then! Thanks for your patience.

I am still a bit woolly on focus failure. I have seen focusing repeat another pass, I guess its failed and trying for a second or third time. I am trying to run imaging as Jobs so will try and work out what the job does if focusing returns control. There are limits that can be set in the capture sequence and maybe some in the job so need to study this.

The Linear algorithm makes 2 passes, the Linear 1 Pass algorithm makes 1.

A good way to get familiar with this is to setup the simulators and practice focusing with these rather than wasting imaging time. If you configure the telescope simulator, focuser simulator, CCD simulator and Filter Wheel simulator you can try out whatever you want. For example, if you set the focus annulus to 50 : 50 you will simulate zero stars (like cloud cover) and see how the system behaves with retries etc. So you can get the options you want and then set the options on your real rig.

Thanks for the OAG explanation. I hadn't picked that up. The EKOS documentation takes a slightly different approach:
Suspend Guiding: Suspend Guiding while autofocus in progress. If the focus process can disrupt the guide star (e.g. when using Integrated Guide Port IGP whereas the guider is physically attached to the primary CCD), then it is recommended to enable this option. When using Off-Axis guider, then this option is not necessary.

I updated this section in the manual - are you looking at the latest version?
docs.kde.org/trunk5/en/kstars/kstars/tool-ekos.html#ekos-focus

Would be handy if Dialog label or hint text gave a clearer explanation. Suspend Guiding option box not ticked and greyed out if using a guide scope or allow suspend guiding to work with a guide scope and let the user make the call. It's a confusing dialog if nothing happens when clicking this option.

I agree. I don't know why it was done like this.

Not tried simulator yet. Will try it out.

The link I used for documentation: indilib.org/about/ekos/focus-module.html

Yeah, that looks out of date. The link I sent you is the latest doco. The project needs more volunteers to maintain the documentation.

Pulling my hair out tonight testing auto focussing. I did some 30 sec image captures manually changing the step count and bracketing around where I can see the sharpest focus. Auto focussing results in step values sometimes quite far from where I know it should be. I am struggling to get a good V graph. It's only an impression so I could be wrong but the HFR value isn't accurate with my images especially away from the best focus position. Here the star images are not perfect more fuzzier round blobs but break up into 2 or 3 spots.
To test further I need to capture the auto focus images so I can load in fits viewer and analyse. I think I came across an option to do that but failing to find it again. Can you point me to the setting please?
I would also like to create a script so I could step the focuser at a given step size and capture my own images. And run it both ways to check if I have any focuser or optical issues. Is this possible?
I may be missing something but I didn't find the simulator useful as it doesn't take an actual image so can't see how it can help. Struggling to find documentation on how to use the simulator.
Thanks.

I think you need to decrease step size. Set it to that value that 2-3 step from ideal focus it will give you HFR around 5. Another good estimate is set step size to CFZ which is calculated as 4.88*550nm*(f-ratio^2) for f/4 scope it is 42944nm or 43um. Then you just need to calculate how much does one step of focuser move.