Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

ASCOM Alpaca confusion with Windows requirement

  • Please log in to reply
18 replies to this topic

#1 dkb

dkb

    Viking 1

  • -----
  • topic starter
  • Posts: 524
  • Joined: 23 Jul 2008
  • Loc: Minnesota

Posted 10 August 2020 - 04:25 PM

I am a little confused with how the ASCOM Alpaca software is "advertised" and may not be stating it as clearly as it could be so will try to restate it below.  On the main page https://www.ascom-st...oper/Alpaca.htm states:

Alpaca is 100% independent of Windows. Nowhere in the Alpaca ecosystem is Windows (or COM) needed.

and on their main page:

 supported by most astronomy devices which connect to Windows and now Linux and MacOS computers. 

To me this wording made it sound like I could now just use my Mac using ASCOM Alpaca and take advantage of all the ASCOM compatible devices on my macOS.

 

After further investigation this appears this is NOT the case.  In order for macOS or linux box to use a device that has an "ASCOM driver" you still need to have a Windows machine to run some middleware that would then allow macOS or linux to access the device through the Windows machine.  The other option is to use a device that has ASCOM Alpaca drivers.  Only if the device has an ASCOM Alpaca driver do you not need a Windows machine.  I'm not sure how many devices actually have ASCOM Alpaca drivers.

 

Someone correct me if I am wrong with the above but I think that is correct and makes much more sense to me now. 


  • MikeECha likes this

#2 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 192
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 10 August 2020 - 05:25 PM

Sorry for the confusion on the ASCOM main page. The full text of the statement is:

 

ASCOM is a many-to-many and language-independent architecture, supported by most astronomy devices which connect to Windows and now Linux and MacOS computers.

 

 

To me this wording made it sound like I could now just use my Mac using ASCOM Alpaca and take advantage of all the ASCOM compatible devices on my macOS.

I'm a bit confused with this. What ASCOM compatible devices do you have running on your Mac? Alpaca itself isn't a "program" so what programs do you have on your Mac that use ASCOM? Since classic ASCOM is Windows only this seems strange. 

 

 

 

In order for macOS or linux box to use a device that has an "ASCOM driver" you still need to have a Windows machine to run some middleware that would then allow macOS or linux to access the device through the Windows machine.

This is correct. If a device is hooked up  to a Windows computer, and that device is accessible via its (classic) ASCOM (COM/LPC) driver, then of course something is needed to translate between Alpaca (a network protocol) and classic COM (a Windows communication protocol). In this case an Alpaca speaking program like Cartes duCiel running on your Mac would need to use that middleware to bridge the two.

 

 

The other option is to use a device that has ASCOM Alpaca drivers.  Only if the device has an ASCOM Alpaca driver do you not need a Windows machine.

This is also correct. The future now holds the prospect of devices with Alpaca drivers on any platform (including MacOS, Windows, Linux, and even standalone microcontrollers) to talk to applications that support Alpaca on any platform, no Windows needed. Since Alpaca is a network protocol, it is also language independent. Oh, and traditional ASCOM/COM speaking programs on Windows can talk to any of these Alpaca devices (on any platform!) via the new Platform 6.5 Chooser with Alpaca discovery and dynamic bridge-driver creation. No need to bring up ASCOM Remote any more. 

 

 

I'm not sure how many devices actually have ASCOM Alpaca drivers.

There are some, notably commercial devices from Optec, and considerable work has been done by several people which you can see on the ASCOM Developer Forum. Here's a thread from last year just to give you an idea of the activity. Keep in mind that Alpaca is a new technology. Its discovery and management protocols were just recently finalized. 

 

To get info, ask questions, and see what's going on, there are two places to go:

 


Edited by Bob Denny, 10 August 2020 - 05:27 PM.


#3 dkb

dkb

    Viking 1

  • -----
  • topic starter
  • Posts: 524
  • Joined: 23 Jul 2008
  • Loc: Minnesota

Posted 10 August 2020 - 06:13 PM

Thanks for the reply and all the info! :)

 

 

 

I'm a bit confused with this. What ASCOM compatible devices do you have running on your Mac? Alpaca itself isn't a "program" so what programs do you have on your Mac that use ASCOM? Since classic ASCOM is Windows only this seems strange. 

 

I think the confusion comes from all the drivers being referred to as "ASCOM".. and not understanding that there is a difference between "classic" ASCOM and "new" ASCOM that supports Alpaca.  



#4 MikeECha

MikeECha

    Mariner 2

  • *****
  • Posts: 264
  • Joined: 15 Sep 2018
  • Loc: Charlotte, NC

Posted 10 August 2020 - 09:07 PM

I am a little confused with how the ASCOM Alpaca software is "advertised" and may not be stating it as clearly as it could be so will try to restate it below.  On the main page https://www.ascom-st...oper/Alpaca.htm states:

Alpaca is 100% independent of Windows. Nowhere in the Alpaca ecosystem is Windows (or COM) needed.

and on their main page:

 supported by most astronomy devices which connect to Windows and now Linux and MacOS computers. 

To me this wording made it sound like I could now just use my Mac using ASCOM Alpaca and take advantage of all the ASCOM compatible devices on my macOS.

 

After further investigation this appears this is NOT the case.  In order for macOS or linux box to use a device that has an "ASCOM driver" you still need to have a Windows machine to run some middleware that would then allow macOS or linux to access the device through the Windows machine.  The other option is to use a device that has ASCOM Alpaca drivers.  Only if the device has an ASCOM Alpaca driver do you not need a Windows machine.  I'm not sure how many devices actually have ASCOM Alpaca drivers.

 

Someone correct me if I am wrong with the above but I think that is correct and makes much more sense to me now. 

Yes very confusing. The problem is that there are almost no Alpaca drivers to run on Linux or Mac. I am waiting for those drivers to run on RPi without INDI/INDIGO/eko whatever server and use the clients on my Win10 laptops remotely. I think the ASCOM Remote server can serve drivers that are not local as long as Alpaca can detect them over your LAN on other laptops. I have the server installed on my Windows 10 laptop at the mount outside. It works but that is not different than running On Tam Viewer as I have been doing for a while. In fact, on APT if I use the ASCOm Alpaca drivers for my ASI camera I lose the ability to change Live View settings available thru the ASI native driver. 

 

Lets stay tuned for future development.



#5 AnakChan

AnakChan

    Apollo

  • -----
  • Posts: 1,228
  • Joined: 01 Sep 2014
  • Loc: Oz

Posted 30 August 2020 - 01:24 AM

Hopefully mark77 will have his Alpaca on RPi drivers (or code?) available soon.



#6 nebulasaurus

nebulasaurus

    Mariner 2

  • -----
  • Posts: 246
  • Joined: 07 Feb 2009
  • Loc: Mostly Cloudy New Hampshire

Posted 30 August 2020 - 10:15 AM

Yes very confusing. The problem is that there are almost no Alpaca drivers to run on Linux or Mac. I am waiting for those drivers to run on RPi without INDI/INDIGO/eko whatever server and use the clients on my Win10 laptops remotely. I think the ASCOM Remote server can serve drivers that are not local as long as Alpaca can detect them over your LAN on other laptops. I have the server installed on my Windows 10 laptop at the mount outside. It works but that is not different than running On Tam Viewer as I have been doing for a while. In fact, on APT if I use the ASCOm Alpaca drivers for my ASI camera I lose the ability to change Live View settings available thru the ASI native driver. 

 

Lets stay tuned for future development.

Well, I've worked in software all my life, from small desktop apps, to very large web based systems, and this is my take on it all.  I currently manage software development with budgets in the 10's of Millions of dollars annually.

 

The bottom line is that people adopt things mainly because they solve an issue they have, not because it's a shiny new technology, except maybe smart phones.  They are definitely new shiny things most of the time...  

 

Alpaca faces a huge uphill struggle on anything other than windows.  This has little to do with the quality of the technical solution, but because Alpaca doesn't actually solve any issues for the typical Linux astro user.  

 

Let's roll back the clock for a moment.

 

When INDI and ASCOM both came about, they each solved a very significant issue for the astronomy community - a way to provide a common control structure for astronomy devices.  INDI also solved the remote access problem to devices.  Hence adoption on each platform was rapid and revolutionary.

 

Roll forward to today.  What problem does Alpaca solve for Linux users?  The honest answer is none.  It does however solve an issue for windows users who want to use small System-On-Chip (SOC) systems like the Raspberry PI, or run Windows to Windows.  And adoption on SOC systems is where ASCOM is going to slam into a wall.

 

Because INDI is developed under the GPL, all of the drivers, the INDI framework, KStars and Ekos have all of their source published and available.  This is a huge enabler for open source community development.  One coherent body with 3 git repositories.  There are dozens of maintainers.  I've even made a couple of small contributions.

 

ASCOM only has the ASCOM framework itself published as open source.  If you want to see how the Losmandy Gemini ASCOM driver works?  Talk to who develops that and you might get it.  Rinse and repeat for each & every driver.  If I have 2 types of camera, a rotator, a focuser and a telescope I need to deal with 6 different groups to offer help in migration to Alpaca under Linux.  

 

This is a very significant issue that serious hampers community involvement.  When I ran into this very issue initially with ASCOM I started migrating to Linux and INDI.  ASCOM as an entire ecosystem is not really open source, only the framework itself.

 

My guess is that we will see a lot of current ASCOM drivers enhanced to work with Alpaca under windows, but very little serious attention paid to getting widespread cross platform equivalence. 

 

ASCOM is saddled with still using COM as it's backbone.  If cross platform is really a key driver then they will need to drop COM pretty much entirely, other than as a very thin client shim in Windows, and have every ASCOM driver re-written in a portable language like QT, or dotnet 5.0 using Alpaca.  Then ASCOM will need to bring all the drivers under one management umbrella like INDI to encourage community engagement that they will need to support the model long term.

 

I may be very, very wrong in this assessment, time will tell.

 

J


  • rpineau, Jii, MikeECha and 1 other like this

#7 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 473
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 31 August 2020 - 02:56 AM

1) Because INDI is developed under the GPL, all of the drivers, the INDI framework, ..... have all of their source published and available. ASCOM only has the ASCOM framework itself published as open source.   ASCOM as an entire ecosystem is not really open source, only the framework itself.

 

2) If you want to see how the Losmandy Gemini ASCOM driver works?

 

3) ASCOM is saddled with still using COM as it's backbone. They will need to drop COM pretty much entirely, other than as a very thin client shim in Windows,

 

 

4) And have every ASCOM driver re-written in a portable language like QT, or dotnet 5.0 using Alpaca. 

 

 

5) Then ASCOM will need to bring all the drivers under one management umbrella like INDI to encourage community engagement that they will need to support the model long term.

 

1) Most ASCOM source is available.The only thing what matters is that protocol is fully standarised and documented. I can write in any program language I prefer.

 

2) Why is that required? The manufacturer has made a decision to share or not share the code but it does not matter since it talks ASCOM.

3) That´s why they introduced Alpaca to move to IP communication rather then COM.interface

 

4) I hope not. Dictatorship of one language. Bhhhh.

 

5) Central management? I don´t think that INDI and Ascom management differ much.  The protocols should be maintained by a non-profit committees. Long term support in INDI is already failing for me, see below.

 

 

I think the power of INDI is that the interface is communicated in a kind of XML. But I´m less happy about the central server concept. Outside Kstars you need something like the INDI starter which is sadly not maintained by as you call it the "INDI  management" or use the command line INDI server. If you dive into the INDI communication there is an awful often unnecessary amount of communication ongoing.  That does not matter for the user. He only want´s easy to install, to configure and to operate software (without IT knowledge) to control his astro-equipment. And it should work for the whole lifespan of his expensive equipment.

 

Long term support. One practical example. I have an old classic QHY5 camera. It doesn´t work with INDI anymore because QHY decided to remove the drivers from their package which is bundeled in INDI.  But for ASCOM, I can still use the old standalone drivers from 2011, kept safely.

 

Han



#8 asl547

asl547

    Explorer 1

  • *****
  • Posts: 61
  • Joined: 19 Oct 2005
  • Loc: New York

Posted 31 August 2020 - 07:15 AM

Long term support. One practical example. I have an old classic QHY5 camera. It doesn´t work with INDI anymore because QHY decided to remove the drivers from their package which is bundeled in INDI.  But for ASCOM, I can still use the old standalone drivers from 2011, kept safely.

Han


Do “old” ASCOM drivers necessarily work with (1) current versions of Windows 10 (including .NET framework [which I don’t understand]), and (2) current version of ASCOM platform?

Are all ASCOM drivers “standalone”?

Frankly, I don’t understand how “old” drivers become “unsupported” by the hardware manufacturer and what that means (merely no longer made available, or no longer functional because of incompatibility with current Windows and/or ASCOM platform?). If the latter, how do people successfully use “legacy” drivers?

#9 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 473
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 31 August 2020 - 08:18 AM

Up to 2019, I was happily using the old QHY5 under Windows 7. The QHY5 camera and ASCOM driver are a separate install under Windows. Then while experimenting with Linux and INDI, I noticed that the QHY5 worked only with an older version of INDI but not with the latest version. It has something to do with the SDK firmware bundled with INDI which is updated regularly. This was confirmed here.  There are no seperate INDI camera drivers distributed. You get all as one latest INDI package.

 

For Linux & INDI, I solved it by buying a secondhand QHY5-II. So for some hardware like cameras, it could be that your at the mercy of the supplier.

 

The old QHY5 still works in Win10. I have tested it some months ago without problems. But old QHY5 Windows drivers are no longer available from the QHY webpage. frown.gif   Company policy I assume. A large amount of these cameras have been sold and are most likely still around as guider.

 

Han

 



#10 asl547

asl547

    Explorer 1

  • *****
  • Posts: 61
  • Joined: 19 Oct 2005
  • Loc: New York

Posted 31 August 2020 - 09:55 AM

I still would like to know more generally from people who are more knowledgeable about ASCOM whether, and under what circumstances, “old” or “legacy” ASCOM drivers should (or don’t) work under current Windows 10 OS and up-to-date Windows astronomy programs.

#11 Iver

Iver

    Mariner 2

  • *****
  • Posts: 267
  • Joined: 12 Oct 2007
  • Loc: Monterey County,Ca.

Posted 31 August 2020 - 10:32 AM

I still would like to know more generally from people who are more knowledgeable about ASCOM whether, and under what circumstances, “old” or “legacy” ASCOM drivers should (or don’t) work under current Windows 10 OS and up-to-date Windows astronomy programs.

This quote is from the ASCOM site.

 

"Every ASCOM Platform release aims for 100% backward compatibility with current drivers and applications, providing an easy upgrade path and new capabilities that developers and enthusiasts can exploit."



#12 asl547

asl547

    Explorer 1

  • *****
  • Posts: 61
  • Joined: 19 Oct 2005
  • Loc: New York

Posted 31 August 2020 - 10:56 AM

Thanks for the quote. But it only references “current drivers and applications.” My question related to “old” or “legacy” drivers, and whether, and under what circumstances, they continue to work (or fail to work) with the current versions of Windows and astronomy programs. (I believe that this question may go beyond backward compatibility of the ASCOM interface standard itself, but don’t know whether, or the extent to which, or under what circumstances, that actually is true.)

#13 nebulasaurus

nebulasaurus

    Mariner 2

  • -----
  • Posts: 246
  • Joined: 07 Feb 2009
  • Loc: Mostly Cloudy New Hampshire

Posted 31 August 2020 - 05:11 PM

1) Most ASCOM source is available.The only thing what matters is that protocol is fully standarised and documented. I can write in any program language I prefer.

 

2) Why is that required? The manufacturer has made a decision to share or not share the code but it does not matter since it talks ASCOM.

3) That´s why they introduced Alpaca to move to IP communication rather then COM.interface

 

4) I hope not. Dictatorship of one language. Bhhhh.

 

5) Central management? I don´t think that INDI and Ascom management differ much.  The protocols should be maintained by a non-profit committees. Long term support in INDI is already failing for me, see below.

 

 

I think the power of INDI is that the interface is communicated in a kind of XML. But I´m less happy about the central server concept. Outside Kstars you need something like the INDI starter which is sadly not maintained by as you call it the "INDI  management" or use the command line INDI server. If you dive into the INDI communication there is an awful often unnecessary amount of communication ongoing.  That does not matter for the user. He only want´s easy to install, to configure and to operate software (without IT knowledge) to control his astro-equipment. And it should work for the whole lifespan of his expensive equipment.

 

Long term support. One practical example. I have an old classic QHY5 camera. It doesn´t work with INDI anymore because QHY decided to remove the drivers from their package which is bundeled in INDI.  But for ASCOM, I can still use the old standalone drivers from 2011, kept safely.

 

Han

First off, this is not an INDI is better than ASCOM debate.  The INDI driver model itself is unbelievably ill suited to running under Windows.  If this issue were solved then INDI would only be a very, very, marginal player under windows because it would be trying to displace a well entrenched competitor called ASCOM.  It is the mirror image of the cross platform Alpaca issue.

 

This thread started by asking about Alpaca and MacOS.  There is a huge gulf between the creation of an enabling technology (Alpaca) and it's successful adoption, especially in the face of a strongly entrenched and well supported competitor (INDI).  As of today, there are zero Alpaca drivers for Linux or MacOS, outside of hobby projects. 

 

With regards to the points you make:

 

1) - Please point me to the source for the Losmandy Gemini Driver and the new ATIK QSI drivers for ASCOM (Which are terrible - but that's a different story).  Like I said, the Framework is OSS, but little else is.  I would love to figure out why the ATIK QSI drivers are non-functional on any of the three systems I tried them on.  And I'm far from the only person with issues with them.

 

2) - Because I was having issues with the driver and wanted to debug it.  Turned out to not be the driver, but that's besides the point. See point 1 and the ATIK QSI drivers, which are very much driver issues.

 

3) - Except every driver today is highly reliant on COM.  Moving to Alpaca is not too hard from where they are.  Getting the driver to run under Linux is a much more significant step.  Keeping COM backwards compatibility (a stated goal) along with going true cross platform is going to complicate things.  Like I said, Alpaca will be a success under windows.  I doubt that will carry over to Linux. Again, this tread started by asking about Alpaca and MacOS.

 

5) Management differs hugely.  ASCOM only covers the ASCOM framework only,  INDI covers everything.  See point 1.  This severely impacts the ability of the broader community to help with the migration to support Linux.  To the point that I believe that it won't happen.  The current maintainers of the ASCOM drivers are either going to have to up their workload significantly to support Linux and MacOS, or they will need to find help.  The easiest way to find help is adopt a very open model, like INDI.

 

As for your QHY example - the INDI source is still available.  You will just have to go back through the third party git repo and become a maintainer.  Fork and build to your hearts content.  That leaves you open to take over maintenance of the code.  The fact that you have this option shows the INDI governance model is superior.  I just checked and the source for indi-qhy is there going back to 2012.  If it worked between 2012 and now then you have the ability to make it work today.

 

That QHY have also withdrawn the windows drivers (by your own words) tells me you don't really "own" the camera.  You lease it from QHY until they remove the drivers.  If you obtain ASCOM drivers by any route other than from QHY you could be in breach of copyright and licensing law, not that they would ever press the issue.  Also, as you say, the ASCOM framework is there as OSS, so you could write you own driver as you state in point 1.

 

Cherry picking examples to make a point based on personal anecdote is rarely productive.  I'm looking at the systematic issues that prevent adoption and success of new approaches to problems that I have seen time and time again.

 

Like I said, I may be wrong.  Time will tell.

 

J.
 


Edited by nebulasaurus, 31 August 2020 - 09:42 PM.

  • rpineau and James Bates like this

#14 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 473
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 02 September 2020 - 02:00 AM


You lease it from QHY until they remove the drivers.

??? There is no lease contract in place. All QHY5 users clearly own their QHY5 and their personal copy of the drivers. They can do what do want with it, sell, modify, give away. They only don't have the copyright.  The supplier can only stop providing backup copies of the driver, risking their good name.

 

 

 

examples to make a point based on personal anecdote is rarely productive

I beg to differ.  Anecdotes are very helpful bringing the message across. The message is that providing only the latest and fanciest INDI drivers is not in all cases good. If in the bundled firmware legacy models are abandoned it can brake an working system. Fixing it by downloading an old code, compiling and installing is maybe doable for IT people but not for the average customer. The customer is better served with an installable legacy driver.



#15 esp

esp

    Lift Off

  • -----
  • Posts: 23
  • Joined: 22 Dec 2016
  • Loc: NYC and VT

Posted 02 September 2020 - 10:29 AM

I have no relationship with ASCOM other than that I think they are doing great work with Alpaca. I wrote this because it makes me sad to see so many people not understanding what Alpaca is and why it is awesome. I believe Alpaca represents the best in class attempt at remote observatory control, and sets the framework for a future with much richer control surfaces than we have now

 

I have not found a good description of what Alpaca is, how it is different from ASCOM, in what ways it breaks free from Windows, or why it is really important for the future of astrophotography. So I wrote this.

 

At a very high level, Alpaca is about decoupling control software from astrophotography hardware. It creates a standard protocol for control software to talk to astrophotography hardware over industry standard technologies that are platform independent and work over a network. If you don’t want to Remote Desktop / VNC / Team Viewer into a computer running on your mount, Alpaca is for you, and you can use this now, with just an ASCOM software upgrade. If you want a future where you can control all your astrophotography equipment from macOS inside your house, with no computer running at the mount at all, Alpaca is for you (but we are not quite there yet).

 

I think the ASCOM team was in a bind over naming. The ASCOM “brand” gives weight to Alpaca. It comes from the same world as the forerunner in astrophotography control systems. But that name brings with it confusion over dependency on Windows. Alpaca builds on the knowledge gained through ASCOM, but it is not ASCOM.

 

To explain Alpaca, I look at a world before ASCOM, what ASCOM provided when it came along, and what Alpaca now does in place of ASCOM

 

The World Before ASCOM

You have some control software that you want to use to control some hardware, your control software needs to know how to talk to that piece of hardware. If I have a different piece of control software that I also want to talk to the same piece of hardware, my software also needs to know how to do that. Two things are required to achieve this (I don’t consider the case where the control software directly interfaces with hardware, that is pretty rare).

 

1. The hardware manufacturer must write a driver that exposes control functionality for each operating system.
2. The control software developers need to update their software to speak to that driver.

 

That means that a hardware manufacturer has to write code for every operating system they want to support. It also means that the writers of your chosen control software have to support the hardware you own, by extending their software to talk to that driver.

 

This sucked for everyone. If I was using an obscure piece of tech I had to hope that my control software supported it. If I want to use software on an operating system that my hardware manufacturer did not write drivers for, I’m out of luck, even if my software developer is willing to extend their software.

 

ASCOM

ASCOM came along and solved this for Windows. It created a set of standard interfaces for astrophotography equipment control that, encompassed all* non device specific workflows. For example, capturing an image of a specific duration, rotating a filter wheel to a specific slot or parking a telescope mount. As long as my hardware manufacturer supplies an ASCOM driver, my software developer only needs to support communicating with ASCOM and not individual drivers and their software will work with any device that has an ASCOM driver. In this sense, ASCOM is known as middleware. It sits in the middle of two sides of a control system and acts as a mediator so that as long as both sides can speak to the mediator, they can speak to each other (through that mediator, not directly). This solves the many to many problem (many different pieces of hardware x many pieces of software = lots of work), and was a huge boon for astrophotographers because suddenly you could swap out an old camera for a new one and as long as there was an ASCOM driver, the existing control software would pretty much just work (Reality is, of course, more complex, but that’s the theory).

 

This is great. Except it emerged in an era where Windows was strongly dominant, and so was only ever implemented for Windows. It could have been similarly implemented on other operating systems, there is no technical reason why not. Other OSs would need different drivers anyway, and they could have been created “ASCOMLinux” compliant, for example. But that never happened. So we were stuck with ASCOM on windows and not much else otherwise until fairly recently. INDI and others have made progress on Linux, etc, but take a fundamentally different approach to distributed control.

 

The Future with Alpaca

Today we have new paradigms in software engineering. Windows is no longer dominant. The internet is (or more specific, TCP/IP and HTTP are) ubiquitous. But the fundamental problem of needing middleware still exists. It’s a good software engineering pattern, because it solves the many-to-many problem. I still don’t want to wait on my software developer to update their app to support my new camera.

 

So this middleware concept is really important, and Alpaca tries to imagine what middleware in 2020 looks like.

 

There are a few key insights about what astrophotographers want that lead to Alpaca.

 

1. Remote observatory control, be that from indoors or across the world.
2. Greater choice in what operating systems we use.
3. Easier system set up.
4. Not to be reliant on control system software developers updating their software to support new hardware. Likewise software developers don’t want to have to support every piece of hardware directly.

 

This requires a many-to-many solution (hardware to control software), that isn’t reliant on any specific operating system, that is easy to use across a network, ideally that just works.

 

Alpaca takes all the great work on standardization done in the ASCOM project, specifically the work they did in generating a nomenclature of astrophotography control systems, and extends it to meet these criteria for 2020.

 

Whereas ASCOM provided the middleware on Windows between hardware drivers and control software running on the same machine, Alpaca defines a middleware protocol (or an API) between control software and hardware interfaces running on any machine on a network. Drivers and a windows machine are not strictly necessary any more, though in practice I expect they will be around for a while. Alpaca is setting the standard for the next 10 - 20 years and change like this can be slow.

 

In Alpaca all that is defined is that standardized interface that allows software developers to instruct a piece of hardware to take a specific action, e.g. for a camera to take a frame, or a filter wheel to rotate to a specific slot, etc. This standard interface is not platform dependent. It’s just a language and communications protocol specification. It operates using web technologies (TCP/IP, HTTP, REST, JSON) that are supported on every platform, in every programming language.

 

It specifies that devices should be exposed through web server endpoints, with actions enacted by control software calling those endpoints with specific parameters, as specified by the Alpaca API. This uses industry standard technology. Web Servers accessed over TCP/IP for network level communication, REST over HTTP for calling a specific action, and JSON for the response value. This is a paradigm used by the vast majority of web connected software out there.

 

These endpoints can be written in any language and run on any hardware (including directly on embedded control chips in astrophotography hardware) and are incredibly easy to build. The industry standard nature of these technologies means that there are extensive tool kits and documentation for building them.

 

The control software doesn’t care where the endpoint is running, it could be on the local machine, it could be on another machine on the local network, it could be across the world connected to my network via a VPN or other means. It also doesn’t care what software or operating system that end point is running. As long as that end point is coded to the same specifications that the control software is, they can talk. That specification is Alpaca.

 

On a control software side, this now means that anyone can update or write software in any language, on any operating system and have access to the same standardized hardware control that previously was available only to Windows users. Software can be written with direct support for Alpaca and there will be no need for an ASCOM installation on the control software system. I do not believe that any control software exists that natively supports Alpaca today, but everything is in place for that. No one has implemented this yet AFAIK.

 

So what are these endpoints Alpaca compliant control software can talk to and why don’t you need drivers any more? Well, they can be anything that can be coded to the Alpaca specifications, specifically that they operate as an HTTP Service, that speaks the Alpaca REST protocol.

 

They come in three forms.

 

1. Devices that directly expose an Alpaca control endpoint over the network. These devices would be connected to a network via Wifi or wired via ethernet. Their embedded control software runs a webserver on startup that talks the Alpaca protocol. Control software that speaks Alpaca can directly control these devices with no additional hardware. Imagine a camera with just an ethernet, no more USB. Or a mount that works with any software over wifi, without needing hardware specific software vendor support. In my mind this is revolutionary, and absolutely the way forwards. Network embedded devices are huge. They don’t require any computer at the telescope. There are no drivers. They simply connect to your network directly. Of course this requires new hardware designs to implement the embedded network endpoints. I believe that this is a smart move for manufacturers, since they would no longer need to write or maintain (this is huge!) OS dependent drivers. They update their firmware as needed, but they do this already, and this firmware contains the Alpaca endpoint.

 

2. Drivers that expose an Alpaca endpoint on a computer with a physical (e.g. USB) connection to the device. This is the more traditional driver route with a twist. Hardware manufacturers would still have to write drivers for different observatory side computer operating systems, but those drivers would all expose Alpaca network endpoints, to which any Alpaca compliant control software could connect over the network. This can be done today by a hardware manufacturer with no hardware changes. Of course it’s not as neat as the first format, because it still requires OS dependent software and a computer at the mount.

 

3. The existing ASCOM windows framework can actually expose Alpaca interfaces for all devices physically connected to the machine running ASCOM. Existing installations can be Alpaca compliant with an ASCOM software update and nothing else. This means that control software that speaks Alpaca, running on any OS, on any device, can now control equipment connected to a plain old ASCOM set up at the observatory. Double bonus, any Windows based control software that speaks ASCOM can already control any device that speaks Alpaca over the network (With an upgrade to the latest ASCOM platform). No more Remote Desktop or Team Viewer. Just run your control software on any machine and connect to your devices over Alpaca on the network.

 

I’m personally very excited for devices that expose alpaca over an embedded network interface. These are very stable, don’t require a computer at the mount, and enable me to completely break free from specific OS requirements.

 

You should be excited too. This will make your life easier. And there is a really neat slow upgrade path while hardware manufacturers build these embedded systems. Running an existing ASCOM system on Windows at the mount you can move to Alpaca supported control software by upgrading ASCOM on both ends. This works today. As new control software becomes available you can remove ASCOM from the control end and simply rely on Alpaca conformity. You could even move to control software on macOS or Linux (or an iPad app, or a web browser, etc, etc, etc) if it supports Alpaca. As hardware supports it you can slowly reduce dependency on a computer at the mount by connected network embedded devices directly to your network.



#16 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 192
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 02 September 2020 - 12:53 PM

@esp I was about to reply to this thread but you have done an excellent job. You hit on all of the points and confusions that were brought up in this discussion. I totally understand why folks are confused. It's a classic chicken and egg problem. The same thing happened back in the early 2000s with ASCOM on Windows. It took 5 years for things to start moving. I've been on a mission to help in this regard but it's not easy. I've tried to explain several times on video and yet the same confusions misconceptions persist, usually because people are coming from INDI and applying those concepts. Maybe they are not looking to the manufacturers to supply their devices with Alpaca compatibility out of the box. This is what must happen, not third party open source drivers (which fork of the foobar driver are you using? Maybe you should try bobolink's new fork, etc. Unsupportable.). Hopefully your excellent explanation will do a better job than I have.

 

Thank you!

 

Recently, Simon Tang of Woodland Hills Camera and Telescope invited me to give a non-technical briefing, but more importantly, they followed up with Optec Instruments, who are pioneering cross-platform instruments using Alpaca, to put on a live demo. Here is that live demo video, and below that, the non-technical briefing I gave before that. Thank you Simon Tang of Woodland Hills Camera and Telescope.

 

Live Alpaca Demo with Optec Instruments  <=== At least look at this

 

ASCOM and Alpaca Non Technical Briefing

 

And again, devices really need to come with universal connectivity. Many  (if not most) devices now come from the manufacturer with the universal Windows ASCOM connectivity. There are still a few mounts and many cameras that do not. For those latecomers, one can hope they will start with Alpaca, and automatically gain the connectivity to the Windows ASCOM world without needing to build a separate Windows ASCOM interface/driver. 


Edited by Bob Denny, 02 September 2020 - 01:08 PM.

  • han.k likes this

#17 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 192
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 02 September 2020 - 06:53 PM

It was pointed out to me today that @esp's post might be a bit confusing with regard to "middleware".  Alpaca is not middleware in  the normal IT terminology sense. It is a network protocol. There is no need to install any sort of "Platform" on Linux, MacOS, or Windows for that matter. The device (or its driver) communicates with the client (user program) over a network connection. Alpaca is the universal standard for the interchange of commands and data over that network connection. Note that the network connection can be between a standalone device (WiFi mount e.g.) and a program on a cell phone, tablet, notebook, etc. Or it can be between a driver (which would come from the device maker) and a program on the same machine. The "network connection" is fine between programs on the same system

 

It is difficult to get this concept across and @esp did a great job. I just wanted to clarify the usage of "middleware" as separate from protocol and interface. On Windows there is middleware that bridges the legacy ASCOM world to the Alpaca world, but that's all it does.

 

You might benefit from my non-technical briefing video where I made my nth attempt at making this clear. Also as @esp explains, this isn't going to take off until the device makers use Alpaca as their connection. If you like the idea let them know you do. That's why I referred to the real world demo video above.

 

If there are other confusions I will try to address them, though I may refer you to existing info on the ASCOM Initiative Web Site or the briefing video (with a "start time" so you can jump to the answer).


Edited by Bob Denny, 02 September 2020 - 06:53 PM.


#18 esp

esp

    Lift Off

  • -----
  • Posts: 23
  • Joined: 22 Dec 2016
  • Loc: NYC and VT

Posted 03 September 2020 - 11:52 AM

@Bob Denny, yes, I think you are right, middleware is potentially confusing here. I wanted to draw a solid line from pre ASCOM through Alpaca and to do that I bend the definition of middleware slightly. Alpaca is not middleware, it's a protocol and is implemented on top of standard web middleware already on every platform (TCP/IP, HTTP Servers, etc). I think it's pretty key that it shifts the onous of providing the middleware technology to the operating system (which they all already provide, because standards rule!), and specifies how it should be used. No more middleware installation or maintainence!

I tried to edit my post to provide clarity, but I think I missed the window.

#19 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 192
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 07 September 2020 - 06:15 PM

I'm sorry, I even edited the above post with the link to the Optec Live Demo. I still got it wrong. Now I can no longer fix it. So here is the link to the video I wanted people to look at first:

 

Live Alpaca Demo with Optec Instruments  <=== At least look at this




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics