Interesting Park using NINA


michael mccann
 

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


Roland Christen
 

When you're off by 15 degrees in RA it always means that your local time is off by 1 hour in that particular application. Could be time is wrong, could also be daylight savings is set wrong.

For every hour, RA changes by 15 degrees.

Rolando

-----Original Message-----
From: michael mccann via groups.io <mmccawsprojects@...>
To: main@ap-gto.groups.io
Sent: Thu, Oct 7, 2021 12:59 pm
Subject: [ap-gto] Interesting Park using NINA

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






--
Roland Christen
Astro-Physics


Dale Ghent
 


NINA just tells the ASCOM driver, essentially, "Park the mount". It's up to the driver and mount controller to get the mount into the park position that is configured in the ASCOM driver. NINA and other upper-level apps aren't aware of what the physical orientation of the park position actually is; they only know whether the mount is parked or not.

As for why your mount didn't land in the Park 3 position, looking at the AP ASCOM driver logs might help determine why. Perhaps you hit the stop button by accident. There could be a time issue at play, so make sure your PC's clock is accurate and that the "Sync mount time at initialization" and "Keep mount time synced to PC time" options are checked in the AP ASCOM driver's setup options. You can access this through the "Setip Telescope" utility or by pressing the gears icon next to the driver selection drop-down box in NINA. I'm not sure, but you may need to reinitialize your mount to get the time to sync. Of course you ought to ensure that your PC's own clock is fairly accurate and is itself synced to a time source, if possible. See the attached screenshot.



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 







michael mccann
 

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.


Dale Ghent
 

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.





michael mccann
 

Come to think of it, and I forgotten until you mentioned it, NINA asks whether to sync ‘NINA to mount’ or ‘mount to NINA’ . And I know I chose ‘NINA to mount’. I guess it should be the other way around. If it’s not to cloudy tonight I’ll change that.

Cheers

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.


W Hilmo
 

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.





michael mccann
 

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.











W Hilmo
 

Yes, I am north of Ellensburg, right at the foothills of Table Mountain.

On 10/7/21 2:44 PM, michael mccann via groups.io wrote:
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.











Ray Gralak
 

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.







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=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.







michael mccann
 

Hi
Yes actually I was trying to figure out what I was doing wrong to confuse the different applications. Wasn’t pointing the finger at software. I was wondering if I was activating software in right order. Last night was cloudy so I’ll try tonight.
Howard brought up taking flats, which on this maiden session I didn’t. So ‘safety park timer’ phrase was used. Which manual is that described in?

Cheers

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.