Let’s split things down a bit.

1. You have the algorithms - they take a set of data and work out where the optimal focus point is. The data could be a set of images plus focuser position or something like the current temperature and some preprocessed info for it to work out where the focus point is.

2. Backlash - this occurs afaik on change of direction of the focuser mechanism. Simplest solution appears to be to overshoot by some amount greater than the max backlash then move to the real position. It doesn’t really matter if the backlash varies each time or in either direction as long as the overshoot is greater. (I’ve no idea why NINA looks to have settings for both - this could just be the gui misleading me and only one is actually used).

3. Final move direction - in the case of sct’s with a focuser moving the mirror final the move direction needs to be against gravity. This move would also need to apply backlash compensation if it was a change of direction.

Current setup seems to not be quite right as it different parts seem to try and solve problems of other parts. I think the link between the backlash setting in the main gui needs splitting off from the focuser indi driver. Then the backlash compensation done independently of the algorithms and drivers if wanted by the user. The algorithms shouldn’t have anything to do with backlash. The indi driver could implement some focuser specific compensation if needed. The final move direction I think would be in the driver and would be active on every move that’s not in the ideal direction. This would shield the algorithms from bad positions without them having to know about it.

Just testing this change on the simulator.

So the backlash field remains as is and is linked to the Indi field (so can be changed from either the focus screen or Indi for convenience).

Backlash field - used by device drivers as today (no change), not used by autofocus routines with this change.
AF Overscan field - new field so provide "overscan" by the Linear and L1P algorithms. Set to 0 to disable.

The Backlash and AF Overscan fields now operate independently so either, neither or both can be used (depending of course on your device driver's capabilities).

What is this overscan thing? Is it just backlash compensation implemented in the lp1 algorithm? Wouldn’t that be the same as breaking the link between the current backlash entry and any driver backlash? What about the other algorithms? Isn’t there a way to implement backlash compensation somewhere between the algorithms and driver? If that was done all focusers would have bc even if their indi driver didn’t implement any and it would work for all algorithms. People whose focuser drivers had a more sophisticated/specific bc setup could use that and switch off this one.

What is this overscan thing?
I've called it Overscan as the existing field retains the title "Backlash".

Is it just backlash compensation implemented in the lp1 algorithm?
Backlash compensation as in the Overscan method for outward movement in Linear and L1P.

Wouldn’t that be the same as breaking the link between the current backlash entry and any driver backlash?
Yes.

What about the other algorithms?
Iterative and Polynomial are unaffected by this change.

Isn’t there a way to implement backlash compensation somewhere between the algorithms and driver?
Well its all code so anything is possible with enough time and effort but currently this isn't a simple task.

@John: So the two settings are in two different places? The overscan in Settings, and BL in Mechanics? I'd rather have them in the same tab, to indicate it is two different/separate things. But yes, this looks fine (maybe except for the 20000+ outward steps, they'd move my focus tube some 50mm ).
Oh, and what is than CFZ thing?
Are you locally testing that, or is it already pushed to git?

@Nigel: Not sure if 'overscan' is the proper phrase for it, but yes, it's that method that Linear and L1P use, by moving further out and then return inwards when an outward move is requested.

And yes, it would be great to have that as a general feature of EKOS, and is what I had asked for in the Whishlist forum. It seems to be difficult to do this, IIR the reply correct it 'would have to be in the driver'. I'd interpret that as 'the modules talk directly to the driver'. I guess what would be needed is an abstract layer between the driver and whatever uses it, that forwards settings to the driver, but has the additional possibility to do such an overscan move. Then any algorithm, and even manual moves from the focus tab, would benefit from it. But I know too little (read: nothing) about the internal structuring to judge if that would be possible or not.

The parameters in general need tidying up... I'll hopefully get to that 1 day.

Don't worry about the big step movements, its just my config on the sim.

CFZ is part of the next phase of focus developments that I'm working on. Its early days so won't be coming out for a while as I keep getting sidetracked by production support Just kidding. The changes cover quite a bit more than just the CFZ (hope you like the yellow moustache on the graph). These changes aren't in git yet.

When I get a bit further with the spec I'll post to the forum.

CFZ - don’t suppose you are working on some way of putting the central focus area towards the back of the cfz so those who either don’t have flatteners or whose flatteners don’t quite work have more of their image in the cfz? Or is that a daft thing?

How are you working out the cfz? I’ve seen different ideas for working this out which for my setup seem to range from over 150 microns down to 20.

Regards

Nigel

There will be several algos for CFZ so you'll be able to choose what you want.

Not sure I completely understand your question but if you want to focus on a certain part of the sensor you could try setting the Annulus field. Only stars in the annulus will be used for focusing.

The Annulus itself is centered, so it's not really possible to analyze, e.g., tilt this way. (Which would be a great addition by itself, like splitting the area in several fields and process them separated to look for systematic drifts...)

Do you mean like the FWHMEccentricity script in PI?

Oh, and I completed testing on the sim for the "Overscan" change we were discussing. I can't test on my rig at the moment due to bad weather. The code is in...
invent.kde.org/education/kstars/-/merge_requests/795

Its not merged at the moment as I need to test it some more on my rig and also as there's a lockdown on new code ahead of next week's 3.6.2 release.

ok this is just an idea based on a theory based on reading various websites… so may be completely stupid….

In the C6 manual when it goes on about how to focus, it says to go counter clockwise as the last step (ie lifting the mirror). Then when you have got your target in sharp focus (I’m sort of assuming the target is in the middle here as I’ve not got the manual to hand) to give it an extra turn of 1/12th of a turn for visual use and 1/24th of a turn for photographic use.

What I believe the idea is, is that given the sensor is a flat plane but the image focus point is in a curve with the edges further ‘in’ , that moving it a bit further moves the central part towards the back of the cfz and in doing so brings more of the edge into it.

For my setup C6 with a Celestron focuser we are on about approx 30 microns or 40 steps. This sort of matches somethings I’ve read (specifically the article from sky and telescope in 2010 by Don Goldman and Barry Megdal - In perfect focus - link astrodonimaging.com/tutorials/ ) the cfz for an f/10 is around 40 micron and f/7 around 20 micron in one direction (so I assume 40 and 40 wide).

So once in focus on the target in the middle of the image a step out of 40 would bring more into the cfz.

Possibly this is a bit of a old idea and that doing the focusing using the whole or large part of the frame makes it irrelevant.