Re: INDI or ASCOM Alpaca?

Ray Gralak

Hi Michael,

Thank you for giving AP's stance on these matters. It is good to understand so people looking for open solutions
can choose appropriately. I will incorporate this into my future plans for what equipment I will deploy.
From the responses on this list it seems that the number of people with A-P mounts looking for an "open" solution totals less than a dozen, so maybe that has been a deciding factor already? That said, I don't think this will affect the sales price or difficulty of selling your mount nor future sales of A-P mounts. There will be a cross platform solution but it will probably not be open source.

BTW, there are other mounts out there with completely unpublished protocols, like Software Bisque and Planewave mounts. At least enough of the A-P protocol is available to slew to targets, autoguide, park/unpark, etc.

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
Author of PEMPro V3:
Author of Astro-Physics V2 ASCOM Driver:

-----Original Message-----
From: []
Sent: Wednesday, May 1, 2019 11:31 AM
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?

Thank you for giving AP's stance on these matters. It is good to understand so people looking for open solutions
can choose appropriately. I will incorporate this into my future plans for what equipment I will deploy.

I think if you are losing market share because someone can run your ASCOM driver on a different mount then
customers much take the mechanical sophistication of AP mounts over others as much of a bonus?

If you are going to limit how people can use a piece of high end equipment they purchased then that is really
disappointing but again it is good to know so I can make appropriate equipment choices in the future.

Michael Fulbright

On 4/27/19 6:36 PM, Marj [ap-gto] wrote:

Hello Michael,

The command documentation still exists, though at a different URL due to our new website. You can access
all of our previous technical support documentation from the Support tab on our new website. Follow the link to the
current published command language document for the GTOCP3 and GTOCP4. I made a few tweaks to it a few
minutes ago to more clearly explain the control box versions. Note that the document reflects all commands through
version Q, not just version G. I have not added any commands at this time.

Thank you for your feedback below. As I mentioned previously, we will consider providing additional
commands. However, we have to weigh important factors as Ray mentioned in a recent post.

We are acutely aware that at least one European and one Chinese company have advised their customers to
use our V2 driver to operate their mounts. That annoyed us very much as you can imagine since we made (and
continue to make) an investment in the V2 driver for the benefit of AP users and it is more full-featured than most
drivers. Use of our driver enabled these companies to bring their mounts to market directly competing with us. We
have provided safeguards so that they cannot use APCC.

Secondly, we truly feel that users will more safely operate their mounts if they use APCC rather than writing
their own software. While you may understand the complexities of safely moving from one part of the sky to
another, most people have no idea what is involved. We have spent years incorporating safety features into APCC.
It is not the commands themselves, but how they are used that is the “secret sauce”. Remote imagers should not
rely on experimental software.

There are some aspects of our command language that we cannot reveal because they are proprietary to our
system. Whatever, we share with our customers would also be shared with competitors.

While there are benefits to making our command language open source, I hope that you can understand the
risks of revealing too much for a small company like ours.

Clear Skies,

Marj Christen

Astro-Physics, Inc

11250 Forest Hills Rd

Machesney Park, IL 61115

Phone: 815-282-1513

Fax: 815-282-9847

From: []
Sent: Saturday, April 27, 2019 1:48 PM
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?


I think this is just good practice to provide documentation for high end devices. This used to be the default
but in recent years more and more rare.

I imagine most developers would take their chances on having _any_ information compared to the decade+
old protocol documentation that currently exists.

Well they would except the protocol documentation doesn't seem to even exist any more - the two links a
web search turns up:

both give 404 errors.

Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".

Case in point - sending a "pulse guide" to the mount.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration
in milleseconds.

For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then
initiate and time a mount move and then terminate the move.

To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to
verify the mount is at the guide speed before you move it

So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed,
for example.

Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.

I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this
is not documented I am not going to release code to the public with it coded that way.

I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is
available but obfuscated in source code somewhere.

Having adequate and up to date documentation should be the minimum hurdle when producing high end
equipment. I would venture most low end mounts have better documentation available. I know the Explore
Scientific PMC-Eight INDI driver I helped with gives documentation for the entire (admitted very simple) protocol
API to developers.

I believe it would be possible to make parts of the protocol required for decent operation of the mount
available without spilling the secret sauce or undermining sales of APCC.


Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and
therefore more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
info as it could be more relevant to them than say someone who writes general purpose software.

What I think is important is to have a minimum level of support for alternative environments. As long as the
information is available for tools to be constructed by motivated individuals or business interests to construct a
solution I don't know that I would expect AP to do more in terms of writing software on these environments.


I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an
under-powered platform I wouldn't waste time trying to get stuff running on it.

I really am not sure developing and writing software for anything other than Windows is a good business
case for AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great

I suspect there are a large number of technically talented people with AP mount that could make some
impressive things happen if given enough information. AP just needs to stoke the fire slightly.


I don't really know how to respond about Alpaca because as far as I know it is all theoretical.

I don't personally see myself ever having one machine talk to another at the device control level over a
network. It is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network
traffic that I just run all things locally on a computer dedicated to the mount/camera at the mount.

If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you
can recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM
has been a bit of an albatross for awhile now that made this not possible.

Final Thoughts

I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I
enjoy using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do

For this to be possible I just need enough knowledge of what is under the hood so I can tinker.

But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to
avoid Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
on the supplier side.

At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot
justify constructing the solution from a business viability viewpoint.

I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of
some fashion.

Michael Fulbright

On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' <> [ap-gto]

So what do people hope will see happen with increased support for Alpaca or INDI?

For example:

1. Just document the specs and let the LINUX and Mac developers figure it out?

(I think developers may be disappointed with this because most of the cool features in APCC require a
lot of work that will not be included in command specs and many features don't use any of the undocumented

2. More MAC and LINUX applications?

3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?

4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?

5. Have the ability from ASCOM applications on Windows to talk to devices on other computers
running LINUX or Mac/OSX?

6. Other things?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro- <http://www.astro->
Author of PEMPro V3:
Author of Astro-Physics V2 ASCOM Driver:

> -----Original Message-----
> From: []
> Sent: Friday, April 26, 2019 8:02 PM
> To:
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
> I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to
whatever they
> see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able
to write the
> software that does what they need. Making information like that available fosters an environment
where people can
> create new innovative solutions. That's good for AP and the users.
> thomas
> On 4/27/2019 12:52 AM, Michael Fulbright
<> [ap-gto] wrote:
> If sources are available for the Alpaca driver it would be a possible option.
> Alternately I would just prefer adequate documentation to allow users to implement solutions to
meet their
> use cases.
> Is Alpaca even something that is realistic in the next year or two?
> Michael Fulbright
> On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' [ap-gto] wrote:
> Hello all,
> Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> Astro-Physics to devote resources?
> INDI or ASCOM Alpaca?
> INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> Alpaca is still in the early stages of development. There are no significant applications that work on
> and there may not be for some time.
> However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> available Alpaca devices can be standalone (over the network or wifi) or on another computer. I
believe INDI only
> works on the computer it is running unless the device has a network interface.
> There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute
> knowledge or preferences if you are interested in this topic.
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> Author of PEMPro V3:
> Author of Astro-Physics V2 ASCOM Driver:

Join to automatically receive all group messages.