> 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.
I think you would be very disappointed if you think that
having the complete protocol will "spoil the secret sauce"
for APCC. Most of what APCC does requires a lot of logic
that has nothing to do with the command protocol. Most of
the calculations and features of APCC are in APCC, not the
For instance the mount firmware doesn't even have a notion
of the park positions. That's all in the software.
That said, a few of the reasons the entire protocol has
not been published are:
1) Another vendor once copied much of the command protocol
to the point that they could even use the Astro-Physics V2
ASCOM driver until they created their own driver a few
2) Along the same line some of the commands would give
hints to other vendors how the encoders and limits and
other features work in the firmware.
3) Some of the commands are "dangerous" and should only be
used by Astro-Physics to reconfigure the control boxes.
Accidental or experimental changes by a user causing their
mount to not operate as it should would cause a
significant number of support calls.
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: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> 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
> For longer pulses you have to do a convoluted
sequence for changing the mount move speed to guide, then
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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 tinker.
> But I suspect what I want for different reasons would
actually help a wide swath of AP users who just want to
> 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
> 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
> constructing the solution from a business viability
> I appreciate AP considering the use cases of all
users - hopefully we can move towards wider support of
> Michael Fulbright
> On 4/27/19 1:07 PM, 'Ray Gralak (Groups)'
groups3@... [ap-gto] wrote:
> 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 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 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):
> 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 Alpaca?
> > I agree, Michael, if the mount commands are
fully documented, A-P can devote their resources to
> > see fit, and if something new pops up or A-P's
choice doesn't fit their needs, then people will be able
> write the
> > software that does what they need. Making
information like that available fosters an environment
> people can
> > create new innovative solutions. That's good for
AP and the users.
> > thomas
> > 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
> > 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)'
groups3@... [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 LINUX
> or MACs,
> > 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 your
> > knowledge or preferences if you are interested
in this topic.
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center):
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: