I have submitted a change to the dithering behavior in Ekos (of course, in the beta codebase). For those of you who run beta code, please test and let me know if you have feedback. Here are the changes:

Before this change

When dithering is activated, after a capture is completed, Ekos suspends guiding and capture, computes a random pixel offset, and moves the guide-star target position by that offset. It then uses standard guiding code to move close to that new target position, sending guide pulses to correct the pointing position until it is within a pixel in x and y image coordinates of the desired position. It may take several guide pulses to reach the new target position. Once the position is reached, guiding is resumed and then a new capture is started.

It is possible to disable guiding in RA or DEC, or disable one of the directions (east or west, north or south). When one guiding direction/motor is disabled, not only does Ekos not guide in that direction, but it does not send dither pulses in that direction (even though it may still decide to add a random offset in that direction--which is a bug). That can cause a situation when dithering will fail because it cannot achieve the desired dither offset.

Changes

Change #1: One Pulse Dithering. Since the dither target position offset is randomly computed, it is not critical to reach the exact random dither position. Therefore when dithering, Ekos will estimate what single RA & DEC pulses are necessary to move to the randomly generated position, and issue those pulses. However, it will not iterate with more pulses to refine the new target position. It will begin guiding from the position that was reached with the dither pulses, and use that as the new target position. This should result in simpler, more reliable and quicker dithering, with the same benefits of dithering. It is possible that some dither moves are less than originally randomly generated, e.g. due to backlash, but overall the dithering should continue to be effective.  This change is controlled by a new checkbox, see below, which defaults to "off". In future releases, assuming this works well, my intention is to remove the checkbox and only use the new behavior

Change #2: Always dither in both RA & DEC. With the new code, dithering will not obey the guider's axis & direction restrictions. Thus, even if one chooses to only guide in RA, dithering will occur in both RA and DEC. In the past the dither was computed for RA and DEC, but the dither pulses in disabled directions were blocked, possibly leading to failed dithering when the positions weren't reached. Now the dithering pulses will be sent.

I think these changes makes perfect sense, so thanks for that!

When you submit something like this, will it automatically end up in the next kstars/indi/ekos release or will it go through some testing and a pull request before it appears in the stable release?

It went through some testing, and a code review by Jasem, and now Jasem has merged it into the beta (nightly) release, where it is accessible to adventurous KStars users who are willing to use/test the beta/nightly releases, e.g. see the "Nightly Build" section in indilib.org/download.html, or who compile their own versions of KStars. I will continue to test as well, skies permitting. At this point it is part of the next planned stable release, but, of course, if issues arise during the beta test period (the time between now and that release) I will try and address them before that stable release is complete. 

This thread is my attempt to encourage folks to test this feature further before that stable release.

Hy

PS Here are the commits to the KStars master branch: invent.kde.org/education/kstars/-/commits/master/ and right now you can see that this change is the 3rd most recent commit with ID 31f0ef70 and name "Dither and Calibration Cleanup" whose detail is here: invent.kde.org/education/kstars/-/commit...19db3069b435ecea8a9d

Thank you Hy, the second change is exactly what can resolve the problem described here: indilib.org/forum/development/9054-enabl...ion-is-disabled.html

Hi Hy, just a quick question: what is the algorithm for calculating the dither pulse length? Is it based on the last calibration or does it factor recent guiding / GPG data?

Also, it would be useful to understand how far the dither actually moved as in the current process if you asked for 8 pixels you know you got 8 pixels or a dither fail, but with the proposed change you won't know what you actually got. If you got 7 or 9 pixels then that's probably fine but if you got 1, you may want to adjust something to get nearer to the 8 rather than get a night's data with significantly different dither. Obviously, this could just be a log message, or on the Drift plot where it says "Dither" it could say by how much.

Obviously, some of the configuration parameters on the Dither tab won't be relevant if "One Pulse Dither" is checked (Threshold, Timeout, Max Iterations).

@hades

Yes, your earlier thread was the kick in the pants for me to make this change--I had been thinking of simplifying the dithering for a while but hadn't done anything. Thanks.

@john

Yes, the dither pulse length is computed by multiplying the previously calibrated "milliseconds of pulse per arcsecond of movement" by the "desired arcseconds of dither movement". It would be nice to use recent guiding data to update that calibration, another thing I've dreamt of doing (that is, adapting the calibration based on observed performance) but that is not currently done.

If one has debug logging enabled for guide, then the actual (realized) dither amount is shown in the log. It will differ for each individual dither. I don't think it's important for the end-user to know what each dither realized, even if in some rare events  you got 1 instead of 8, but you can look in the log if you wanted to (see below).  I didn't modify the code that computes the desired dither amount, but it is here:
invent.kde.org/education/kstars/-/blob/m...ernalguider.cpp#L230
Basically it tries to dither by the amount requested in a random direction, subject to a "MAX_DITHER_AMOUNT constraint on each axis.

The desired dithering and the realized dithering can be gleaned from log messages. Here's a few lines pulled from a (simulator) log:

[2022-01-07T14:37:36.429 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering by  8  started. Current ( 147.003 105.01 ) + ( -5.41898 5.88512 ) --> Target  141.584 110.895
[2022-01-07T14:37:41.083 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering in progress. Current 141.996 110.996 Target 141.584 110.895 Diff star X: 0.100734 Y: 0.412056

[2022-01-07T14:37:51.514 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering by  8  started. Current ( 141.996 110.996 ) + ( 7.49317 -2.80221 ) --> Target  149.489 108.194
[2022-01-07T14:37:57.662 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering in progress. Current 148.995 107.995 Target 149.489 108.194 Diff star X: -0.198455 Y: -0.493705

[2022-01-07T14:38:08.236 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering by  8  started. Current ( 148.995 107.995 ) + ( -2.10263 7.71874 ) --> Target  146.893 115.714
[2022-01-07T14:38:13.329 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering in progress. Current 147.009 116.003 Target 146.893 115.714 Diff star X: 0.289149 Y: 0.115791

None of these are consecutive lines in the log, but if you have verbose guide logging enabled and search for "Dithering by" and "Dithering in" you should find them. What you could see (e.g. first entries) is that the original guide star target position was 147.003,105.01, and it attempted to dither by 8 pixels on some random angle (dx=-5.41898 dy=5.88512) to 141.584,110.895 but it actually reached 141.996 110.996 which was an error of 0.100734 Y: 0.412056. Of course, the actual position it reached is subject to significant measurement noise (e.g. from seeing).

Finally, you are correct. I should have disabled some of the configuration parameters when one-pulse dither was enabled. I'll try and fix that. Thanks.

@Hy, thanks very much for the comprehensive reply. Also, thanks for the comprehensive documentation you supply with all your changes and the commentary you add to the code which really helps folks like me who aren't so familiar with it, to understand a bit of what's going on. 

I've used the One Pulse Dither on two or three sessions and up until the last session it worked well with no failures. In my most recent session I noticed a couple of times that I was getting "dither failed" messages but at the time I assumed that this referred just to a specific frame so didn't take too much notice of it. I saw 2 of these messages.

I've just been processing the data from the session and I see that there are quite a lot of frames that didn't dither. It would appear that once a dither failure occurred, dithering got suspended (although on screen I believe I was still seeing dithering messages indicating all was working fine - but I may be mistaken on this). When some event occurred like a filter change + refocus or a MF it looks like dithering resumed as normal.

It may be that this is how it's meant to work. I've used dithering for a while now but only ever had it fail in the last session so can't compare to the previous version.

Anyway, appreciate any thoughts on this.

Regards,
John.