That's a good way to simulate the pier side. Nevertheless I'm not a fan to drag this inside of EKOS but leave this inside of the INDI driver. Maybe we could add this function in a foundation class like inditelescope.cpp so that we do not rely on all single manufacturers to implement it.

Nevertheless, it's a workaround and does not cover all edge cases and pier side strategies of all mounts. The ultimate point of truth is the mount and it's firmware, since it ultimately decides wich way to turn the axis.

Oh, I indeed overlooked that. I was (only) looking for EKOS options to tell PHD2....
The question then is, how does PHD2 detect a Meridian flip? Maybe they already have the code that we are looking for?

Hmm, not too informative that table. Just to say ASCOM supports it so not needed to set is a bit Windows-centric
I still wonder how that driver is doing it. Unless you have access to the raw coordinates of the motors you can only guess and/or derive it from the command history, or am I missing something here?

Sorry, it seemed so obviously a mount function that it didn't seem worth saying so explicitly.

I'll have a look, initially for individual drivers but as you say it could go into the base telescope class. It needs thinking about because not all mounts need pier side, fork mounts for example don't usually use this.

Chris

Oh wait, guess I got fooled. That is something different. It is an additional thing that some mounts need, but is not triggering any meridian flip by itself. It would be applied in addition to the rotation of the guide matrix, and doesn't tell when to rotate. But ioptron mounts don't need that option checked.

So we're back to the point that someone has to tell PHD2 to actually flip the coordinates. If the mount/driver supports pier side, it's done automatic, without pier side I either have to do it manually, or EKOS / the scheduler have to do it.

I agree, this should probably not go into the driver itself, else it needs to be done for every mount/driver that doesn't support it natively. So a wrapper function that uses the mounts info if present, else does some guess work....

If I read the other posts in the thread correctly and if the mount does not report side-of-pier then if that option is not checked, DEC guiding runs away after a flip.
But no need to guess, just use Tools -- Calibrate meridian flip in PHD2 and it will tell you whether or not you need to check the 'Reverse Dec output after meridian flip'.
Cheers and clear skies.

No, not true. at least not for me (CEM60EC, ieqpro driver). I don't have it checked.
True, guiding runs away after an automatic meridian flip initiated by EKOS. But it runs away in both axes, also RA, because the calibration orientation wasn't flipped. I have to do it manually (Tools->Modify Calibration->Flip Calibration Now...). Then it perfectly guides in both axes.
While I haven't tried, I'm definite sure that if I check it, DEC would run away after flipping the calibration.

The setting only affects how the guiding calibration is flipped, but doesn't tell when to flip.

The problem with the current implementation is that is applied on the Guide module, unrelated with the Scheduler one, but the configuration parameter to always reset calibration is inside the Scheduler configuration. This is very misleading, because users that are not using the scheduler will don't know why now the guider behaviour differs from previous versions. In my case, I've been struggling over a week, trying to understand why PHD2 was now loosing the calibration after each slew. Only when I read the source code for this patch, I understand that the problem is related with the scheduler option. I'll recommend to move this option directly to the guide configuration where it belongs if the logic to associate it with the scheduler state is so complex.

Wherever that check box ends up, doesn't matter to me. By now I know Ekos and its behavior inside out, having tested all possible combinations. I know where every box is and what it is doing (I hope).
Key is that the option remains in the code, because if not, my mount and that of several other users would become unusable. When using the internal guider, recalibration is pretty fast, hardly noticeable, but I agree, PHD2 is S-L-O-W and thus it could be a drag on PHD2 users. Personally, I do not understand why anyone is using PHD2. The internal guider works just fine.

But simply unchecking that box will solve the issue, simple enough, I hope.

Which box are we talking about here?

We are talking about this checkbox:



It's inside the Scheduler configuration, but it affects all guide operations. I think that it must be renamed to "Reset calibration after each mount slew" and moved to the Guider calibration configuration:



Obviously I'm not asking about removing this feature, because it's useful. I'm only proposing a change in the way that it's shown to the users. I try to reduce the confusion that the current placement / implementation is causing.

Alright, it's done.

As El Corazon said, we get accustomed to the way things are, where they are located and what they do. But it's frequently changes like this that happen in the background that are a source of confusions to those who do not follow ongoing development closely. As these changes can be subtle, and not at all apparent. It would be nice if KStars included a basic changelog, perhaps with links to a related development thread for more information.

Example, a note in the changelog could say.
-Change to force guiding calibration will now clear recalibration on each slew when option to always reset calibration is enabled.
And
- Always reset calibration option has been moved from the scheduler options to the guiding options.

So just having a place of reference to look first when caught off guard by new changes would be very helpful.