Yes, that is what I proposed, essentially.

Just program the scheduler and the guide module to IGNORE the DEC swap command when "Always Recalibrate" is selected. Then the problem would not occur with those mounts that do not detect pier side. With the ones that do, just don't select "Always recalibrate" and all should be fine.

All we need then is a list of those mounts, one way or the other.

PS: Flip and reacquisition and guiding of second target works perfectly for me, too, with my Orion Atlas Pro, which uses the EqMod driver and which detects pier side (AND using the internal guider!). Again, perfectly matches what you are seeing.

I just don't see how this would be a problem with the internal guider. That has always worked for me with my EQMod mount.

It doesn't need to; there is a setting in PHD2, 'Reverse Dec output after meridian flip'.

** For details of mounts which report side of pier, see here:
github.com/OpenPHDGuiding/phd2/wiki/Reve...-after-meridian-flip
It seems the latest ioptron ASCOM driver does report pier side, so it must be the driver's responsibility to report rather than the firmware...
Cheers.

What is really needed is for more mounts to report the pier side.

Here is a suggestion - when a slew command is issued use the hour angle of the slew destination to determine pier side. if the hour angle is less than 0 the pier side is West (pointing East) and if the Ha is > 0 then the pier side is East (Pointing West). There's a zone close to the meridian where the pier side might be wrong if the mount model doesn't change pier side exactly at the meridian but most of the time it wil be correct. Pier side can only change when a slew is done, not when tracking, not even across the meridian.

This needs changes to drivers but could help.

Chris

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?