Astronomy interfaces: ASCOM, Alpaca, INDI, and/or Indigo?

[SkyHiker]

Those who read my messages are aware that I am rather unhappy with ASCOM as a standard, from a design point of view. Of course it supports a bunch of useful devices but the main problem is that it is Windows-only and non-distributed (the "device drivers" live on the Windows host!). As a result ASCOM is not a standard for interfacing with small embedded remote devices (directly, not through an ASCOM wrapper), or servers/drivers on small non-Windows computers (or big ones such as MacOS and Linux computers).

ASCOM is based on DCOM, which is a standard that was already dead by the time ASCOM was created. While DCOM is still supported by Microsoft as non-managed software, it was otherwise abandoned in favor of .NET around 2000. The ASCOM developers have finally realized the need for supporting non-Windows devices and created a new interface named Alpaca as a distributed and OS-independent wrapper for ASCOM drivers.

Alpaca is new to me, I just noticed it the other day. There are two other platform independent distributed platforms around that gained some traction: INDI, mostly used on Linux with no native windows solution (just an ASCOM wrapper), and INDIGO, based on INDI and most popular on MacOS. Vendors must be getting confused about what to support.

I get the impression that Alpaca is a patch for an (IMHO) already broken ASCOM system that just adds confusion and makes things worse. If it is good then why not abandon ASCOM and use Alpaca instead, or better, design something from scratch that is completely independent of ASCOM. But we already have INDI and Indigo, do we have to muddy the waters by adding yet another option?

I found this article written by someone who knows this much better than me that I want to share: https://daleghent.com/2019/05/alpaca-in ... the-future

Curious what you all think. I don't expect a unified platform independent distributed distributed standard within a decade but it becomes more and more clear that ASCOM is problematic.

[XCalRocketMan]

Well, I'm not all that knowledgeable of the complete history of ASCOM, and yes, I'm a Windows user. But ASCOM has never failed me yet. It simply works for all my cameras (QHY, ZWO), mounts (CGEM, iOptron, and now AP1100) and software (SGP specifically). So, I for one am sold on ASCOM. I will research Alpaca just for my interest in what's up-and-coming, but I don't see ASCOM going away anytime soon.

[Star Dad]

I'll agree with XCalRocketMan in that ASCOM works for me. I was, quite frankly, stunned when I first hooked up my Atlas mount and realized that ASCOM (I had to get a special serial cable) was the (realistically) only choice. I would MUCH, MUCH prefer to have a Linux solution that worked. Too many pieces of the AP puzzle are stuck on windblows. It would be GREAT if I could communicate with it via wifi/ethernet just as I talk to my printers, camera, scanners, etc. Why are telescope manufacturers so far behind the times?

But it seems that people are somewhat like sheep to be herded. Why does just about every organization pay for Microsoft Office, when a better solution that is free is available (OpenOffice, LibreOffice, etc)? Schools teach MS Word - why not teach using a word processor? Throw a Word person into LibreOffice and they are totally lost - the menus are different. They are both word processors. Should not be that hard to adjust, but it is. This entrenching by an ancient standard can be seen in a wide variety of technologies - i.e. cars that use wheels to steer instead of a joystick. The qwerty keyboard, when it is well documented that the Dvorak keyboard is much more efficient. ASCOM will live until - well maybe for a very long time to come. Perhaps when it becomes cheaper to put an ethernet or wifi connection because ASCOM is too expensive manufacturers will move on.

[KathyNS]

Just being a standard is more important than being good, when it comes to market share. Just look at VHS vs. Beta, or Windows vs. Mac. There is a lot wrong with ASCOM (Don't get me going on SideOfPier! ), but it does have the advantage of being a standard that (mostly) works.

[Star Dad]

VHS Vs Beta! Wow that brings back memories. Bought a Beta machine when I was stationed overseas. Everyone overseas had Beta. Came back to the states and suddenly everything was VHS. <sigh> Well, you made me smile Kathy as I recall that kerfuffle. I am surprised we actually made the transition to digital TV. Man was there howling about that impending move-over.

[JayTee]

Hey Henk,

There's an online seminar going on right now about ALPACA on the Woodland Hills camera website. I'm about to start running errands and can't watch but I thought I would pass that along to you.

Cheers,
JT

[SkyHiker]

Hey Henk,

There's an online seminar going on right now about ALPACA on the Woodland Hills camera website. I'm about to start running errands and can't watch but I thought I would pass that along to you.

Cheers,
JT

Thanks for that JT,

I missed it because I went for a beach walk right before you sent it.

So I looked up the Woodland Hills channel on YouTube and tried to find it. I did not but found a one-year older presentation by Bob Denny. Very nice and motivating for Alpaca. What I learned from it,

• Alpaca is the REST-API version of ASCOM. The difference being, ASCOM is stateful (the objects remain alive and are managed until all clients are gone) while Alpaca is stateless. You can still get a handle and keep querying it (polling) but it's not as fancy as distributed objects.

• Alpaca does not depend on ASCOM or Windows in any way. While they did not say that it was meant to replace ASCOM, it totally looks like it could, and like that was the intention. This is not strange, I have seen OPC (a DCOM based industry protocol) move from DCOM to a stateless version, all because DCOM is a hopeless dinosaur that needs to be abandoned.

• ASCOM and Alpaca implement only the useful common features, no device specific extensions. INDI allows extensions (and interface feature discovery), which has the potential of becoming unwieldy depending on how badly it is abused.

• Alpaca does not require a server while INDI does. I don't know it this is an implementation issue or if this is bad or good. There has to be an Alpaca listener somewhere, just like ASCOM requires a DRPC server.

So, my take on this is that Alpaca will displace ASCOM in the long run but they don't want to tell their customers who invested a lot of money in writing ASCOM drivers. I'm all for that except was it not possible to join forces with INDI, which is similar enough, so we don't have 3 protocols for vendors to worry about but just 2?

As an aside, I also ran into a Losmandy video on the Woodlan Hills channel with some Scott Losmandy introspective. Scott says he wants his mounts to be well crafted, look classy and beautiful, and that it is totally OK to just look at it in awe even if you don't use it! That's what I do, so a sigh of relief here...

[JayTee]

Thanks for the info Henk!

My errand was a Dr. appt so I couldn't just blow it off to watch the seminar. I think I found the video. Alpaca starts at time 2:29:00

Cheer,
JT

[SkyHiker]

Thanks for the info Henk!

My errand was a Dr. appt so I couldn't just blow it off to watch the seminar. I think I found the video. Alpaca starts at time 2:29:00

Cheer,
JT

Cool.

• They said that Alpaca is the future (my take on it is that it will replace ASCOM eventually).

• It has only just been released as part of ASCOM 6.5 with full API documentation

• A device can implement Alpaca for direct access via a web service. Its GUI is included as part of that, in the device. No server needed.

• If a device is connected through USB you will have to launch a proxy driver for it to look like an Alpaca device with IP address

• Windows has a discovery service that automatically wraps an ASCOM driver around it so you can't even tell the difference

• It looks like if a vendor provides an Alpaca driver, that ASCOM support is provided as per the last bullet

• On non-Windows devices you may have to type the IP address to configure it in a web browser (no discovery service)

• It is geared towards IP (ethernet/WiFi) not USB. No more USB to ethernet with repeaters for long distances.

So, it looks good, with a seamless migration path towards Alpaca. ASCOM can eventually die once all clients have moved to Alpaca. Conversely, ASCOM devices on Windows can be used from Alpaca (on any computer/OS) through the bidirectional ASCOM/Alpaca wrapper on Windows. Once those devices are moved to Alpaca the wrapper is no longer needed and ASCOM is out of the loop.

It looks pretty clean - perhaps using the equivalent of the well-appreciated ASCOM interfaces for Alpaca is the key to success. Meaning that, by forcing the vendors to keep things simple and well defined without device specific clutter, more reliable drivers are achieved and better reliability and usability than with INDI. I don't know if this is true, I just heard the gospel so now I need an INDI pep talk to make up my mind.

Now to wait for vendors to support it, currently Optec is the only one that is moving.