APCC & NINA Platesolver "sync" question


Xentex
 

I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.

My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

It was late and cold at that point, so I shut down, but now I'm perplexed about how APCC and Stellarium can show different values for the mount's RA/DEC (whether using JNOW or J2000).  I'm not surprised the platesolve gives a different RA/DEC because the star in question isn't actually centered.  But I'm not sure what the process is to rectify it.


Ray Gralak
 

With the Mach2, there's both a "Sync" and a "ReCal" button in APCC,
When using a planetarium program you won't usually need to use SYNC or RCAL. To use them, you would have to manually enter coordinates into APCC then issue the RCAL.

So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?
Yes.

Second question, how am I supposed to actually use the ReCal thing in APCC? For example, last night I wanted to
center a particular star as part of an alignment routine. I used Stellarium to command the mount to the star. It
wasn't quite centered, so I platesolved with the "reslew" and "sync" options on. To my surprise, it wouldn't center.
The most accurate way to sync/recal the mount is to use APPM. On APPM's setup page, there are buttons for syncing into the model.

And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver
all showed different RA/Dec for where the center of the frame was. There was about an arcmin difference between
them.
It depends on the accuracy of the J2000 to local apparent calculation. For instance, Stellarium might not account for refraction, but APCC does when you have a pointing model enabled. If you have no pointing model and the difference is more than 1 arc-second (rounding error), then the reason for the discrepancy is something you would have to ask of the Stellarium developers.

Plate solves are not always very accurate. Using the same image you will usually get different coordinates between each plate solver, and even in the same solver when using different catalog files. The most accurate results are usually from the solvers that use, or derive from, the Gaia databases.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Xentex
Sent: Tuesday, December 29, 2020 1:14 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC & NINA Platesolver "sync" question

I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.

My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.
You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click
sync. I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync"
options turned on. I never knew exactly what was happening, but didn't really care. It just worked.

With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to
"Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it. I can't
see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or
a "recal". And then I started wondering what exactly is happening.

So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Second question, how am I supposed to actually use the ReCal thing in APCC? For example, last night I wanted to
center a particular star as part of an alignment routine. I used Stellarium to command the mount to the star. It
wasn't quite centered, so I platesolved with the "reslew" and "sync" options on. To my surprise, it wouldn't center.
And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver
all showed different RA/Dec for where the center of the frame was. There was about an arcmin difference between
them.

It was late and cold at that point, so I shut down, but now I'm perplexed about how APCC and Stellarium can show
different values for the mount's RA/DEC (whether using JNOW or J2000). I'm not surprised the platesolve gives a
different RA/DEC because the star in question isn't actually centered. But I'm not sure what the process is to rectify
it.


Dale Ghent
 

On Dec 29, 2020, at 16:14, Xentex <michael@widner.me> wrote:

I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.

My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up. You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync. I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on. I never knew exactly what was happening, but didn't really care. It just worked.
"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving. Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it. I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal". And then I started wondering what exactly is happening.
The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?
Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

Second question, how am I supposed to actually use the ReCal thing in APCC? For example, last night I wanted to center a particular star as part of an alignment routine. I used Stellarium to command the mount to the star. It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on. To my surprise, it wouldn't center. And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was. There was about an arcmin difference between them.
You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale


Roland Christen
 

Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics


Xentex
 

Roland/Ray -
What you described is perfectly clear to me with the small exception of the distinction between Sync and ReCal for those of us that do everything through APCC or third party programs working through ASCOM.

Using your example, let's say I've gotten Accrumulous centered in the camera crosshairs.  I go over to that APCC GoTo/ReCal tab and there's just old data in the RA & DEC fields.  I assume what I should do is type 10 00 00 in my RA and 45 00 00 in my DEC fields, and then push either the Sync or ReCal button.  Is it correct to believe they are going to do the same thing, with the exception that Sync will pop up a warning box telling me to look at my scope and make sure the counterweight bar is pointing down?

Now that it's dark outside I've played around a little more and I still can't figure out why Stellarium and APCC disagree on where the mount is pointed.  I installed Cartes du Ciel and found that it does NOT have the same issue.  APCC and Cartes du Ciel are in complete agreement on RA & DEC, and if I nudge the scope around a bit and do a sync through Cartes du Ciel it does exactly what I'd expect.  So for now I've concluded that there's something buggy in Stellarium (or at least with how I have it configured).

Dale:
I'm going to have to do a little more examining of what's going on in NINA.  It's not the tolerance thing.

I think there's something slightly off in the translations between J2000, JNOW, and Apparent RA/DEC.  I'm brand new to APCC, but at the moment my guess is that the APCC is showing Apparent RA/DEC, which is a little different than JNOW, which is different than J2000.  I currently have Alpha Aurigae centered in the crosshairs and NINA through ASTAP correctly solves and displays the coordinates in J2000.  So that part is great.  The platesolve is accurate.

The peculiarity is that NINA believes the coordinate in question is not centered.  It reports that I'm off by 41 pixels RA, 8 pixels DEC.  So if I tell it to reslew and sync it ends up moving the star 41 pixels and 8 pixels off center and syncing the mount there.  And then no matter how tight I make the tolerance (0.1 arcmin for example) it just keeps it off center like that.

This is my second night playing with it, and I haven't built a sky model, and it's not like 41 pixels is going to kill my imaging.  It's just a little curiosity I'm trying to figure out.


davidcfinch9
 

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011@...> wrote:

Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics


Roland Christen
 


When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
Yes, this is exactly correct.

Roland


-----Original Message-----
From: davidcfinch9 via groups.io <DF121819@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 7:15 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
David C. Finch


Sent from the all new Aol app for iOS

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011@...> wrote:
Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Jeff B
 

Roland, I really like your explanations of the differences between Syns and Recal.

Just one tiny question for clarification:  "Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star."  Does "manual move" mean by hand, not using the paddle buttons or could (should?) it include the paddle buttons?  No before hand slewing ?

Ok, that was two questions. 😁

Jeff

On Wed, Dec 30, 2020 at 10:58 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
Yes, this is exactly correct.

Roland


-----Original Message-----
From: davidcfinch9 via groups.io <DF121819=aol.com@groups.io>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 7:15 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
David C. Finch


Sent from the all new Aol app for iOS

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


davidcfinch9
 

Thank you.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Roland Christen via groups.io
Sent: Wednesday, December 30, 2020 10:58 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

 

 

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?

Yes, this is exactly correct.

 

Roland

 

 

-----Original Message-----
From: davidcfinch9 via groups.io <DF121819@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 7:15 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?

David C. Finch


Sent from the all new Aol app for iOS

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011@...> wrote:

Sync and Recal were two commands that we used from the beginning on our very first controllers.

 

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

 

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

 

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

 

I don't know how else to explain it better. Maybe it's still mush?

 

Rolando

 

 

 

-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale






--
Roland Christen
Astro-Physics


--
Roland Christen
Astro-Physics


Roland Christen
 


Does "manual move" mean by hand, not using the paddle buttons or could (should?) it include the paddle buttons?  No before hand slewing ?
Manual move can be with clutches loose or using the buttons at 1200x with clutches tight. Those are both manual moves versus a GoTo co-ordinate move.

Roland


-----Original Message-----
From: Jeff B <mnebula946@...>
To: main@ap-gto.groups.io
Sent: Wed, Dec 30, 2020 10:12 am
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

Roland, I really like your explanations of the differences between Syns and Recal.

Just one tiny question for clarification:  "Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star."  Does "manual move" mean by hand, not using the paddle buttons or could (should?) it include the paddle buttons?  No before hand slewing ?

Ok, that was two questions. 😁

Jeff

On Wed, Dec 30, 2020 at 10:58 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
Yes, this is exactly correct.

Roland


-----Original Message-----
From: davidcfinch9 via groups.io <DF121819=aol.com@groups.io>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 7:15 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
David C. Finch


Sent from the all new Aol app for iOS

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Jeff B
 

Got it and thanks!

Jeff

On Wed, Dec 30, 2020 at 12:13 PM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:

Does "manual move" mean by hand, not using the paddle buttons or could (should?) it include the paddle buttons?  No before hand slewing ?
Manual move can be with clutches loose or using the buttons at 1200x with clutches tight. Those are both manual moves versus a GoTo co-ordinate move.

Roland


-----Original Message-----
From: Jeff B <mnebula946@...>
To: main@ap-gto.groups.io
Sent: Wed, Dec 30, 2020 10:12 am
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

Roland, I really like your explanations of the differences between Syns and Recal.

Just one tiny question for clarification:  "Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star."  Does "manual move" mean by hand, not using the paddle buttons or could (should?) it include the paddle buttons?  No before hand slewing ?

Ok, that was two questions. 😁

Jeff

On Wed, Dec 30, 2020 at 10:58 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
Yes, this is exactly correct.

Roland


-----Original Message-----
From: davidcfinch9 via groups.io <DF121819=aol.com@groups.io>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 7:15 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

When I use SkyX, I do a “Closed Loop Slew” to a star, which will slew to the star, take a picture, plate solve and center the star. I then “Synch” on the star in SkyX. Is this the same as your fourth paragraph?
David C. Finch


Sent from the all new Aol app for iOS

On Tuesday, December 29, 2020, 5:41 PM, Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
Sync and Recal were two commands that we used from the beginning on our very first controllers.

Recal:  When you send the scope to a star, the planetarium software sends the co-ordinates to the mount where it is stored in memory. The mount moves there via the GoTo command. For example, you send (GoTo slew) the mount to a star named Accrumulous, which is at exactly 10hrs00min00sec and Dec of 45deg00min00sec. That number is now in memory in the CP controller. However, you wish to center this star in your CCDchip/eyepiece, so you move it around until it lands on the crosshairs. The new number is where the scope thinks it is pointed, but you wish for that to be the original number. So by issuing a Recal, that new number is replaced by the stored number of 10hrs00min00sec and Dec of 45deg00min00sec.

Sync: you send the mount via manual move to a spot in the sky that you are absolutely certain is the star
Accrumulous. The mount's internal co-ordinates could be anything, but you wish to replace them with
10hrs00min00sec and Dec of 45deg00min00sec. Remember, that co-ordinate is NOT in the mount's memory because you never issued a co-ordinate GoTo command to go there. So, in order to sync on that co-ordinate, your external planetarium program will send the numbers 10hrs00min00sec and Dec of 45deg00min00sec along with a Sync command. The mount controller will dutifully replace the internal co-ordinate with the new one which you sent in your sync command. A co-ordinate and sync command does NOT cause the mount to move, it is not a move command. It is only a re-alignment command.

When i use SkyX with the ASCOM driver, I will click and slew to an object in SkyX, then image and center the object via my keypad or ASCOM driver or APCC buttons. I then do a sync on the object in SkyX. Works flawlessly every time. SkyX knows the object co-ordinate, asks you if that's the one you want to sync on and then does the sync when you say YES. Bingo, done.

I don't know how else to explain it better. Maybe it's still mush?

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 3:54 pm
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question



> On Dec 29, 2020, at 16:14, Xentex <michael@...> wrote:
>
> I just started using APCC and a Mach2, and my usual imaging program is NINA with ASTAP doing platesolving.
>
> My other mount is a Celestron CGEM and there is a pretty simple process to sync it to the sky when started up.  You pick a star in the mount driver's pseudo-planetarium software (CWPI), go to, center it in eyepiece, then click sync.  I generally did the centering with platesolving, and in NINA always had the "reslew to target" and "Sync" options turned on.  I never knew exactly what was happening, but didn't really care.  It just worked.

"Reslew to target" makes NINA issue another slew to the desired coordinates after a plate solve is done and the mount is updated (synced) with the results of the solve. This process repeats until the results of the successive plate solves indicate that your mount is pointing within the Pointing Tolerance of the the desired coordinates. The Pointing Tolerance is a setting found under Options > Plate Solving.  Given the wide variety and qualit^H^H^H^Hcapabilities of mounts out there, this tolerance can be large or small.

> With the Mach2, there's both a "Sync" and a "ReCal" button in APCC, and the manual explains you only want to "Sync" once per session, and you want to be pretty careful about where you're pointing when you're doing it.  I can't see my mount from where I control it, so that got me wondering whether the NINA "Sync" option is doing a "sync" or a "recal".  And then I started wondering what exactly is happening.

The NINA sync option does a classic sync through the ASCOM driver. There is no provision in the ASCOM telescope driver standard for issuing it in the form a ReCal, which is a command and semantic that is unique to A-P mounts. If set, the A-P ASCOM driver (or APPC) will transparently convert Syncs to ReCals as they are received from applications such as NINA and normally this option should be On.

> So first question, is it useful and safe to have the "Sync" option turned on in NINA's platesolve section?

Is it useful? In general, yes. In the context of the Mach2, it might be superfluous, but not deleterious, after the first time the mount is synced since the Mach2's encoders allow it to know and regulate where it is pointing in the sky without the aid of a plate solve, given a proper polar alignment.

Is it safe? It's generally safe when it's done with a non-encoder-enabled mount in the proper orientation, with counterweights down. Syncing with the mount in a cw-up orientation can end up being dangerous when the mount is told to slew to something later, and the mount dutifully does so, but drives the telescope under the mount and into the pier/tripod legs. There might be safeguards against this that I'm not aware of in the CP or APCC/ASCOM driver, though.

This brings up a good question, though - what if you're running a pointing model and the driver gets a sync? Will the sync perturb the pointing model? This, I don't know because there have been scant clear nights since I personally started using APPM back in mid-November, so maybe Ray can chime in on this. I know that Bisque's ASCOM driver for TheSkyX and T-Point contain an option to silently discard syncs issued by applications when a pointing model is active as, in their system, a sync can throw off the active pointing model.

> Second question, how am I supposed to actually use the ReCal thing in APCC?  For example, last night I wanted to center a particular star as part of an alignment routine.  I used Stellarium to command the mount to the star.  It wasn't quite centered, so I platesolved with the "reslew" and "sync" options on.  To my surprise, it wouldn't center.  And to my even greater surprise, when I tried to figure out why I noticed that APCC, Stellarium, and the plate solver all showed different RA/Dec for where the center of the frame was.  There was about an arcmin difference between them.

You were probably within the aforementioned Pointing Tolerance and NINA determined that there was no need to reslew. Coincidentally, the default value for NINA's Pointing Tolerance setting is 1 arcmin. Reduce this tolerance to force the centering process to be tighter. Not many mounts are capable of such accurate pointing, hence NINA's generally conservative default of 1 arcmin.

/dale







--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


deonb
 

Is it just 1200x that's considered manual?


Roland Christen
 

No, of course not. Any button speed is always considered a manual move since you are not sending a co-ordinate command to the mount.

Roland

-----Original Message-----
From: deonb <deonb@...>
To: main@ap-gto.groups.io
Sent: Wed, Dec 30, 2020 11:24 am
Subject: Re: [ap-gto] APCC & NINA Platesolver "sync" question

Is it just 1200x that's considered manual?

--
Roland Christen
Astro-Physics