Along those lines, has automated testing for features and fixes going forward been considered? If something was fixed and a test was created as part of the fix, then it should break the build if it is modified unknowingly or removed. The time it would not help are if a completely different version of the code tree is merged in that does not have the fix or the test.

I have experienced what the OP is talking about as well, so am trying to suggest ways to mitigate it and allow Jasem, Eric and our other devs with limited time to focus on forward-looking things instead of churning in fixes.

Jim

I second this request.

During recent months much work has been directed towards introducing new features and drivers. At the same time a few bugs creeped into other parts that did work OK in the past, impacting functionality. Some of these bugs have been left unaddressed. I'd favor an older, "hardened" version with a few "hand-picked" bugs removed over any new, feature-rich one.

Ok, so this is NOT a scheduler issue. I worked on this today and made the Guide module aware of the pier side property IF supported by the mount. In cases where the pier side changes AND calibration was already done, it simply swaps the DEC switch and not recalibration is necessary. I will test this tonight as well to make sure it works as expected.

This has to be validated against PHD2 too. PHD2 has a setting to invert the DEC information from the mount depending on pier side. This setting has to be clarified if Ekos alters the mount configuration.

-Eric

The change that I made (and forgot to push on my work PC) is only valid for internal guider.

I support the change. It is equivalent to the "reverse DEC after flip" in PHD2.

-Eric

Maybe I am interpreting this wrong, but that was not the problem I had. When imaging the same target, the guide module recalibrates reliably after the meridian flip.

The problem I encountered occurred when the scheduler was managing more than one target. After the first target slipped below altitude limits, the scheduler would then - correctly - switch to the next target in line. However, the guide module would not recalibrate. Which resulted in the ugly image I posted above: After switching to the second target on the other side of the meridian, the guide module would continue to use the previous calibration data from Target 1 now on Target 2. Which means that not only DEC is now reversed, but RA would also not be optimally calibrated.

It would be safer to just instruct the guide module to OPTIONALLY clear the data and recalibrate after EVERY meridian flip or else swap the DEC data, AND DEFINITELY recalibrate upon switching to a new target.

If "Always Reset Guide Calibration" is check (by default it is), then it is reset after meridian flip. When switching to a different target like in your case, as soon as the pier side changes, the DEC is swapped so recalibration isn't necessary. At any rate, this is all theoretical I yet have to have a clear night to test it out.

For robustness when processing targets that are far away, I agree you should reset calibration for each. For close enough targets, such as mosaics, this should not be necessary (but see below). With DEC now swapped properly, calibration should survive the flip.
It must be noted that calibration results are different at zenith and at horizon, I certainly confirmed this with real-life tests. Damage due to a calibration done 4 hours before is clearly visible on my F=480mm.
So long-exposure targets, even close from each other like mosaics, should benefit from being divided to recalibrate in-between.
So there is room for improvement on when to reset calibration. We could consider using the same method as the refocus mechanism, but using HA/altitude-based angular distance instead of elapsed time.

-Eric

I agree, Eric, that was my assessment as well. It is not without cause that PhD2 asks for the Declination of the target prior to calibrating.
That's why I would prefer to rather calibrate one time too often than one time too few. Only after a meridian flip, while staying on the same target, i.e. when Declination does not change, should just swapping the DEC data be sufficient.
In all other cases, when DEC is changing, I would think only recalibrating can yield optimal results.

Thankfully KStars internal guider calibrates very quickly, so it's not a big deal to repeat this procedure.

But a better approach is to use the declination and side-of-pier to calculate guiding adjustments, so that the calibration remains valid all over the sky. Just as with PHD, PHD2, TheSkyX, or MaxIM DL, it's unnecessary to calibrate for a specific target.

Rather, calibration provides the orientation of the guide camera and guider image pixel scale relative to the sky. The rest of the guide pulse calculation is precisely deterministic from the declination and pier side.

There's no reason to calibrate again unless you either (1) change out equipment -- mount, guide scope, camera; or (2) forget the declination and side-of-pier where calibration was performed. Unfortunately it appears that the KStars guider does the latter every time!

Something that looks to be robustified is the calibration. I have very often bad experienced with it while I don't meet the same problems with PHD2.
So when the calibration fails on Ekos I switch to PHD2.
I don't know what are the algorithms that are used in PHD2 but they look to be more robust than the ones of Ekos. Or maybe I have a serious problem of parameters in Ekos calibration.