INDI or ASCOM Alpaca?


Ray Gralak
 

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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


Craig Anderson
 

I think continued ASCOM support is essential. My vote is for ASCOM Alpaca. 

Thanks for asking!

-Craig


On Apr 26, 2019, at 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


Bill Long
 

+1 for Alpaca.
From: ap-gto@... on behalf of Craig Anderson craig@... [ap-gto]
Sent: Friday, April 26, 2019 5:40:55 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
 
 

I think continued ASCOM support is essential. My vote is for ASCOM Alpaca. 


Thanks for asking!

-Craig


On Apr 26, 2019, at 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


Michael Fulbright <mike.fulbright@...>
 

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)' 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



Bill Long
 

Maybe just open up the source on the V2 ASCOM driver? Then folks could easily adapt applications to work with it, even if they dont use ASCOM? 


From: ap-gto@... on behalf of Michael Fulbright mike.fulbright@... [ap-gto]
Sent: Friday, April 26, 2019 5:52 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
 
 

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)' 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



David
 

+1 for Alpaca.  



On Apr 26, 2019, at 8:55 PM, Bill Long bill@... [ap-gto] <ap-gto@...> wrote:


Maybe just open up the source on the V2 ASCOM driver? Then folks could easily adapt applications to work with it, even if they dont use ASCOM? 


From: ap-gto@... <ap-gto@...> on behalf of Michael Fulbright mike.fulbright@... [ap-gto] <ap-gto@...>
Sent: Friday, April 26, 2019 5:52 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
 
 

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)' 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc 
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver






Ray Gralak
 

The problem with doing an Alpaca Astro-Physics driver today is there are no applications outside of windows that can talk to it! It might be a while until software developers start writing cross platform applications, or even applications specific to LINUX and Mac OSX.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Friday, April 26, 2019 6:15 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



+1 for Alpaca.




On Apr 26, 2019, at 8:55 PM, Bill Long bill@outlook.com [ap-gto] <ap-gto@yahoogroups.com> wrote:


Maybe just open up the source on the V2 ASCOM driver? Then folks could easily adapt applications to
work wit h it, even if they dont use ASCOM?

________________________________

From: ap-gto@yahoogroups.com <ap-gto@yahoogroups.com> on behalf of Michael Fulbright
mike.fulbright@pobox.com [ap-gto] <ap-gto@yahoogroups.com>
Sent: Friday, April 26, 2019 5:52 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



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)' groups3@gralak.com [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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.astro-
physics.com%2Findex.htm%3Fproducts%2Faccessories%2Fsoftware%2Fapcc%2Fapcc&data=02%7C01%7C%
7Cd5ad80682f764d261fc408d6caaab2ee%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636919231
822083929&sdata=tUj%2Fe%2BJYnWuQbAwifNwH%2BgjMLEWJ2W5wumxy%2Bgs9Res%3D&reserved=0>
Author of PEMPro V3: https://www.ccdware.com
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ccdware.com&data=02%7C01%7C
%7Cd5ad80682f764d261fc408d6caaab2ee%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369192
31822093934&sdata=muCFLqebibIXPMIMYzX5dBpj%2BXXQ9MXsB0o8iUcQ2B8%3D&reserved=0>
Author of Astro -Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.siriusimaging.com%2Fapdriver&dat
a=02%7C01%7C%7Cd5ad80682f764d261fc408d6caaab2ee%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%
7C0%7C636919231822103945&sdata=ZBPw5tLApnHssDq5ewOXzLs%2B%2Bs42lpWmWsNLn2nb3IQ%3D&re
served=0>








Dale Ghent
 

Hi Ray, thanks for bringing these subjects up. There are a lot of aspects to each.

Foremost, I don't see this as an exclusive OR choice between the two, and I ask that everyone try to mentally maneuver away from the "it has to be one or the other, and never both" mindset. There's no reason why ASCOM (in any flavor) and INDI frameworks can't enjoy parity insofar as A-P hardware support goes. There's plenty of need and room for both across a plethora of OSes, architectures, and programming languages.

This topic is of great interest to me personally and there is a lot of technical and philosophical ground to cover, but it finds me busy packing on the eve of a trip so I'm unable to contribute to it in-depth at this moment. In the quiet moments on the plane I'll put my thoughts on my personal blog, as I find it a better venue than email to lay things out.

/dale

On Apr 26, 2019, at 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-gto@yahoogroups.com> 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



------------------------------------
Posted by: "Ray Gralak &#92;(Groups&#92;)" <groups3@gralak.com>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
------------------------------------

Yahoo Groups Links



Ray Gralak
 

If sources are available for the Alpaca driver it would be a possible option.
It's up to Astro-Physics if the source code will be open source. But I don't think some of the things you said you are interested in would be in the driver. Most of the non-trivial logic in APCC and PEMPro is not something that would be in an Alpaca driver. It's application level code, not driver code.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Friday, April 26, 2019 5:53 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



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)' groups3@gralak.com [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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver





Ray Gralak
 

Hi Dale,

Okay great. I am looking forward to reading your blog after you get a chance to post it.

And yes, I think there is a possibility of supporting both INDI and Alpaca. The dilemma is that Alpaca's driver interface is not
available. Thus, even if an A-P Alpaca driver is created other manufacturers might not want to create new drivers until ASCOM can
create a driver framework. Then after a critical mass of Alpaca drivers is reached it might then make sense for application
developers to create non-Windows applications for Alpaca.

Best regards,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Friday, April 26, 2019 6:40 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?




Hi Ray, thanks for bringing these subjects up. There are a lot of aspects to each.

Foremost, I don't see this as an exclusive OR choice between the two, and I ask that everyone try to mentally
maneuver away from the "it has to be one or the other, and never both" mindset. There's no reason why ASCOM
(in any flavor) and INDI frameworks can't enjoy parity insofar as A-P hardware support goes. There's plenty of
need and room for both across a plethora of OSes, architectures, and programming languages.

This topic is of great interest to me personally and there is a lot of technical and philosophical ground to cover, but
it finds me busy packing on the eve of a trip so I'm unable to contribute to it in-depth at this moment. In the quiet
moments on the plane I'll put my thoughts on my personal blog, as I find it a better venue than email to lay things
out.

/dale

On Apr 26, 2019, at 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-
gto@yahoogroups.com> 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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



------------------------------------
Posted by: "Ray Gralak &#92;(Groups&#92;)" <groups3@gralak.com>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
------------------------------------

Yahoo Groups Links





Thomas Swann
 

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 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)' 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver




Ray Gralak
 

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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Friday, April 26, 2019 8:02 PM
To: ap-gto@yahoogroups.com
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 mike.fulbright@pobox.com [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)' groups3@gralak.com [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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver






Michael Fulbright <mike.fulbright@...>
 

1.

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:

        http://astro-physics.com/tech_support/mounts/protocol-G.pdf

        http://astro-physics.com/tech_support/mounts/command_lang.htm

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.

2.

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.
 
3.

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 slightly.

4-6.

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 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 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)' 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): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto: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 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 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)' 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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>



Ray Gralak
 

Hi Michael,

Case in point - sending a "pulse guide" to the mount.
Okay, I think I can provide insight into this.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction
and 'xxx' is the duration in milleseconds.
But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control boxes with that version in use. What's a driver author to do about that? :-)

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.
Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is "convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

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.
That's why you always change the speed and start the move right after each other. Regarding "no responses", that's the Meade protocol. But it has worked fine for 20 years.

So on the off chance the change rate command failed you might move the mount for
2500ms at slew speed, for example.
I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you can send the change rate command followed by the start move all in one string. This virtually guarantees that if the rate is not accepted neither will the start of the move.

Hopefully there has been progress in the protocol design so you can do this with a saner
atomic operation.
Even if there was a complete redesign of the command protocol you can't expect the thousands of existing mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 11:48 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



1.

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:

http://astro-physics.com/tech_support/mounts/protocol-G.pdf

http://astro-physics.com/tech_support/mounts/command_lang.htm

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.

2.

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.

3.

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 slightly.

4-6.

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 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 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)' groups3@gralak.com [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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@yahoogroups.com
> 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 mike.fulbright@pobox.com [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)' groups3@gralak.com [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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>





Ray Gralak
 

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 mount firmware.

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 years later.

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.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 11:48 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



1.

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:

http://astro-physics.com/tech_support/mounts/protocol-G.pdf

http://astro-physics.com/tech_support/mounts/command_lang.htm

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.

2.

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.

3.

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 slightly.

4-6.

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 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 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)' groups3@gralak.com [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): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@yahoogroups.com
> 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 mike.fulbright@pobox.com [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)' groups3@gralak.com [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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>





Michael Fulbright <mike.fulbright@...>
 

If newer firmwares support a better command for longer pulse requests then clearly you'd want to use it no?  At the moment that isn't even an option as it isn't documented

Having to send a command twice because the protocol is poorly designed is unfortunate I understand for older mounts.  It is not optimal but what can you do?

I've already set things up so for pre-V level firmwares there is a minimal functional legacy INDI driver.  I have no intention of working on it.  It is out there for anyone who wants to contribute. 

I understand AP doesn't have this much flexibility although I believe APCC does set a "you have to be this tall to ride" threshold for firmware level as well.  Which only makes sense.

I think you've swerved a bit into a specific example away from the larger picture.

How do you tell with protocol 'G' if the mount has been unparked and initialized?

How do you tell which firmware level the mount has?

How do you set a meridian delay?

Etc.

I've been through all this with the helpful feedback with Howard as there are things you need to do with the mount you simply can't with the available documentation.

I gave my feedback as you requested Ray. 

I'd really be interested in what Astro-Physics has to say.

Michael

On 4/27/19 3:24 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
 

Hi Michael,

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

Okay, I think I can provide insight into this.

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

But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control boxes with that version in use. What's a driver author to do about that? :-)

> 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.

Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is "convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

> 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.

That's why you always change the speed and start the move right after each other. Regarding "no responses", that's the Meade protocol. But it has worked fine for 20 years.

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

I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you can send the change rate command followed by the start move all in one string. This virtually guarantees that if the rate is not accepted neither will the start of the move.

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

Even if there was a complete redesign of the command protocol you can't expect the thousands of existing mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> 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:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> 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.
>
> 2.
>
> 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.
>
> 3.
>
> 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 slightly.
>
> 4-6.
>
> 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 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 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)' 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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto: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 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 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)' 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): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>



Michael Fulbright <mike.fulbright@...>
 

I have never suggested anything approaching the entire protocol.

Of course there are commands which have specialized use which you don't release to end users.

I think it is indisputable that there are reasonable operations one would want to take with their modern AP mount which are not covered adequately in the 'G' document.

Michael Fulbright

On 4/27/19 3:35 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
 

> 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 mount firmware.

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 years later.

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.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> 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:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> 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.
>
> 2.
>
> 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.
>
> 3.
>
> 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 slightly.
>
> 4-6.
>
> 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 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 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)' 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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto: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 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 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)' 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): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>



Ray Gralak
 

Having to send a command twice because the
protocol is poorly designed is unfortunate I
understand for older mounts.
It is a workaround to make it extremely reliable. If you are not doing that in your experimental INDI driver, maybe you should if you detect an early version of firmware.

A-P didn't design the original protocol and it has to be supported as there are mounts that still use the protocol. Remember this post is about INDI/Alpaca, so we are talking about supporting all versions of the firmware.

It is simply not that hard to do two commands, one to start and one to stop. BTW, do you also think that separate commands for RA and Dec are wrong too? You almost always want both if you want one of them. But you have to send two commands.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 12:37 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



If newer firmwares support a better command for longer pulse requests then clearly you'd want to use it no? At the
moment that isn't even an option as it isn't documented

Having to send a command twice because the protocol is poorly designed is unfortunate I understand for older
mounts. It is not optimal but what can you do?

I've already set things up so for pre-V level firmwares there is a minimal functional legacy INDI driver. I have no
intention of working on it. It is out there for anyone who wants to contribute..

I understand AP doesn't have this much flexibility although I believe APCC does set a "you have to be this tall to
ride" threshold for firmware level as well. Which only makes sense.

I think you've swerved a bit into a specific example away from the larger picture.

How do you tell with protocol 'G' if the mount has been unparked and initialized?

How do you tell which firmware level the mount has?

How do you set a meridian delay?

Etc.

I've been through all this with the helpful feedback with Howard as there are things you need to do with the mount
you simply can't with the available documentation.

I gave my feedback as you requested Ray.

I'd really be interested in what Astro-Physics has to say.

Michael


On 4/27/19 3:24 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:




Hi Michael,

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

Okay, I think I can provide insight into this.

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

But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control
boxes with that version in use. What's a driver author to do about that? :-)

> 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.

Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for
many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is
"convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

> 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.

That's why you always change the speed and start the move right after each other. Regarding "no
responses", that's the Meade protocol. But it has worked fine for 20 years.

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

I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you
can send the change rate command followed by the start move all in one string. This virtually guarantees that if the
rate is not accepted neither will the start of the move.

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

Even if there was a complete redesign of the command protocol you can't expect the thousands of existing
mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common
sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only
driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@yahoogroups.com
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> 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:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> 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.
>
> 2.
>
> 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.
>
> 3.
>
> 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 slightly.
>
> 4-6.
>
> 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 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 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)' groups3@gralak.com [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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> > Sent: Friday, April 26, 2019 8:02 PM
> > To: ap-gto@yahoogroups.com
> > 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 mike.fulbright@pobox.com [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)' groups3@gralak.com [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): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>





Ignacio Diaz Bobillo
 

Hi everyone,

I have been experimenting with INDI + Ekos + Kstars lately, on my AP1100 CP4, as there already is a (somewhat buggy) driver available. I ran it with Apogee CCDs (Alta and Aspen) & FW, robofocus, and QHY guide cam.

It is quite an impressive and integrated platform, from my point of view, for full end-to-end observatory automation. The suit includes planetarium app with lots of loadable professional DBs (including DSS alla Aladin), a sophisticated sequencer, astrometry plate-solving, auto-guiding, auto-focusing, auto meridian flips, dome control, etc. As with most things Linux/opensource, it is a bit unstable and buggy, but quite matured to the point of being usable. Also, the pace of development/debugging is quite impressive. And not that I haven't had problems with commercial software in the past!

BTW, it has a client/server architecture, so one can run the INDI sever on a small form factor local computer (I ran it on a Raspberry Pi 3B+ attached to the OTA), and have all the observatory hardware driven from there, while controlling/monitoring it from clients (Kstars, Ekos, Astrometry) running on the same LAN (laptop/PC running any OS, android devices, etc). So no need to run remote desktop apps, while keeping low the load on the server.

I would definitely support this effort! And given the comparative stages of development (INDI vs ASCOM Alpaca), I would suggest to start with INDI, and then add Alpaca when the time comes.

The current experimental driver for AP mounts is already quite usable, particularly when connected thru USB (had some issues thru ethernet).

Hope it helps,
Ignacio






Bill Long
 

There is likely a good middle ground here though where AP can keep their secrets and users safe, and developers can have access to the tools they need to write their own software.


From: ap-gto@... on behalf of 'Ray Gralak (Groups)' groups3@... [ap-gto]
Sent: Saturday, April 27, 2019 12:35 PM
To: ap-gto@...
Subject: RE: [ap-gto] INDI or ASCOM Alpaca?
 
 

> 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 mount firmware.

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 years later.

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.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> 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:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> 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.
>
> 2.
>
> 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.
>
> 3.
>
> 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 slightly.
>
> 4-6.
>
> 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 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 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)' 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): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto: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 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 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)' 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): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>