ASCOM ALPACA Raspberry Pi

[oyabuns]

Hey,

 

I have a question, did anyone here have luck installing ASCOM alpaca Remote Server on a Raspberry Pi 4?
Or is it like I suspected as in the below image not possible, unless it's a windows machine?

 

[MarkAR]

I wouldn't bother, ASCOM is Windows. You need to look at Astroberry or INDI.

[AngryDonkey]

28 minutes ago, MarkAR said:

I wouldn't bother, ASCOM is Windows. You need to look at Astroberry or INDI.

This is not quite correct. ASCOM Alpaca does not require Windows nor does it need the original ASCOM framework to work. As a protocol I think it has a lot of potential, there is however very little support for it at present in terms of drivers and clients. Hopefully this will change...

[oyabuns]

Yes, it was said that ASCOM Alpaca wouldn't be OS dependent. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work.
ASCOM Alpaca client might work on non Windows OS, haven't tested that yet.
Looking forward for the server side also to be available on other OS.

 

@MarkAR I'll take a look into those, thanks for suggesting!

Edited October 8, 2020 by oyabuns
Spelling

[AngryDonkey]

8 hours ago, oyabuns said:

Yes, it was said that ASCOM Alpaca wouldn't be OS dependent. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work.

You only need the 'remote server'/'ASCOM remote' part if you want to use an existing Windows client (running on normal ASCOM) to connect to an Alpaca device driver (over the Alpaca API) or if you want an Alpaca client to connect to a regular ASCOM driver on a Windows machine. So it really only comes into play if you want to include some component running under the 'old style' ASCOM framework.

I think the arrows in the diagram are a bit misleading, you can remove the entire left hand side of the diagram and it will still work i.e. you could have an Alpaca client running on Linux connect to an Alpaca driver running on the Raspberry Pi. Not sure what the rules are on posting links to other forums but if you look on cloudy nights and search for a recent thread called 'Raspberry Pi and Alpaca' there is a guy who has just done that i.e. developed a Linux client and RPi drivers via the Alpaca API. I don't think it is released yet but it shows what can be done.

The problem at the moment of course is that there are very few (if any) Alpaca drivers and clients available at the moment. It's a bit of a chicken and egg situation and time will tell if it finds any traction... As has been said above, if you need something now (and you don't want to write your own drivers etc.) then its better to stick with the other suggestions. I also find the INDIGO framework to work quite well.

Edited October 9, 2020 by AngryDonkey

[stash_old]

CCDCIEL allows the use of ASCOM/Alpaca and Indi connections at the same time.  CCDCIEL can and does run on Linux ,MacOS and Windows.

But as Angrydonkey says there are very very few Alpaca drivers so unless you run CCDCIEL on Linux/MacOS and use Ascom Remote on Windows to pick up any existing "Normal" Ascom driver there is not a lot you can do with it at the moment. You can also run CCDCIEL on Windows and use both Ascom locally and remote Indi server.

[skybadger]

Indeed, alpaca is a rest web api specification that implements an interface to ascom, where the clients are typically windows ascom clients. However , if you want to write to an alpaca rest service hosted  on your Pi device, feel free, it will work seamlessly. The same if you want the client end to be on your Pi and the device interface on anything else. I have a family of alpaca compliant  devices coded at github/sky badger if you want to take a look. They are accessed from the ascom remote client running on the Windows server but also by many other non windows devices and are hosted on  esp2866 Wi-Fi devices. 

[JonCarleton]

The real question should be, "Can an ASCOM server talk to an INDI server.  They are both TCP/IP XML message platforms.  Both ASCOM and INDI have provisions for distributed remote servers with one primary server.  I don't know the answer,  because I don't do Windows.  But it seems to me that if they don't do that yet, they should.  It should go both ways.  A primary INDI server should be able to talk to secondary ASCOM or INDI servers and likewise a primary ASCOM server should be able to talk to secondary INDI or ASCOM servers.  TCP/IP XML is common between both platforms.

The only reasons it may not be are that 1) Nobody thought of it yet, or 2) The XML specifications for the drivers have become too differentiated, or 3) The port for the two server types is different.  None of which are particularly difficult problems to solve with a bit of code   Even if things are completely mismatched, a simple socket program with a conversion between driver specifications could make it happen.

Since I don't see it happening, and since it makes sense to have a Pi on a telescope running an INDI server with perhaps a primary ASCOM server connecting to the human-interfacing programs, there has to be a catch I'm not seeing.  There was a project called wINDI that was reported to be an ASCOM->INDI bridge, but I don't know the status of it now.

 

Edited October 9, 2020 by JonCarleton

[MCinAZ]

15 hours ago, JonCarleton said:

The real question should be, "Can an ASCOM server talk to an INDI server.

To me, the questions are, "Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?" If separate ASCOM and Alpaca drivers are required for Windows vs. non-Windows platforms, I don't foresee many manufacturers putting money into development of the latter.

I watched a YouTube presentation about Alpaca given by Bob Denny a few months ago. It looks interesting, but it wasn't clear to me if Alpaca drivers work in the Windows environment. If not, I doubt that there's much future for it -- hardware suppliers will continue to cater to the ASCOM market and for those of us who don't live in Windows land, there's no obvious benefit over INDI.

[dunc]

I got this working with Alpaca Server on my RPi4b running Raspbian (set up initially with AstroPi3) so I could use the Pi on my scope and connect to it from Windows i.e. my laptop, using APT, PHD2. I managed to get it working but it proved a bit flakey so I've gone back to running the scope and capture on the RPi  and VNC into it. The trouble with using INDI or ALPACA servers is you then have two points of failure, the server and the client. I prefer it all to run on the same machine, whether laptop or RPi so if it doesn't work I have can simply replace with a laptop or the pi and continue imaging. 

[AngryDonkey]

16 hours ago, JonCarleton said:

Can an ASCOM server talk to an INDI server.

Although the comms protocols might be similar, the fundamental philosophies behind each framework are quite different which will reduce compatibility e.g. ASCOM implements a fairly strict interface whereas INDI is a lot more free form. Also the way messages flow push/poll is different. I'm sure it could be done somehow (the now retired wIndi server did expose ASCOM devices to INDI I believe) but I'm not sure the benefits would outweigh the potential issues of working across two frameworks.

1 hour ago, MCinAZ said:

"Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?"

Drivers need to be written for a specific system (Windows/Linux) so the Vendor will still need to write two drivers if targeting both Windows and Linux. For Windows however the 'normal' ASCOM driver can be exposed over Alpaca so it doesn't need a separate 'Windows Alpaca' driver. Not sure if Vendors will buy into this but there is certainly a market for RPi based devices at the scope end.

[JonCarleton]

I need to look into Alpaca.  I really am not familiar enough with the project to speak with any authority on it.  Then too, I'm perfectly happy with INDI, and "I don't do Windows."

Data conversion for dissimilar enterprise systems was my area before I retired, so I know it could be done.  The real question is then, should it?  The notion of an additional point of potential failure is certainly valid.  I do see the value of running a Windows desktop with a Pi running the scope, especially when there is any real distance between the two.  In my case, I am basically doing the same thing under Linux....Linux desktop, Pi/Linux at the scope, so the conversion issue does not come into play.

 

[Martin Meredith]

I'm potentially interested in ALPACA but still trying to understand what components are needed to make this work on a completely Windows-free setup.

Let's say I want to control a filterwheel. I write a client program, look up the JSON semantics for this device, and send the necessary JSON to an ALPACA server. So far so good. But then what?

In the Windows case it is pretty clear that it converts the JSON into something ASCOM-compliant and sends the request to the device. End of story. I can see how this would work easily enough, and I can see that controlling ASCOM-compliant devices hooked up to a Windows box from any other device is pretty trivial. And it is trivial because all the drivers already exist, as does the ALPACA-ASCOM server. 

But this isn't my case. As I see it, for a non-Windows setup much of what is needed to get this to work (ALPACA server + drivers) isn't currently available and I'm not even clear whether it is being developed. It would be wonderful to have a truly OS-independent way to access devices, but is it going to happen?

Am I missing something?

Martin

Edited October 15, 2020 by Martin Meredith

[callump]

People might find this YouTube video of Bob Denny (one of the Ascom/Alpaca driving forces) useful - especially if you know nothing about Ascom or Alpaca.

https://www.youtube.com/watch?v=Qd1ZsJ_Q1XY

Its a while since I watched it, but I think the essence is that Alpaca is not really there yet... And whether it ever will be is moot - it may get somewhere, but will never have complete cross platform support.

At the moment I think INDI is the only complete cross platform that actually works. INDIGO is good if you want to use Cloudmakers apps, and it also falls back to INDI too but there's not much in the the way of third party clients.

Callum

 

Edited October 15, 2020 by callump

[stash_old]

1 minute ago, callump said:

INDI is the only complete cross platform that actually works.

Indi (and we are really talking Indilib here) is NOT a cross platform - there is no Indiserver running on Windows. The one created by Indigo authors is not supported any more. The only mainstream program that runs on any platform (Windows/Linux/Apple) is CDC and CCDCIEL but they are NOT Indiserver (i.e. a server) just have the client capabilities to talk to Ascom (via Ascom remote when not on Windows),Native Alpaca or Indi and sometimes both at the same time when run from Windows.

Indi and Ascom are just a standards for messages formats, message handling  and standardised driver functionality.

You could (but would you really even bother) write an Indi/Ascom two way converter - not forgetting the overhead.

Robert Brown showed the way for Ascom ,IMHO, with his Focuser that has a TCP/IP interface in his Ascom driver. So too Sky watcher - there App/Ascom Driver enables you to run the App/Ascom Driver on another Windows "box" (with Ascom loaded of course).

For ALL Ascom drivers that use "COM" you have been able to have a Ascom remote device on any OS using "COM" to Network modules such as SER2NET (LINUX) and the Virtual Com emulators / Com port redirectors (some free some not). Using this method ASCOM is totally unaware and the "only" problem is that of timing.

I guess ,unlike Indi, Ascom is stuck with waiting for hardware manufacturer's  producing native drivers for Alpaca on other O/S . Thats where Indi is strongest but still has its limitations as stated - lack of "true" Indiserver on Windows.

Thats my take -  no doubt others will have there POV's

 

[callump]

2 hours ago, stash_old said:

Indi (and we are really talking Indilib here) is NOT a cross platform - there is no Indiserver running on Windows.

Sorry, yes you are right (though I am sure when I last looked for one there was - but that may be several years ago).

I guess more accurate to say client neutral.

I expect  most INDI users use some sort of appliance on the telescope, and whatever client platform of preference. 
Alpaca will no doubt provide a practical similar solution some time in the future...

Callum