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
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
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.
Park, IL 61115
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
I imagine most developers would take their chances
on having _any_ information compared to the
decade+ old protocol documentation that currently
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:
Case in point - sending a "pulse guide" to the
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
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
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 enough.
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
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.
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 it.
For this to be possible I just need enough
knowledge of what is under the hood so I can
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
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.
On 4/27/19 1:07 PM, 'Ray
groups3@... [ap-gto] wrote:
So what do
people hope will see happen with increased
support for Alpaca or INDI?
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 commands)
2. More MAC and LINUX applications?
3. Ability to run APCC and other apps on a
Raspberry Pi 3 or other small low power
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?
Author of APCC (Astro-Physics Command Center):
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver:
> -----Original Message-----
> From: ap-gto@...
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM
> 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.
> On 4/27/2019 12:52 AM, Michael Fulbright
mike.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)'
> Hello all,
> Of those users wishing for a non-Windows
support for your mount, which platform would
> 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 LINUX or MACs,
> and there may not be for some time.
> However, ASCOM Alpaca is modular as
opposed to INDI's monolithic design. Once
> 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
> knowledge or preferences if you are
interested in this topic.
> -Ray Gralak
> Author of APCC (Astro-Physics Command
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: