Just the quick side note that PHD2 also computes the RMS including the dither settle. So it rather seems 'common practice'

Jo,

I agree RMS doesn't have any effect on performance. Once RMS is shown, it should be correct though. With regard to dithering I have to confess it works pretty perfectly for me. What happens during a dither is the guide star as well as the green box are being moved by a certain amount of pixels in a random direction. Once guiding restarts, the guide star is fixed to this new position. The effect can be seen when blinking through the subs that have been taken this way. I've attached a small sample of cropped subs (8,8 pixel dithering, ASI 294MC Pro).

Alfred

You are right, Alfred, something definitely moves, also in my images, I see the jump when I blink through them. But it takes much longer for the guide star to be centered again after dithering than the time it takes when the guide star is lost and a new one is selected. That usually happens in a snap, 3 or 4 seconds usually, while it takes 10 seconds or longer for the guide star to be centered again on the drift plot after guiding is restarted following the dither.
I wonder whether it would not be faster and avoid these long intervals with the star moving incrementally to the center again if after each dither the guider would simply reacquire, and only once the same or another guide star is reacquired start the next exposure. Basically, the same what happens after calibration is finished.

Ah, got it. You're right, once dithering is completed it can take a few seconds for the guide star to be centered in the green box again. I THINK what Ekos does is move the guide star to the middle of the green box which has been positioned exactly X pixels away from its former position as defined in guiding -> options -> "dither X pixels". However, that doesn't take 10 seconds here. It may take up to 3 seconds. Alternatively accepting the guide star's current "after dither" position (regardless wether or not it has moved exactly X pixels from its former position) as the green box's new position and starting guiding right away would accelerate the process a bit but the well defined shift between two subs would be lost.

That beings up an interesting and quick dither algorithm. Instead of specifying the random pixel offsets for dithering, then spending time guiding to that spot, dither by specifying the random pulses for the DEC and RA motors (eg insisting on at least a pixel or two of motion). Then wherever it winds up is the new target. E.g. 0 time needed post pulsing.

Actually I like the idea. IMO there is no need for pixel-exact movement between two subs. We could leave settings as the are now, just allow the guider to accept a certain amount of deviation from the setting and make it guide from the actual "ca.-position" immediately. This would add another (welcome) "element of randomness" to the dither process, too.

Yes, and make it a lot faster. It would also prevent the ovoid stars that occur when exposure starts while the guide module still tries to position the star.
What that would require then is reversing the algorithm: Rather than centering the star in the green box, after dithering the green box is centered on the star.
One would probably also have to ensure that overall the cumulative dither over the course of the sequence never exceeds more than 30 arcsec deviation from the original position, otherwise there would be too much image information lost at the edges of the frame.

There is a mechanism established already that limits the guide star's movement. When Jasem fixed the not-so-random dither direction two years ago he said: "Thanks, I just pushed a fix for the not-so-random dither and used different algorithm and add a bounded area." indilib.org/forum/ekos/3466-lost-star-wh....html?start=12#26784