in another thread regarding merdian limits, Ray Gralak asked about letting APCC inform SGP of where the current meridian limits are. unfortunately it sounds like the meridian delay is not part of the API, so for now that won’t work.
in this thread (here), i see that a similar problem that i’m coming up against now is addressed in this thread, but there’s no real solution.
in my case i have a range of declinations for which the mount needs to stop before the meridian is reached. i understand that inputting a negative meridian delay in SGP is not legal, because it’s not supported by the AP driver. furthermore flipping at a point before the meridian won’t work either, because the camera would hit the pier on the east side.
i’m trying to figure out how to work around this right now. Chris’s ASCOM enhancements for telescope V4 would probably be the real answer. in the meantime, it seems like i’m stuck. Ray was going to add an option to APCC to allow a mount-flipping slew even if tracking had been stopped by the meridian limits… but i’m not sure this works - if SGP relies on the mount tracking past the meridian to know when to attempt a slew that causes a flip, then it won’t since the mount will have stopped tracking before the meridian.
does it make sense to decouple the concepts of “can’t track past here” and “meridian flip is safe when X minutes past the meridian”? i think this might let the user configure SGP in a way that is compatible with east and west meridian safety limits, as long as SGP is OK with the mount stopping itself before the meridian is reached (or maybe SGP itself could stop tracking at the “can’t track past here” limit.) this would be reasonably mount-agnostic and might even allow one to eliminate the current delay when the mount is past the real meridian but has not reached the delayed meridian set in SGP (the situation where the UI allows you to ‘attempt flip now’ but otherwise would wait if left unattended.