APCC/APPM requirements for the Astro-Physics mounts.


Arvind
 

Hi, A-P team:

I am asking this for a future purchase, and hopefully for the benefit of others who might have a similar question.

So far I have been under the impression that to be able to build a pointing model and use it with any of the Astro Physics mounts, I had to use the APPM to build a model, and APCC to use that model with the mount to improve pointing & tracking accuracy; especially for unguided imaging to factor in real-world sources of errors even with near-perfect polar-alignment. Of course, one can choose NOT to do all this and just do autoguiding to provide the necessary feedback and still get wonderful results with A-P mounts.

Is my understanding correct on the need for APPM/APCC to fully benefit from encoders & unguided imaging with the A-P mounts? If so, is there a plan to move the model building & usage to the mount computer itself eventually to allow customers to use any software, or even a hand-controller, to coordinate model building & usage? Perhaps a firmware update to CP4/CP5. Is there any other performance-related functionality that is only provided as part of APCC/APPM software?

Thanks & best regards,
Arvind



ap@CaptivePhotons.com
 

I'd like to offer a new-customer perspective on this.  I came from a MyT and The Sky X and so had some concerns about a software based system as opposed to hardware/firmware, and what limitations this may impose.   I was not a fan of TXS generally, so was then not a fan of the … I'm not sure restrictions are so much the right word as perhaps hurdles you had to overcome when you wanted to use other software.  This despite it having been around forever and had a ton of interfaces/techniques documented.

 

I found the AP system a different world even if a lot of similarities.


It required APCC and APPM to build and use a model (and so far as I know that's the only way) just like TSX and tPoint.  And like TSX it has a ton of options and settings (though I will also say that the defaults are a lot more sensible and need less changing to just get started).  And like TXS (at the time) it is 32 bit only.  However…

 

It does not get in the way. 


It is possible to use the mount without APCC (through the ASCOM driver) though without the model, but with encoder benefit.  But I think rather pointless.

 

The use of APCC is transparent to other applications; it's just plain ASCOM.  While you can tweak things in APCC (e.g. limits), the application does not really 'see' that the mount is anything special.  I just converted to NINA and all was (almost) well.  The almost was frankly that I forgot to undo some special settings left over from TSX.

 

Now secondarily to that, NINA in particular has been customized so it can interact directly with APPM. You can actually use NINA to build your model; it does the work of invoking APPM, building and loading the model, you never need touch it.  I personally prefer to do it directly, but it's all in there.   An advantage of doing it from NINA is it can be pre-programmed to go off at a certain time, for hands-free model building.

 

I am to the point now that I only touch APCC once most nights -- at the end, I park from there instead of NINA, as I keep NINA and APCC's park defaults to different locations.

 

The only downside I've seen so far (again, as a new user) is the 32 bit limitations.  When using APPM itself (vs NINA or TSX) to control the camera, its memory limitations come into play.  However, these vanish if you tell APPM to use NINA or TSX (or probably others).  So it is really moot; people with large full frame cameras are better off just starting there, not trying to let APPM use the camera itself.  [Insert Ray's protest here, that the issue is really ZWO's and probably others lousy ASCOM driver memory utilizations, but from a user perspective it does not matter who is at fault -- just use the 64 bit application for camera and it is all moot].

 

My GUESS is also that doing these things in software vs firmware provide for a faster development cycle, and more flexibility since PC programs can grow faster on disk and computer memory than inside firmware.  In just the 3 months or so since I got my mount quite a few new features were added.

 

Short version: As someone coming from a "software" mount, the integration and interactions of APCC and APPM do not get in the way.  I think that's because Bisque was a software company that also builds hardware, but (my view) AP is a hardware company that also does software (well, Sirius Imaging does).

 

As to what's planned… I of course have no idea.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Arvind via groups.io
Sent: Thursday, November 4, 2021 12:11 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC/APPM requirements for the Astro-Physics mounts.

 

Hi, A-P team:

 

I am asking this for a future purchase, and hopefully for the benefit of others who might have a similar question.

 

So far I have been under the impression that to be able to build a pointing model and use it with any of the Astro Physics mounts, I had to use the APPM to build a model, and APCC to use that model with the mount to improve pointing & tracking accuracy; especially for unguided imaging to factor in real-world sources of errors even with near-perfect polar-alignment. Of course, one can choose NOT to do all this and just do autoguiding to provide the necessary feedback and still get wonderful results with A-P mounts.

 

Is my understanding correct on the need for APPM/APCC to fully benefit from encoders & unguided imaging with the A-P mounts? If so, is there a plan to move the model building & usage to the mount computer itself eventually to allow customers to use any software, or even a hand-controller, to coordinate model building & usage? Perhaps a firmware update to CP4/CP5. Is there any other performance-related functionality that is only provided as part of APCC/APPM software?

 

Thanks & best regards,

Arvind

 

 


Mike Hanson
 

Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being shipped with the Mach 2.  We are working to make this available for the CP4/keypad combo.  Here's some recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact with your camera and other software in ways that the keypad cannot.  For example, APPM can initiate image captures and plate solves, which enables automation in the mapping process.  This also enables model data to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.  Either APPM/APCC or the Keypad model can run passively in the background while using other third-party software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning curve.  It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson


Arvind
 

Thank you for the clarification, Mike. It's good to know first hand about these improvements and how they come together!

Linwood, appreciate your new-customer perspective as well; lots of interesting points & experiences have been shared in your response, so I thank you for taking the time to be thorough. 

Overall it's good to know that I am better off using the APCC Pro than not, especially if I'm going to be buying an encoder version of A-P mounts to be able to fully utilize its capabilities. I'll be using another mount for my smaller / portable scopes so I'm exploring options for my toa-150b which will most likely be semi-permanently mounted and maybe travel with me on rare occasions - likely 1100AE or the 1600AE. I will continue to track the updates around NINA-APCC integration as well -- NINA is what I am currently using for image acquisition. I hope the 32-bit issues are addressed on the APMM side though (wouldn't have known if you have not called this one out, so I will try to learn more!). But good to know these are not deadends and there are known workarounds.

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence of internet connected devices and especially in our hobby how we're most often already using an internet connected computer, applying a firmware patch periodically (can even automate this with customer consent) might solve the problem. In fact, the more often this is done the less wrinkles such a process would have -- and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking could be then done using any protocol compliant software (say, NINA to send GoTo commands, align commands, sync commands etc) because the mount itself would know how to handle those situations internally without requiring a desktop program. But this is just wishful thinking on my side :-)

Thanks, and best regards,
Arvind

On Thu, Nov 4, 2021 at 12:17 PM Mike Hanson <mikeh@...> wrote:
Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being shipped with the Mach 2.  We are working to make this available for the CP4/keypad combo.  Here's some recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact with your camera and other software in ways that the keypad cannot.  For example, APPM can initiate image captures and plate solves, which enables automation in the mapping process.  This also enables model data to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.  Either APPM/APCC or the Keypad model can run passively in the background while using other third-party software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning curve.  It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson


Ray Gralak
 

Hi Arvind,

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence
of internet connected devices and especially in our hobby how we're most often already using an internet
connected computer, applying a firmware patch periodically (can even automate this with customer consent)
might solve the problem. In fact, the more often this is done the less wrinkles such a process would have --
and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking
could be then done using any protocol compliant software (say, NINA to send GoTo commands, align
commands, sync commands etc) because the mount itself would know how to handle those situations
internally without requiring a desktop program. But this is just wishful thinking on my side :-)
There's another side to this. One problem with the modeling being built in the controller approach is that it is then limited to the hardware of the mount's control box. To improve performance or memory would likely mean buying a new, relatively expensive control box. And that still won't have near the performance and memory/storage of even a modest modern laptop. For example, another manufacturer's mounts have a limited number of mapping points, while there is no limit in APCC. Also, testing, debugging, and improving modeling algorithms is much easier on a desktop, which allows more frequent advances and without requiring a hardware update.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Arvind
Sent: Thursday, November 4, 2021 9:22 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC/APPM requirements for the Astro-Physics mounts.

Thank you for the clarification, Mike. It's good to know first hand about these improvements and how they
come together!

Linwood, appreciate your new-customer perspective as well; lots of interesting points & experiences have
been shared in your response, so I thank you for taking the time to be thorough.

Overall it's good to know that I am better off using the APCC Pro than not, especially if I'm going to be
buying an encoder version of A-P mounts to be able to fully utilize its capabilities. I'll be using another mount
for my smaller / portable scopes so I'm exploring options for my toa-150b which will most likely be semi-
permanently mounted and maybe travel with me on rare occasions - likely 1100AE or the 1600AE. I will
continue to track the updates around NINA-APCC integration as well -- NINA is what I am currently using for
image acquisition. I hope the 32-bit issues are addressed on the APMM side though (wouldn't have known if
you have not called this one out, so I will try to learn more!). But good to know these are not deadends and
there are known workarounds.

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence
of internet connected devices and especially in our hobby how we're most often already using an internet
connected computer, applying a firmware patch periodically (can even automate this with customer consent)
might solve the problem. In fact, the more often this is done the less wrinkles such a process would have --
and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking
could be then done using any protocol compliant software (say, NINA to send GoTo commands, align
commands, sync commands etc) because the mount itself would know how to handle those situations
internally without requiring a desktop program. But this is just wishful thinking on my side :-)

Thanks, and best regards,
Arvind

On Thu, Nov 4, 2021 at 12:17 PM Mike Hanson <mikeh@...> wrote:


Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being
shipped with the Mach 2. We are working to make this available for the CP4/keypad combo. Here's some
recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs
corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact
with your camera and other software in ways that the keypad cannot. For example, APPM can initiate image
captures and plate solves, which enables automation in the mapping process. This also enables model data
to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.
Either APPM/APCC or the Keypad model can run passively in the background while using other third-party
software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning
curve. It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson