Flippin' meridians & APCC


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.





There was a simple solution that I had proposed, but I haven’t heard any final decisions on whether it would be done.



you mean the helper app? or was there something else?


The “helper app” is simple and is not the roadblock. What needs to be implemented in SGPro is a way for the helper app, maybe through a ReST API call, to change SGPro’s meridian limit value. I haven’t heard if Ken and Jared have decided to add that implementation.

-Ray Gralak


OK - yes understood, i just didn’t know if you were referring to something else.

one problem seems to be though that SGP does not support the concept of stopping the mount before the meridian has been reached, and waiting until it’s safe to flip. even if SGP knows the limits from APCC i think the meridan flip logic needs to be expanded.


@rgralak by “Meridian Limit Value” are you referring to the “Degrees to Flip” setting? This may work, but the “Degrees to Flip” can be somewhat fuzzy unless the “Wait” option is used.



Yes, I think so. Can the user change that field while running a session?



Yes they can. But not via the API at the moment. We’ll talk this over and see what might be the best route to take. I don’t see setting the “Degrees to Flip” as being that useful in the API (other than this case) but maybe allowing outside sources to trigger a meridian flip with some parameters would be more useful (force, wait for frame, etc) and also solve this problem as well.



Just to be clear, the option i think I meant is “Minutes past meridian to flip”. Is that the same as “degrees to flip”?

The “helper app” just monitors the mount’s meridian limit (aka flip point) in APCC. If it changes, the helper app would update the “Minutes past meridian to flip” value.in SGPro.