I guess my real question is ---- Can I just power cycle the mount and the computer when I think that the mount is lost for any reason (but has not been moved) and go from there? I think that this works if I am resuming from "last parked" which is what I am doing anyway.

Rgrds-Ross

On Aug 1, 2019, at 11:56 AM, Ross Salinger rgsalinger@... [ap-gto] <ap-gto@...> wrote:

I guess my real question is ---- Can I just power cycle the mount and the computer when I think that the mount is lost for any reason (but has not been moved) and go from there? I think that this works if I am resuming from "last parked" which is what I am doing anyway.

There seems to be the belief that power cycling *the mount* will accomplish something here - it won't. Doing that is pointless. The mount's notion of where it is pointing in the sky after a power cycle will be exactly the same as what it was right before power-off. Giving your computer the 3-finger salute is not likely going to fix anything either, other than perhaps add more annoyance to your evening when Windows decides to take that opportunity to pause for 30 minutes on the startup screen while it installs deferred updates.

A lost mount is when there's a difference (of varying amounts) between where the mount thinks it is point and where it actually is pointing. Plate solving is the best recovery for this, and this is indeed what you outlined in your original email. The key thing here is to know that plate solvers perform differently from each other in terms of the speed and the reliability in which they arrive at a solution under different circumstances.

A regular plate solve is hinted. When APPM, MaximDL, or another app that uses plate solving starts that process, it uses the combination of the image and the mount's notion of where it is pointing to give a hint to the plate solving software. It's basically saying "Here's an image to match, and you can start by looking around this area." The plate solving then searches for a solution that matches that image within so many degrees (how much it looks around that area varies from solver to solver) of that hint. If your mount isn't far off, the plate solver will eek out a match, return those coordinates to your application, the the application will then sync/RCAL the mount to those coordinates, if configured to do so. That will update the mount's notion of where it is pointing.

"All-sky" or "blind" solving is the same process, but without that important and time-saving hint. It's the fall-back method if the first method fails because your telescope is pointing sufficiently far from where the mount thinks it is. This is naturally going to take longer because the plate solving software must search all 180 degrees of the current sky for a match, assuming that your computer's clock is somewhat accurate. This takes time, and depending on the particular plate solving software in question and the hardware you're doing it on, it can take a LOT of time.

The speed at which solvers arrive at their solution varies. Some are fast, some are quick. Some solvers are further hindered by longer focal lengths, or even fooled by hot pixels. There are also the environmental considerations that Chris mentioned. The best thing to do for the solver that's in use is to make sure you're feeding it exposures that are optimized for what the plate solving software wants - that the exposures are long enough to include enough stars, that focus accuracy is there, and to use your L filter and not RGB or narrowbands when exposing an image to feed to the solver. Stuff like that. If you're using software that is slow at blind solves, then you also need patience.

/dale