Date   

Re: Lost communications with mount

weihaowang
 

Hi Ray, 

Thank you. I will try those. I was wondering if it’s 
related to some timeout setting or the update rate.
But without specific guidance, I do not want to 
try it, as I don’t really understand it. Now I have
good directions.

When I tried Mach2, it’s the only USB device
connected to the computer. But of course, it has
to go through the USB-C adapter.


--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


Re: Lost communications with mount

Ray Gralak
 

Hi Wei-Hao,

 

> Thanks for the comments.  But to be very honest, if getting a Windows laptop is the only solution here, I will be

> very disappointed. ASCOM on a virtual Windows machine has worked for me for more than 8 years on every

> other system.

 

The problem is not with the application software or the mount, but the virtualized hardware performance of your Mac, specifically virtualized USB performance.

 

Of the virtual machine choices out there, Fusion has been known to have the most performant USB virtualization.

 

Is the mount the only USB device, or do you have a camera connected as well?

 

Here are a few things you can try:

1.    Reduce the crosshair update rate to 1000msec or greater in Sky6’s Telescope Setup. By default, it tries to poll the mount as fast as it can.

2.    Start with a 200 msec timeout in APCC and increase the by 100 msecs at a time. Do not exceed 1000 msecs.

3.    Start with a 500 msec timeout in the AP V2 ASCOM driver and increase the timeout by 100 msecs at a time.

4.    Turn off logging in the ASCOM driver.

 

-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 weihaowang

> Sent: Wednesday, December 30, 2020 9:04 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Lost communications with mount

>

> Thanks for the comments.  But to be very honest, if getting a Windows laptop is the only solution here, I will be

> very disappointed. ASCOM on a virtual Windows machine has worked for me for more than 8 years on every

> other system.

>

>

> --

>

>

> Homepage:

>

> http://www.asiaa.sinica.edu.tw/~whwang/

>

> Astrobin gallery:

> http://www.astrobin.com/users/whwang/

>


Re: Lost communications with mount

weihaowang
 

Thank you. I will try Ethernet and Wifi during the new year holidays, and let you know if I have any luck.
--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


Re: Continued: (Field curvature with Flatteners and compressors)

lmbrabec@...
 

Thank you so much Rolando!  Your advise is much appreciated!  All the best, Scott
Oh by the way..... I love my Mach2 mount!


Re: APCC & NINA Platesolver "sync" question

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


Re: Lost communications with mount

 

>>> Wei-Hao. Well, try the Ethernet/WiFi access first before giving up. It's likely to work better than USB.

PS on ethernet - i suggest you use TCP as it's much more reliable for this kind of mount communication than UDP

On Wed, Dec 30, 2020 at 9:23 AM deonb <deonb@...> wrote:
Wei-Hao. Well, try the Ethernet/WiFi access first before giving up. It's likely to work better than USB.

+1 on using NUCs though. Much simpler, and small enough to fit on the eyepiece trays of most tripods.



--
Brian 



Brian Valente


Re: APCC & NINA Platesolver "sync" question

deonb
 

Is it just 1200x that's considered manual?


Re: APCC & NINA Platesolver "sync" question

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


Re: Lost communications with mount

deonb
 

Wei-Hao. Well, try the Ethernet/WiFi access first before giving up. It's likely to work better than USB.

+1 on using NUCs though. Much simpler, and small enough to fit on the eyepiece trays of most tripods.


Re: APCC & NINA Platesolver "sync" question

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


Re: Lost communications with mount

Michael 'Mikey' Mangieri
 

The NUC is a great solution. I have a BeeLink Corei5 NUC attached to my pier and I simply remote into it.  Works great.  Costs under $400.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Brian Valente
Sent: Wednesday, December 30, 2020 11:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Lost communications with mount

 

>>> Getting a cheap laptop with the latest version of Windows isn't very hard, and you can keep it purely for astronomy. It will save a lot of heartache. When you are done imaging, you can transfer the files to your Mac and do what you already do without relegating part of your system to Windows. 

 

Better yet, just get an inexpensive NUC-style computer, and you can remote in using your Mac (or windows or ipad or whatever) to a fully functional windows computer

 

Brian

 

On Wed, Dec 30, 2020 at 8:35 AM Liam Plybon <liam@...> wrote:

Even using Ethernet and Wifi are not perfect solutions when using VMs like Parallels. Earlier this year, I spent quite a while with a customer that was trying to use Ethernet on Parallels, and we found that the system wasn't actually allowing any access to the Ethernet port for Windows. It was quite bizarre. Similar things can happen with all of the ports.

 

Really, using a VM to get windows on a non-windows computer will eventually be a pain no matter how good of an IT person you are. Getting a cheap laptop with the latest version of Windows isn't very hard, and you can keep it purely for astronomy. It will save a lot of heartache. When you are done imaging, you can transfer the files to your Mac and do what you already do without relegating part of your system to Windows. 

 

Liam

Astro-Physics

 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of weihaowang <whwang@...>
Sent: Wednesday, December 30, 2020 9:55 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Lost communications with mount

 

Hi George,

I don't have any Windows PC.  The only reasons I run Windows on my Mac are to run Registar
and to control telescopes/cameras.  I tried to get rid of Windows completely, but there are 
still a few programs that only have Windows options.

And as I said, I started with native Windows in Bootcamp, and then found it's not as stable
as Windows under Paralles.  It was perhaps more than 8 years ago, and perhaps bootcamp
is better now, but I don't have a chance to find out.


--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


 

--

Brian 

 

 

 

Brian Valente


Re: Lost communications with mount

weihaowang
 

Thanks for the comments.  But to be very honest, if getting a Windows laptop is the only solution here, I will be very disappointed. ASCOM on a virtual Windows machine has worked for me for more than 8 years on every other system.  


--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


Re: APCC & NINA Platesolver "sync" question

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


Re: Changing polar alignment...Ground shifting?

Mike Dodd
 

On 12/30/2020 11:16 AM, Tom Blahovici wrote:
I also just remembered that at one point before the poor tracking showed
up, that my rotator came loose. I then tightened it quite snug.
Maybe that was the culprit?
I absolutely would suspect rotator (and other equipment) attachment to the OTA before I would suspect rain or ground movement shifting the pier 4-6 degrees.

For peace of mind, I recommend pressing a level against the pier on two sides to determine if it is plumb or not.
--- Mike


Re: Lost communications with mount

 

>>> Getting a cheap laptop with the latest version of Windows isn't very hard, and you can keep it purely for astronomy. It will save a lot of heartache. When you are done imaging, you can transfer the files to your Mac and do what you already do without relegating part of your system to Windows. 

Better yet, just get an inexpensive NUC-style computer, and you can remote in using your Mac (or windows or ipad or whatever) to a fully functional windows computer

Brian

On Wed, Dec 30, 2020 at 8:35 AM Liam Plybon <liam@...> wrote:

Even using Ethernet and Wifi are not perfect solutions when using VMs like Parallels. Earlier this year, I spent quite a while with a customer that was trying to use Ethernet on Parallels, and we found that the system wasn't actually allowing any access to the Ethernet port for Windows. It was quite bizarre. Similar things can happen with all of the ports.


Really, using a VM to get windows on a non-windows computer will eventually be a pain no matter how good of an IT person you are. Getting a cheap laptop with the latest version of Windows isn't very hard, and you can keep it purely for astronomy. It will save a lot of heartache. When you are done imaging, you can transfer the files to your Mac and do what you already do without relegating part of your system to Windows. 


Liam

Astro-Physics




From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of weihaowang <whwang@...>
Sent: Wednesday, December 30, 2020 9:55 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Lost communications with mount
 
Hi George,

I don't have any Windows PC.  The only reasons I run Windows on my Mac are to run Registar
and to control telescopes/cameras.  I tried to get rid of Windows completely, but there are 
still a few programs that only have Windows options.

And as I said, I started with native Windows in Bootcamp, and then found it's not as stable
as Windows under Paralles.  It was perhaps more than 8 years ago, and perhaps bootcamp
is better now, but I don't have a chance to find out.


--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/



--
Brian 



Brian Valente


Re: Lost communications with mount

 

Even using Ethernet and Wifi are not perfect solutions when using VMs like Parallels. Earlier this year, I spent quite a while with a customer that was trying to use Ethernet on Parallels, and we found that the system wasn't actually allowing any access to the Ethernet port for Windows. It was quite bizarre. Similar things can happen with all of the ports.


Really, using a VM to get windows on a non-windows computer will eventually be a pain no matter how good of an IT person you are. Getting a cheap laptop with the latest version of Windows isn't very hard, and you can keep it purely for astronomy. It will save a lot of heartache. When you are done imaging, you can transfer the files to your Mac and do what you already do without relegating part of your system to Windows. 


Liam

Astro-Physics




From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of weihaowang <whwang@...>
Sent: Wednesday, December 30, 2020 9:55 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Lost communications with mount
 
Hi George,

I don't have any Windows PC.  The only reasons I run Windows on my Mac are to run Registar
and to control telescopes/cameras.  I tried to get rid of Windows completely, but there are 
still a few programs that only have Windows options.

And as I said, I started with native Windows in Bootcamp, and then found it's not as stable
as Windows under Paralles.  It was perhaps more than 8 years ago, and perhaps bootcamp
is better now, but I don't have a chance to find out.


--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


Re: Continued: (Field curvature with Flatteners and compressors)

Roland Christen
 

The TEC 140 FL is the same as the ED model and would use the same spacer. For each 3mm filter and 3mm cover glass you need to add 1mm of back focus. If the camera company specifies the chip distance as the optical path, then the cover glass 1mm is not added. I am not familiar with your camera, but at least for the filters you need to add 1/3 of the filter thickness to the back focus calculations. For smaller chips the ideal back focus distance will be between 1/2 and 1mm further than for the largest full frame chips. So plan on adding 1 to 2mm and see what you get.

Rolando



-----Original Message-----
From: lmbrabec@...
To: main@ap-gto.groups.io
Sent: Tue, Dec 29, 2020 8:12 pm
Subject: Re: [ap-gto] Continued: (Field curvature with Flatteners and compressors)

Really cool information Roland!  Would you by chance have any data to share with TEC140FL with the QTCC?  I'm early on trying to fine tune my new TEC140FL with a QTCC and ZWO ASI294MC Pro camera to minimize star elongations in the corners of the image.  I'm curious how sensitive it might be to minor changes in the back focus versus the spec. of 80.8 mm +/- 1.0 mm (I also have the 18.3 mm spacer for use with the TEC140).  All the best, Scott

--
Roland Christen
Astro-Physics


Re: Changing polar alignment...Ground shifting?

Tom Blahovici
 

Hi
I'm in Montreal. No earthquakes here lately. Occasionally get some 4ish quakes one every 5 to 10 years.
Could well be the rain though. We had like 2 inches of rain lately and then -12c weather.
I also just remembered that at one point before the poor tracking showed up, that my rotator came loose. I then tightened it quite snug.
Maybe that was the culprit?
In any case, all seems well now. 
Tom


Re: APCC & NINA Platesolver "sync" question

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


Re: APCC & NINA Platesolver "sync" question

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

11161 - 11180 of 86428