My guess would be that those who are coming from a linux environment would consider a homebrew recipe to be simplest. And those who are coming from a mac os x environment and have never seen homebrew before would find the method i have been distributing kstars ( in an app build with craft and then distributed in a dmg that they just have to drag and drop to their system to install) to be the simplest.
With the old OS X build script that we developed back in 2016-2018, I built using a Mac OS X 10.11 El Capitan computer so that the binaries would be compatible with all subsequent systems. When QT ended support for anything less than 10.12, I had to speed up the work that I was already doing on craft so that we could get a completely craft-built kstars and INDI. The issue was that my build computer could not be updated to 10.12 and my new MacBook is running Mojave. Homebrew does NOT support building on a newer system and running the binaries on older systems. But craft can support that using the macosx-version-min build flag you mentioned. So far that mostly seems to be working fine. Though we might be having an issue with one of the binaries associated with either python or astrometry.net, but I'm looking into that. INDI has been working perfectly using craft.
My build scripts do not require a complete Xcode installation. They also can run automatically on your system.
If you want to try the craft one, it is here:
But note that this builds INDI in a craft directory not /usr/local
The scripts that we build INDI in homebrew with are here:
This could easily be modified so that it just builds INDI if desired.
But note that I haven't updated this script since I started relying solely on the craft version. I did make some changes since then. I made a better way to build the 3rd Party libraries before the 3rd Party drivers and we also have added a few more drivers. So this script does need some updating. I can easily do that if you think you would like to use homebrew to build INDI.
So yes for a start, you could take a look at one or both of my build scripts. Also I can create a new homebrew based build script for just INDI leaving out KStars if you like. That is just a matter of copying and pasting and updating a few outdated lines of code. Then we can think about where to go from there. Also, it does not have to be just one solution. There is no reason we can't maintain a homebrew recipe or build script at the same time as we have an app out there like the INDIServer app.
We can talk/think about what might be best. Here are some options:
1: Home-brew build based bash script: Already have this, but mixed in with other things. Can very easily separate it.
2: Home brew recipe: This is simple to make since we already have the script and craft recipe
3: Homebrew cask: I think that Sean Houghton made one of these
4: Craft build recipe: Already have this too, but really meant for building apps like kstars, does not install to /usr/local. This could easily be used for building a new standalone indiserver app. This is what I was working on most recently.
5: Modifying Peter's indiserver app: Would require getting his permission, also seems to mostly be written in swift. I am most used to writing cross platform in Qt now. I probably would not do this.
6: Making a new INDIServer app in QT. This is something I have been considering. It could be just like Peter's app except it could work on all the platforms potentially. It might also be nice to have it be controllable just like the INDI Web Manger. This would be great to have on Macs, as well as Linux and maybe even windows (except INDI can't run on windows except in Cygwin or Windows Subsystem for Linux and WSL does not allow usb functionality)
7: Getting INDI Web Manger working on Macs. There are some really nice things about this one, since it is all python and shouldn't be too tough. But note, this would have to be tied in with a home-brew installation of INDI.
Number 6 im my list would require the most work, but could be the most interesting. The others could mostly be done fairly easily.
The INDI server stand-alone app was developed by cloud makers/ Peter Polakovic. But of course they developed INDIGO, so they moved on from that. I spent a lot of time porting kstars a couple of years ago and as a part of that, packaged up and internal indiserver. So I have spent a lot of time fixing INDI drivers to work on OS X. After my work last summer, INDI now supports on OS X almost everything that it does on Linux. I have maintained the ability for INDI to build in home brew using a script and now in craft for use in apps like kstars .
We already have a script that can build INDI on macs using homebrew that I wrote as well as another one using craft.
A home brew formula would not be too tough. It’s very similar.
The standalone app, while developed by cloud makers is open source and is published on INDI’s repo. I have no idea if it is up to date. We could ask Peter if we can do something with it?
My recommendation would be to connect it with usb rather than Ethernet. I had a friend who tried the Ethernet route and was having trouble figuring it out, but usb worked right away so he just uses that . For me, I don’t have these options, I have to use serial since I have an older Gemini
Yes that is correct. I worked very hard last year to get it to do this. You are correct that it was disabled for awhile and that made me sad until it got restored because it is very important for monitoring images when you are using a raspberry pi headless so you can see what is going on and not have to open VNC.
My guide camera is not connected to INDI either. The goal is to be able to monitor the guide star without having to have PHD2 or VNC open with any camera, not just INDI cameras. So yes you should still be able to get a star profile image.
Again the star profile image is not an external guide frame. Loading external guide frames is bandwidth intensive, the images are really big. Loading the star profile image is not bandwidth intensive, the star profile image is something like 20 pixels across and not only that, it is transmitted in base64 as text so it is very small.
So I would say it is definitely not unnecessary. I run my PHD2 on a raspberry pi where constantly viewing the screen of the pi over vnc would be an extra use of bandwidth. I want to be able to monitor the star profile image to make sure that guiding is proceeding well, but cannot run VNC.
Getting the star profile image from PHD2 is actually very nice because it is a very small data transfer being a small amount of text transferred in base64 compared to the entire external guide frame being transmitted over wifi. So this is not the same as the option "receive external guide frames" Also note that receiving external guide frames only works with INDI based cameras. If your camera is directly connected to PHD2 and not connected with INDI, then you could not receive the guide frames.
I actually spent a lot of time last year getting PHD2 to work well with KStars/Ekos and I spent a lot of time also getting the Star profile image PHD2 transmits to display in the guide module. My camera is connected directly to PHD2 and not to INDI, for speed reasons. So I was a bit dismayed when somebody tied the option for displaying the star profile image to the option for receiving external guide frames. I don't want to get external guide frames, they are very large. I do want the small star profile image so that I can monitor guiding. I don't want to use VNC constantly to monitor it.
A separate option could be added to disable the star profile image, but that option is not "receive external guide frames" because the star profile image is definitely not the guide frames. it would need to be a separate option.
I think III might be supported. Check this bit of the code:
Here is my serial port script
Birthdate19. 07. 1980
About meEven though I am relatively young, I have been an astrophotographer for about 20 years. Within the last 5 years or so, I have taken my hobby to new heights. I built my own 10 inch telescope including grinding the mirror, bought a wide field newtonian for wider fields, acquired a much better mount to put them on (separately), got an SBIG camera for cooled CCD photos, modified a Canon XSi for better DSLR photos, and got lots of accessories. I have been doing all of my astrophotography with a Mac computer. I have basically made my own portable observatory, everything is carefully organized into boxes that I can load into my car in about 20 minutes. I take these things to dark skies and do lots of imaging at star parties.
I found out about INDI in May 2016 when Pleiades Astrophoto sent me an email about including an INDI client in their software. When I investigated further, I found out about KStars and Ekos. I quickly realized that I could install everything on a Raspberry Pi, velcro that to my scope, and use VLC to configure it from my computer using wifi. I have implemented 2 modes. The first is using the Raspberry Pi as an INDI server and using my Laptop as a wireless client using either the EKOS VM (running KStars and Ekos) or PixInsight as the client software. The second is using KStars and Ekos on the Raspberry Pi and controlling everything through VNC. Both methods have allowed me to cut the cords, move to WIFI control, and make all USB connections shorter. The second method also allows me to put my computer to sleep after I have configured the PI to do all the work. All I have to do is check in once in awhile to make sure it is working properly. So far this experiment is going very well, but I did have to work out quite a few issues along the way. I have been keeping a couple of logs of everything I have done to make it work, however, which is very useful. There are still a few problems, but the system is fully functional. It is a good thing it is summer so I have time to work on this!
The remarkable part is that you can automate your astrophotography setup, make the connection wireless, simplify the software by just running one program (KStars/Ekos) that runs it all, and you can make the connection to the devices separate from that program using INDIServer. (The last item is important because if KStars/Ekos were to crash, the devices would still be running on INDIServer.) And all of this will cost you around $100 including the Pi, a case, a 32 MB microSD card, the software, and a powered USB hub. There was a bit more work involved in setting it up and figuring it all out, but it was worth it.
I am an:
Physics and Computer Science Teacher
Delaware Astronomical Society Member
Mt. Cuba Observatory Education Associate