Looking at gmath.cpp, calc_square_err is looping through all values of the drift array to calculate the RMS error, and I believe performProcessing is adding all movements (including dither movements) to the drift array, but I'm also not familiar enough with the guiding code to jump in and make any changes.

I suspect "Dither settle" is not what you're looking for. Dither settle is the time span between dithering being finished and guiding being resumed. I never quite understood what this is supposed to achieve. What you're probably looking for is "Guiding settle" which is (illogically, I might add) placed at Ekos Setup -> Options -> Ekos -> Capture -> Guiding settle. That's the time span between guiding being resumed and the next capture started. This (set to 13s here) provides enough time for guiding to get to a stable state before the next exposure is triggered. I've been advocating for moving this setting to the Capture Tab -> Options before where I think an "average user" would expect it to be.

Yes, Herrhausen, you are quite correct, however RMS values are still affected because of the shift in star position after dither. I do run dither settle for about 20 seconds or so, as my stars would appear egg shaped or rather Tadpole shaped because of the residual movement of the guiding action after dither. I think what may need to happen is RMS values should be taken AFTER GUIDING SETTLE time. This would at least eliminate the RMS values from showing incorrectly high values.

Totally agree!

The RMS error that is indicated does not affect the performance, even though its calculation is probably not correct as many of us have noticed by now.

What would be more important is to command the guide module to search for a new guide star following each dither event and then restart guiding. From the movements I am seeing on the guide plot, it looks to me like the module is moving the mount BACK to where it was before it started dithering, instead of resetting the position of the green square onto the shifted position of the guide star and then continuing from there. If what I am seeing is correct, that would negate the entire effect of dithering and explain why I still have these streaks in my OSC images, event though I am dithering like crazy.

Alfred, what do you think? Does that match what you are seeing?

Jo

Jo, the more I remember the guiding I've done before, the more I think you might be correct. I've noticed in processing that the offsets when aligning are pretty small even over several images, leading me to believe we aren't actually getting much out of the dither.

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.