Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

Recommended Posts

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?

 

spacer.png

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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...

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by oyabuns
Spelling
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by AngryDonkey

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by JonCarleton

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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 by Martin Meredith

Share this post


Link to post
Share on other sites

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 by callump

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By autonm
      I made a new video - which walks through the downloading, installing and setup of AstroBerry (astronomy software running on Raspberry Pi) - and then I connect to an HEQ5 and DSLR camera. Nothing to complicated - but its the basics covered.
      There are a lot of videos out there on using AstroBerry, but not too may walkthroughs on the actual setup. Although Rp and Ab should be simple theres a lot of questions out there just on the setup.
      Hopefully the video gives people confidence on the first steps and is enough to get them going.
      https://youtu.be/Bgn3KioAAJ0
      Many Thanks - clear skies & if the video is helpful please subscribe.
    • By Sidecontrol
      Has anyone had any experience installing ASCOM driver onto the EQM 35 pros SynScan hand controller for using with PHD2?  I'm watching a tutorial using PHD2 and the chap is using ASCOM for connecting his computer to his guide camera instead of using a cable.  So the computer becomes the middle man instead of the mount.
      Thanks,
      Mark
    • By aditya10
      Hello!
      This is my first post on stargazer’s lounge, so forgive me if this is the wrong place to ask. 
      I have a SkyWatcher AZ-GTi mount (with a firmware update + eq wedge so that it can run in eq mode). I also have a Raspberry Pi 4 with INDI, KStars, and Ekos tools. I don’t have a guidescope (and my budget is extremely limited), so I was wondering if there was a way to polar align my DSLR using just the software running on the Raspberry Pi. 
      I’m also competent in Python, if that could be useful for anything. 
    • By JonCarleton
      From my other post, you all should realize 2 things about me.  1: I can't leave well-enough alone.  and 2: I like to fiddle around with things. In my last thread, I got setup with my goto telescope and managed to control it remotepy with KStars or Stellarium and even got my CCD working so I can sit inside in comfort while stargazing.....ALMOST.  I still have to run in and out to turn the focus knob.  So....
      There is a raspberry pi running the INDI server pointing the scope and managing th CCD.  I have a nice little geared motor and a HAT board that I know how to connect and control with the pi to make the motor go fast or slow, or forward and backward.  I can manage the machine work to create a connection to the focus mechanism for the motor.  What I need to know is if there is already a DIY-ish or configurable driver for INDI.  And yes, this probably is a post for INDI forum, but for some reason I can't get a login there.  So, if anyone knows or has done this, thank you in advance for any information you are able to provide.
       
    • By Andy_ZH
      Hello all,
       
      this is my first post at SGL, and it will be quite long. I am not native a English speaker, so please excuse any mistake.
       
      I have quite some plan with my telescope mount and its goto control, and I am looking for some feedback and comments. If somebody else did a similar project, please let me know. And please feel free and encouraged to make suggestions, ideas, critics, etc.
      The story in a few buzzwords: Raspberry Pi Zero → direct control of TMC2209 stepper drivers via the Pi's Uart serial interface to drive my telescope mount. I am writing a software (optionally: open source?) to control the mount. The language will NOT be C, as typically used for Microcontrollers (I know for instance OneStep)
      I am using Kotlin, which is a more advanced JVM language.
       
      I think this should be enough information to filter the readers who are interested in reading the rest of my post.
       
      Now the long and detailed story:
      My professional background: I am a physicist, and did a PhD in EE (Power Electronics). Later, I became software engineer. Besides being fascinated by Astronomy, I am a tinkerer (Reprap 3D printer, electronics, …). I did grind my first mirror (a 6'' Schiefspiegler) when I was 15 years old, and I built the cookbook CCD cameras in the 90's.
      After many years without a telescope (study time, relationship, ... ), I settled down with my family, and I started to get back to Astronomy.
      Recently, I did by a quite a massive second hand mount: the “Vixen New Atlux” from another other stargazer in Switzerland. My opinion is that the New Atlux' mechanical design is superb. It has (had...) internal wiring, the counterweight bar can be hidden in the mount for transport, good polar alignment screws, it has an excellent polar finder with a dimmable LED.
      But on the other hand the electronics: two weak servo motors in combination with the incredible Starbook 5.... Seigh... the starbook...(!) it is, well... the mount is just superb, and no more comments about the starbook game boy, which shall rest in peace at the garbage dump.
      I removed the servos and all electronics, and I put 2 stepper motors into the mount, which are coupled to the gear with a timed belt. My original plan was to put an Arduino into the mount in order to control the steppers. I have an old goto Celestron cg-5 with Starsense, and it would have been quite easy to mimic - with the Arduino as interface – the servos of the old cg-5 and translate the Starsense control signals to my New Atlux. I can write C, and there is even an open source project called OneStep, which uses a Microcontroller in a similar way as I do.
      But I don't like to write C code anymore. In the 3D printer community, people need to use real time electronics to control the printer steppers. Due to the real time requirement, C with a real time microcontroler (Arduino & similar) are the only option for 3D printers.
      Do we need real time for our telescope? No. We don't need to control a lot of Motor accelerations and high speed control. For the telescope, we need to set the Motors speed precisely, and we need to drive to any position in an accurate and controllable and slow way.
      Then, there are new stepper motor drivers available with as much as 256 microsteps. The TMC2209 stepper driver , which is very well know in the 3D printer community, is not vibrating at all. It runs just smoothly, also at very low speeds. I do drive my motor with 0.25 rpm (sideral speed). In case of a slew, I can accelerate to 1500x sideral speed, which also would allow me easily to track the ISS. Wonderful.
       
      The current status of my project is:
      The mount is equipped with the two new motors The TMC2209 drivers are connected to the Raspberry pi GPIO Interface, and I can control them via Software. Theoretically, I could attach up to 4 motors with a single Uart interface (1 wire protocol). For instance, a focuser or a filter wheel could be attached. I selected Kotlin as language. Java also would have been possible, but I think for a new project, Kotlin will lead to a much more readable code. The TMC drivers can be driven via a chip-internal clock signal. Different to what the 3D printer community is doing (they use the step / dir pins, and create every single microstep with the microcontoller), I can send a “speed” signal from the Raspi via UART to the 2209 chip, and it will execute this speed for me without any further action. The only time critical issue was that I need to precisely count the steps that the 2209 stepper drivers executed. This is done via a GPIO pin, receiving its index signal (a pulse for every 2209 fullstep). Here comes the pain with Linux (non real-time) and the Pi: For user programs, it is impossible to guarantee that every pulse from the stepper drivers will be registered. But I cannot afford to have a step count drift over time. The solution was that I wrote a Linux kernel module in C. I wrote that I don't want to write any C code. Well, a few lines for the kernel module were indeed necessary. I can live with that, having in mind that the rest will be written in Kotlin. The only task of the Kernel module is to count every registered step at the Pi's GPIO input pins. This kernel module output is then mapped to a character device file in /dev/ for every stepper. In Kernel space, it is possible to register and count interrupts without missing even any one of them. From a hardware point of view, this is indeed everything we I need. The project cost so far: 2x10€ for the stepper drivers, 2x10€ for the motors, 2x20€ for the tooth belts and pulley, 10€ Pi Zero plus some peripheral expenses: Micro SD card, USB charger, and 1200 € for the used Vixen new Atlux mount. And a lot of time.
      I have so many ideas on how to extend the ecosystem of my software, but these ideas are for the longer term (maybe years from now on):
      Multi-star alignment. The alignment should be able to be updated continuously during an observation night. With a set of stars, it should be possible to calculate the quality of the aligment points, and e.g. drop them if they are errorneous. PEC correction (should be easy on the Pi) End-Stop support The polar alignment routines of today's goto scopes are quite good. But what I would like to have is some audio-feedback when I move the alignment screws into the right direction. Possibility to pre-plan an observation night (e.g. the mount could tell you that the Jupiter moon shadow will be on Jupiter in a few minutes). Record the telescope movements during the night in order to be able to tag any picture. The TMC drivers have much more capability than what I am using currently. For instance, they could be current controlled for slews in order to set the stepper current exactly to the value that it needs without stalling. This saves a lot of energy. The TMC drivers have a feature called “Stall Guard”. This could be used instead of endstop switches (for 3D-printers, this is done frequently). Advanced options for tracking: siderial, solar, moon speed, ISS speed. Tracking in both axis (e.g. to compensate polar misalignments of atmospheric refraction) or just in right ascension. Commercial mounts do not allow much customization here. With slow slew speeds, 5V input via a USB-C cable is sufficient for the Pi + Motors. Usb-C and newer usb battery packs allow to output a higher voltage via USB. With an “USB-trigger”, the input voltage can be selected to my needs. Higher voltage allows higher slew speeds, but consumes more power. Autoguider support, or even better: simply connect a webcam via the Pi's USB connector and do the guiding on the Pi The Raspberry Pi touch screen could be used for telescope controlls Advanced German mount limits and meridian flip control (e.g. a warning about a necessary flip when driving to a specific goto target). An Android App, connected via WiFi to the Pi could be used as display alternative Language control (have a look at Mycroft, an open-source artificial intelligence). "Hey mount, please slew to the whirlpool galaxy!" Control the mount via SkySafari and Stellarium The Pi has a built in camera interface. How about an open source auto align? The Pi could look at the stars to align itself, which makes a lot of sense. I did already order a long focal length lens and monochrome camera from Arducam in order to do some experiments (the standard Pi camera has 3.5 mm focal length and is not really usable, although star imagining is possible). My first observation site is my balcony. And there, the real Starsense does not work at all. It always spin-loops on 2 alignment positions where the sky is covered by the roof – how silly is that?. This can be done better. Further, Starsense is doing only a initial alignment. It should update its position and accuracy over the time! I think I could do this better.  
      Besides all my ideas, the first and most important focus of the software will be:
      Readability (therefore my choice of Kotlin), extensibility and open source. I like to have the Maths of the internal mount model clearly visible and understandable in the software. The calculations that are done within all our goto mounts are no rocket science. I admit, I am the nerd guy who wants to go the hard way and implement this from scratch.
      I am looking for a good project name, do you have any suggestions? How about QuickStep? this is possibly too close to OneStep and would offend the creators of OneStep?
      Does anyone of you have interest in joining my plan? Doing such a project in a small group would be more encouraging then just doing it for myself. And of course later on, I would appreciate if other stargazers would update their old mounts with my software.
       
      Any comments on my project plan are welcome!
       
      Clear Skies!
      Andy
       

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.