INDI client/server support


I have a PDF file describing ASCOM Web but I cannot attach it. I will try and find the URL.
I connect to my Stick/Nuc with Microsoft Remote Desktop from either a iMac or iPad. It is possible to store images anywhere you like using redirection, on either host or client. I choose to store locally on a USB3 drive for speed but then, after capture, I transfer them over to my iMac drive whilst still in MRD.


I put the file in a dropbox folder


This looks super interesting, but it must still be in its infancy? Other than this paper which you kindly provided, I can find zero other references to it or any implementation anywhere?

I like the idea of communication over HTTP using JSON as opposed to the relatively noisy XML employed by INDI.

The only other hit I found to ASCOM over the network was while researching Prism a many months ago. Looks like there’s some kind of client/server wrapper:

Shows potential but also trying to overcome an inherent gap in ASCOM’s functionality (that maybe this ASCOM Web initiative will address).


I found a thread on the ascom-talk yahoo forum.


I think the big plus is here that the INDI server driving the devices is platform independent and using IP rather than USB to communicate removing the need for long USB leads. The only downside using INDI over ASCOM is that there are not as many LINUX drivers as there are Windows.

The EKOS/KSTARS applications do a lot of what SGPRO does. There are a lot of features that would make me use SGPRO over these.


Unfortunately the INDI driver support is not mature with all devices. I got two QHY cameras and the driver is not able to
support both connected to an RPI. Only one of them is working (both are recognized by the driver). Quite useless as one is the main imager and the second the guider. No problem with an ASCOM interface. I am playing around with INDI on a RPI device because i like the idea of remote control and getting rid of the dangling cables. Just the power cable is remaining.
Micro USB hub, focus controller and dew heater controller are mounted to the saddle plate with short cables to the devices.
Faster setup, and no risk of cables slung around the mount while in the warmth of your living room. For now i stay with SGP
on my laptop positioned near the scope while remoting with teamviewer.


So I totally agree with garthb on this one. Since I started astrophotography in 2015, ASCOM was the only choice I saw and I jumped to a network solution that same year (same reasons as garthb)… then I noticed how bad ASCOM itself was in doing that. If I want to control it via my Raspberry I need something like USB-to-IP running on it so ASCOM thinks it’s connected locally (requires a super stable connection). The only other way is to run Windows on a bigger, way more expensive, computer at the telescope and then remote desktop into it… personally I found it all a bit of a messy solution. More overhead on the network and just not as nice and stable as a dedicated client-server solution. Bonus is that I can use Linux on the Raspberry, which is also made for networking from the ground up, rock solid and never restarts for updates or so. :wink: Other bonuses are that the drivers are open-source, or at least most of them and you can write your own, granted that may be a stretch for most, but at least I can do it. With ASCOM I was having to go with drivers the companies made and some were just buggy, I almost had to buy another device just to get a better driver which I thought was a bit nuts. So I switched to INDI. Yes it was still a bit buggy back then but development is going incredibly fast, I would say that now everything is pretty stable and I’m making mosaic schedules without much effort. I still love SGP itself so to have that for INDI would be amazing.


We have a handful of devices supported in INDI (not yet released). I think it’s a nice platform and I like the interaction with the hardware. I really only have 2 concerns:

  1. Image download is painfully slow. Testing with my ASI1600 on a Wifi connected PI the download is like 40 seconds. Ethernet speeds this up but it’s still a significant amount of time.
  2. Connectivity over wifi or even wired Ethernet can be spotty. It will be interesting to see how breaks in connectivity hold up.

Overall I really like how INDI pushes data to the client rather than requiring polling. This way we can just be reactive and handle data when it comes in vs asking if it’s ready.



That already sounds very exciting Jared, thanks for looking into it! My experience with connectivity has been Wifi and Ethernet. Wifi caused all sorts of problems indeed, maybe simply due to the brick and steel enforced walls of my house, however… connection was never lost, it was the spotty data that cause drivers to fail it seems. Since I switched to Ethernet everything has been a dream in operation. A download of my DSLR is a bit slow still, but that might also just be the DLSR itself and the USB2 connection of the Pi. If you think it really is the driver, it may be worth checking in with Jasem of the Indi project, he’s extremely helpful.


So you mentioned INDI may be supported in this upcoming version 3.0. Is that still in the planning? I had a wonderful SGP session again last night, but would love to be able to ditch my usb-over-IP server thingy. :slight_smile:



I would be nice, if SGPro would act as an INDI server as well. This would help to access data from SGPro without polling it from the REST API.

Just as an idea.



Yes, but probably not at the same time that we release 3.0. It will likely be a follow up in a minor version.

Hm, I’ll have to give some thought to this. At first glance I think the answer is “No” but I’ll have to think about it a little more. We plan to revamp our API in the near-ish future for some other work as well. But I can’t immediately see a reason to act as an INDI server when you could just connect to the INDI server that SGP is connecting to and get the same info.




many thanks for the quick reply. If you plan to revise your API, please let my know, because I did some work using SGPro as the frontend for automatic modeling for 10micron mounts (MountWizzard).
That’s the reason also asking for being as server as well, because you concentrate a lot of devices in SGPro. To be able to use them would make a lot of sense.




Will do! Although we would likely create and version a new endpoint and leave the existing implementation as is. So that would continue to work but would lack the functionality of the newer stuff.



Well that’s just really awesome Jared. Consider this another paid upgrade! :wink:


Any news on the this? I just got my raspberry PI working and I had some trails with Ekos, but I truly prefer running my sequences in SGP.