1. Messages
  2. Interesting Park using NINA

Re: Interesting Park using NINA

Howard Hedlund
 

Ray and Dale,

I honestly think we are starting down a rabbit hole here. It is my belief that Mr. McCann's safety park timer parked the mount while pointed at the zenith awaiting flats. After that, the issue was further compounded because the nature of that safety park was not understood.
There is no problem with how NINA is parking the mount.
There is no problem with how APCC is parking the mount.
There is no problem with how the driver is parking the mount.
While this discussion has been interesting, I honestly believe that the issue itself is little more than a misunderstanding of how things worked with the safety park timer.

Mag. 7 or Better Skies!

Howard Hedlund
Astro-Physics, Inc.
AP Phone: 815-282-1513
Direct Phone: 815-315-7015
www.astro-physics.com
Please include this e-mail with your response.

 Consider the environment before printing this e-mail.

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Friday, October 8, 2021 8:41
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Park using NINA

Hi Dale,

I honestly can't explain why there's a difference between an external
app such as NINA telling the driver to park, and the driver's own park button giving different results.
The only difference is that you can select a different park position from the driver's UI than the default. The actual park operations are handled identically.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of Dale Ghent
Sent: Thursday, October 7, 2021 2:09 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Park using NINA


I honestly can't explain why there's a difference between an external
app such as NINA telling the driver to park, and the driver's own park
button giving different results. I would think that both interfaces run the same logic underneath. Perhaps Ray can shed some light on this mechanism.

But given a correct PC and mount time and a reasonable lat/long,
parking should always be successful and fine assuming your mount is
properly aligned, something that can be done with a single plate
solve. Time zones aren't going to have a bearing on the mount's internal clock. Like your PC, the system clock actually runs in UTC time, with whatever timezone you have configured applied to it for purposes of display.

What I bet *might* be happening in your case is that you have the
keypad connected to your mount and it's not set for an EXT auto
connect. So when your mount is powering on, the time that's configured
in the keypad is immediately getting applied to the CP when the keypad
initializes it. This could possibly explain some mount/PC time
mismatch or wonkiness. With the Sync Time options I pointed out before, you can set the keypad to EXT in its autoconnect setting which will allow the ASCOM driver to initialize the mount when it connects.

On Oct 7, 2021, at 16:50, michael mccann via groups.io <mmccawsprojects@...> wrote:

You know that might be. I’m living in New Mexico, but so close to
Arizona my computer always tell me my
time is an hour earlier. I’m out in the countryside where I get my
time from cell/data and not a regular network. I thought I had
corrected this problem on my computer because I set the display time
for mountain time zone, but when you look at all the settings it shows that it thinks it’s in Pacific time zone. I tried several times to change it. Software comes back says that I don’t have permission to, and yet I’m the administrator.

So finalizing the park is best from AP ASCOM.
Join main@ap-gto.groups.io to automatically receive all group messages.