I just had my scope driven to 20 degrees below the horizon.
Request an option to either not allow the scope altitude to be driven below 0 degrees or possibly some user-selectable lower limit. This could be determined just prior to a slew, given the RA and Dec of the object from the target list, so the scope would not move at all.
I was unable to find another request for this feature among the large number of feature requests. It is potentially very important for my remote observatory so I don’t inadvertently run the OTA into the floor. Others might find this of use also.
We have been resisting adding this into SGPro because we have a different idea for mount safety. The problem with this method is that it only provides partial protection. The ASCOM driver for the telescope is owned by the SGPro process (app). If it dies, the ASCOM driver dies with it. If the mount stores safety limits on board, you are probably still ok, if not, you have lost your limits. I would like to introduce a mount “watchdog” that can be started with a sequence, but is not part of SGPro… if SGPro eats it, the watchdog will still be up and going… It would recognize a loss of connection with SGPro and perform emergency end of sequence actions. It would also continually poll mount position and issue stop commands when it tries to go beyond the limits. This is not fully fleshed out, but that is the general idea.
How would the watchdog initiate end-of-sequence actions if SGP has died?
External actions, I suppose. Would that then be a separate set of
actions from SGP in the watchdog? It would need to be connected to the
mount and the observatory in order to park the mount and close the
observatory. That should work. I wonder if somebody has already come up
with something like this in software. Andy Galasso has a watchdog timer
based on an Arduino that cuts power to the mount if it tries to go out
of limits. That’s not exactly what I want, though, as I would want the
end-of-sequence actions.
I really only wanted the simple case of stopping a slew to below the
horizon when the sequence starts.
It’s possible to make a mistake in RA and Dec or pick a wrong start time
although your Planner alleviates many of those concerns. Manual entry of
RA, Dec and start/end can still be done and it seems like a sanity check
in SGP when the sequence is run would flag a potentially serious
problem. Even users who have drivers and mount firmware that can check
the limits would still get useful information that their sequence is not
quite right.
What happened to me was related to a bug in SGP that caused the scope to
start the sequence after I manually aborted during waiting for start
time. I know that’s been fixed, but still… It would be good to have
that simple check at the outset. Call it more of a sanity check (among
others you might have) of the sequence rather than an altitude safety check.
SGPro and the watchdog can talk so the watchdog can know what things to do when required.
I think that should work. Ideally, the ASCOM drivers use a server based architecture and can support multiple connections… otherwise POTH is an option too.
For sure. Andy has a whole bunch of good ideas. I think this idea may have even been planted by him (maybe not intentionally)
Understood. I think we can add this in phases. The initial phase, just checks against your user-defined horizon. The problem with this (in addition to above) is that it can only protect you if you have added a user profile with lat / lon. So… there is work to do here in order to promote this idea and guide potential users through the process.
Phase one would be something like: Can we determine the altitude of the location requested?
How about both cases then. Check at the start and also in real time when
the slew is done. Just thoughts. No big deal for me however you
implement it or not. Kind of low priority as we all should carefully
check our sequences and if bad, it’s on us.
Regards and thanks for all the good work you and Jerod do,
Kent