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.

Read More...

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:
github.com/rlancaste/kstars-on-osx-craft .
But note that this builds INDI in a craft directory not /usr/local

The scripts that we build INDI in homebrew with are here:
github.com/jamiesmith/kstars-on-osx
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.

Read More...

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.

Your thoughts?

Read More...

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?

Read More...

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

Read More...

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.

Read More...

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.

Read More...

I think III might be supported. Check this bit of the code:

github.com/indilib/indi/blob/master/3rdp...di-dsi/DsiProIII.cpp

Read More...

Here is my serial port script

github.com/rlancaste/AstroPi3/blob/master/udevRuleScript.sh

Read More...

Serial port assistant is a feature specific to stellar mate.

My astropi3 script installs a script with a related functionality.

But I’m not sure about astroberry

Read More...