Tony,

Nexdome developer points at SGP as the issue - so what can be done?

Have you tried using Active dome control mode? In APPM, you would instead point the dome control to the NexDome driver. APPM will then send the NexDome driver the mount's RA/Dec destination coordinates, which the NexDome driver must then calculate the appropriate Az coordinate to which to move the dome. If the NexDome driver can do that then this should work. At least I think this would circumvent SGPro's involvement, but you might need to disable SGPro's dome connection during the run.

-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 Tony Benjamin
Sent: Sunday, October 4, 2020 8:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Hi Ray,

I did use the Hour Angle strategy.

I think the issue is solely with SGP and the way it implements dome/scope slaving. I've brought this issue up with
Jared (and the developer of the Nexdome ASCOM Driver). Jared hasn't done anything that I'm aware of and the
Nexdome developer points at SGP as the issue - so what can be done? I have heard that the SkyX dome control
does move both the dome/scope simultaneously - but I don't want to move over to the SkyX - yet.