Maybe some chime-in with flip-experience on the CEM60 with PHD2: Just went through one, and it didn't work. EKOS didn't inform PHD2 to flip the calibration. So while everything else had worked beautifully (re-point, align the target, in PHD2 select star and guide) the guiding was driving the star off. I had to stop, manually flip the calibration, and restart....

Exactly my experience with the iOptron SmartEQPro+, which is also using the CEM60 driver, and the internal guider, not PhD2.

I was prepared to accept that I was the only one who was seeing ghosts. I am glad to see that there is another Vampire Slayer joining the team now!



PS: I bet that if you had set "Always recalibrate" the flip would have worked just fine, but if you had another target programmed in the scheduler, that second target would have failed on initial guiding.
If you have a chance, try that and let us know what you find.

I cannot see right now how there would be a difference between the internal guider and PhD2 when it comes to resetting DEC swap.

Best

Jo

Well, from my experience with the previous mount (GP-DX, eqmod driver) I know flip works perfectly when the mount/driver reports pier side.

So I wonder if one solution could be to check (in EKOS) if the mount does support pier side info, and if not send a separate flip command to PHD2 before telling it to guide.

I'm afraid though that this wouldn't help at all for a second target which is in the other hemisphere. There a lot more logic would have to be involved to decide if a flip is needed or not.

For a final solution I think EKOS would have to keep track where it is, starting from the very first slew. And if one crosses(*) the meridian, set it accordingly. As long as EKOS is the only one commanding movements (no HC, and no auto-flip from the mount) that could replace the pier side info for those that don't have it. But that sounds like a quite invasive, with changes in many places...

(*) rather, the target coordinates are in the respective hemisphere. For meridian flip, the slew happens after you are already on the other side, so technically you don't cross. Still, if the internal pier side tracker says you had been on the other side it would toggle the variable...

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.