I'd second the question what happens for people using PHD2. Does that setting have any influence? Does EKOS send any info to PHD2 regarding a flip of coordinates?

Also, what about people with a mount that doesn't report pier side? How do you detect a flip there?

AFAIK Ekos doesn't need to send any mount information to PHD2 because it will read it from the camera and mount specified in PHD. That covers the pier side, declination, guide focal length, guide camera and pixel size. It should have all it needs to be able to do a good calibration and allow for changes in pier side and declination so it shouldn't need to keep doing calibrations. The Ekos guide controller can force addional calibrations but they may not be needed.

I'm not sure how PHD handles a pier side change on a mount driver that doesn't report the pier side. The way I'd resolve that is get a driver that does report the pier side, even if I had to write it myself. Reading the PHD help could give an answer, there are a number of ways that they could implement this. At worst redoing the calibration after every slew.

Dither is handled by the guide application offseting the guide star position and using the normal guide commands to drive the guide star to the new position. My guide system has a pixel size of 1.68 arc seconds so a 2 pixel dither will need a little under 0.5 seconds of guiding at 50% rate. For PHD Ekos will send a dither command at a time of it's choosing and will then wait until it's guide accuracy criteria have been reached.

Yes, meridian flip worked nicely with my (eqmod-driven) GP-DX. The CEM60 driver doesn't work in that respect, because there's no pir side info. Not because the driver doesn't relay that info, but because you cannot get it from the mount. It just doesn't report that info Therefore I asked if there's any communication implemented to actually signal PHD2 to flip the calibration. But I think the is none.

Hi
I think it important that whatever change which is made to the EKOS guider, leaves the PHD2 behaviour exactly as it is.
Thanks.

To reply to Alacant’s request: I think it is essential that the guiding behaviour is the same in all situations irrespective of which guiding software is used. On top of that there should be a configuration such that the current behaviour with PHD2 can be achieved. And again, that behaviour then should be the same for any other guide software as well.

If this means that current users need to modify their configuration to maintain the current behaviour then that should be documented and announced to all users.


Wouter

The mount may not send that signal, but wouldn't Ekos detect that it is sending commands to the mount to move across the meridian and that recalibration or calibration swap is required?

At least during the imaging of the first scheduled target that works, but when the second target it initiated, calibration does not seem to get swapped back. Ekos definitely has that information, since it accurately calculates the time until the next meridian flip.

Yes, that it does know. But it has no way of checking if that switch had actually taken place. Only the mount knows which side it is on, not based on coordinates, but based on the steps/position of the motors.

Usually you can give a good guess which side you're on (like, when the position is more than 10-15 degrees away from the meridian). But inbetween always both pointings would be possible, and where you are depends on the history.

You need to read the declination axis position. If the declination axis position is in the range -90 to 0 t0 +90 you are on the 'normal' side of the pier. If the declination axis position is in the range -90/270 to 180 to 90 then you are on the 'alternate' side of the pier.

Maybe the mount has functions to read the axis positions, if that's the case then the driver can deterine the pier side.

All this only applies to GEMs a fork mount usually stays in the same pointing state everywhere.

@ Wouter: no, it does not affect dithering. I checked it both with the internal guider and PHD. After each slew the calibration is cleared. But when the guider dithers, it is not recognised as slewing. Hence for dithering the calibration is kept.

@alakant: this change applies to all guiders. If the option "Always Reset Guide Calibration" is selected, both internal and external guiders receive a "clear calibration" command for each slew detected. If the option is NOT set, all decisions about calibration are left to the selected guider.

Regarding mounts that do not report the pier side, I cannot answer it, since my mounts and the simulator support it. Needs to be tested, but worst case simply set the option.

HTH
-- Wolfgang

*Unpopular opinion alert. But I do not think recalibrating after ever slew is particularly elegant. There are occasions when calibrating in a different region of the sky is necessary. For instance calibrating near the celestial pole is not recommended, and may fail. It would generally add time to perform especially if repeated, such as occasionally going to a star to manually re-focus.
Narrowing the trigger criteria may help, such as if slews in Dec are substantial, as RA only impacts calibration when pier-side changes. But IMHO implementing declination compensation with recalibrations only after pier-side change and guiding failure is ideal.

Food for thought. Thank you
- Andrew.

@Wolfgang Thanks for the confirmation!

Hi Andrew:

The original reason for the recalibration after slewing is that some mounts, such as the iOptron mounts, do not recognize when they are slewing across the meridian. Which means that when using the scheduler, the second sequence is ruined as the previous calibration swap is not reversed. The only way to fix that is to recalibrate.

Not elegant, perhaps. But the problem in that case is with iOptron and other mount manufacturers that cannot get their firmware act together, not with Ekos. If there is another more elegant workaround to solve the problem, please let us know.

Jo