Re: NINA and utilizing APCC meridian limits


Dale Ghent
 

Right, in NINA and other apps, the parameters for a vanilla meridian flip are straight forward: You specify a desired flip delay once for when you reach the meridian, and an optional pause-before value (also in minutes) in case you have to suspend things as the mount approaches the meridian because the west side of your mount has clearance issues at the declination you're imaging at. This is common for tripods where the camera can crash into a leg. The real solution here is to convert to a pier or tri-pier type of setup that either removes the legs as obstructions or lifts your gear sufficiently above them (*shameless plug for the A-P Eagle tripod with extension*)

IF you've mapped out these collision areas using APCC's meridian limit config tool, then SMF will observe these limits and flip (or stop) the scope 10 seconds prior to encountering them. This is why I mentioned the plugin having two time statuses: one for any pre-meridian pause, the other for the actual flip time. Optimally they would be the same, meaning you don't have to stop work to avoid a collision while you wait for the target to sail through the meridian and get low enough so that you can then safely flip and resume.

Without SMF, you have to set up the vanilla meridian flip parameters for your worst-case scenario, even thought your target of the moment might be at a low or high enough declination that avoids any obstruction. In this case, the vanilla flip would be premature and interrupt imaging the target when it's at the best place in the sky to image it.

On Jun 11, 2021, at 11:48, ap@captivephotons.com <ap@CaptivePhotons.com> wrote:

As for slews, this has no effect on slews, so starting in a cw-up position is something this plugin doesn't care about or influence. Its only concern at the moment is dictating when the flip happens.
One of the things I have yet to find out (as I don't have the mount yet) is whether I will have the opposite problem -- a need to limit tracking before meridian to avoid collisions at certain DEC angles. Which I think I can code for, right? Different limits based on DEC?

Let's hypothesize that at certain angles I need to stop 15 minutes before transit and resume 15 minutes afterwards to avoid the collision area.

Will this new smart flip accommodate the opposite case -- where you enter limits at certain angles which will not quite allow counterweight level, much less up.

I can do that in NINA now, I think, but it's uniform -- all DEC angles. So I'd have my (example only) 30 minute gap for all flips.

I'm likely to need it (if I need it at all) just in a small area, which is attractive -- I could put in limits once, and it would image to transit and flip in all other areas, but in that area it will stop early and continue later to honor the limits?

Linwood





Join main@ap-gto.groups.io to automatically receive all group messages.