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

Hi
I believe the manual says try to unpark and park with AP Ascom or APCC.  Last night I started the mount and connected with NINA.  This was my first tracking session with this mount, so this a newbie making sure My process is correct. At the end of tracking M31, I used NINA to park to #3 the mount. Dec returned to correctly, RA was 10 to 15 degrees off, weights East.  So I then tried the AP Ascom to park.  The mount corrected and moved to park position #3.
So here’s the info to fill out the picture:
Software: 
NINA 1.11 - very recent version: I only used the simple sequence aspect of setting up a single target.
APCC - not installed yet 
AP ASCOM V2 - installed 
Keypad is attached and is configured for Ext.
You’ll Laugh:
Telescope: EVO50
Camera: ZWO ASI183MC 
Guiding 
ZWO MINI GUIDER w/ ASI290MM
PLATESOLVE: ASTAP
Process:
- Start mount 
- Start Nina 
- connect eqpt 
- set Nina to slew, and auto correct (platesolve)
- run a set of four settings, about 3 hours worth
- manually I used NINA to Park, in NINA park is set to position 3. 
*** this is where it didn’t fully move to park #3
This where I used the AP ASCOM V2 interface to park, which it did correctly.

So I was surprised that NINA didn’t park it correctly.  A side note, I did notice that when slewing to M31 it was several degrees out.

Any thoughts?

Cheers 

On Oct 7, 2021, at 16:50, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> 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.

On Oct 7, 2021, at 15:08, Dale Ghent <daleg@elemental.org> wrote:


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 1:51 PM, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> 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.

On Oct 7, 2021, at 15:30, W Hilmo <y.groups@hilmo.net> wrote:

Are you at Rusty’s by chance?

If so, say hi to Dennis and Dianne for me.

Regarding the time zone issue, if your computer is 100% dedicated to the observatory, you might consider setting it up on UTC, with no DST changes.

On Oct 7, 2021, at 1:51 PM, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> 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.

Hey Wade
I’m not in Rusty’s. But I see him a couple times a week. So I will. Are you back near Ellensburg, do I have that right? I know I was supposed to come by sometime this summer, but the summer went by too fast.

I’ll look into that. I didn’t know that was an option.

On Oct 7, 2021, at 15:30, W Hilmo <y.groups@hilmo.net> wrote:

Are you at Rusty’s by chance?

If so, say hi to Dennis and Dianne for me.

Regarding the time zone issue, if your computer is 100% dedicated to the observatory, you might consider setting it up on UTC, with no DST changes.

On Oct 7, 2021, at 1:51 PM, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> 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.

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.

-----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=icloud.com@groups.io> 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.

On Oct 8, 2021, at 10:23, Howard Hedlund <howard@astro-physics.com> wrote:

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=icloud.com@groups.io> 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.