You can run setup.sh as many time as you need. It will not hurt your existing installation.
You can either edit setup.sh or just edit the /etc/apache2/sites-enabled/allsky-indi.conf file directly. You just need to restart the apache2 service when finished.
I believe the setup.sh script comments out the Listen directives in ports.conf, so the only file you need to edit is the site.
Yes, I meant 16-bit color depth.
If you connect to RDP, I believe it normally starts a second GUI interface that is different from the one on the root console. Its easy to re-enable the GUI anyway. I believe you disable the GUI with
Just running the indiserver without the GUI is probably a good way to go.
I have had good success running indi-allsky on the Le Potato SoC. The cost of this device really does make it very attractive.
The biggest thing you can probably do is disable all of the default GUIs from starting by using multi-user mode instead of graphical mode, but that is not going to get any type of huge gains, just less memory usage.
If you use RDP, use 16-bit mode instead of 32-bit.
In Kstars, enable low resource mode for the FITS viewer.
I am the developer of indi-allsky and I wanted to get some opinions on using the "indi" name in my project.
I never really asked for any type of permission to use the indi name in my project I just used it to indicate that indi was the basis for the software. I tried to use the name in good faith and made sure there were no projects with similar names. I have no intention on selling or trying to change the license of indi-allsky.
I just want to stay in good standing with the indi team and not step on any toes. Are there any policies or guidelines for using the indi name?
I think everyone wants this feature, unfortunately, I do not think it is possible to implement.
I believe the merdian flip is a go-to function of the mount, not EKOS. EKOS just issues a slew command and the mount decides if it is time to perform a meridian flip. The reason the setting exists in EKOS is some mounts will not perform a merdian flip until the object is a few degrees past meridian.
This update was really more of an experiment for me to see if I could acquire images from other sources. The time lapse part of the code does not particularly care where the data comes from.
It was never my intention to push for a new driver in indi. I am not that subtle. Although, I can see how my post could be perceived that way.
Recently, I have been following the Allsky Camera group on facebook and there has been a lot of activity and interest in the new Waveshare IMX378-190 camera that has an integrated lens. It is a compelling product at $50 and is perfect for all sky cameras, although I think the view might be a bit too wide.
You may want to forgo using Raspian 10 and just use the libcamera support on Raspian 11 64-bit instead.
No downsides other than you have to build indi even though you do not use it. The libcamera support is transparent to the user.
I am getting the same error with my Rpi3. I need to go check on my Rpi4, maybe I am running an older version of indi.
I did do one thing that I thought was creative, but is really only useful in my use case. For the libcamera integration, indi-allsky thinks it is talking to a normal indiserver.
indi-allsky uses the pyindi-client to interact with INDI. Therefore, I had to write a fake pyindi-client class to emulate the behavior of this module. indi-allsky still calls functions like connectServer(), but they do not do anything.
I would love to be able to help, but for this iteration, I just settled on using the libcamera-still command to generate images instead of using the C or Python bindings. I was very interested in using the Python bindings, but the Python module is not yet installable via the normal pythonic way (pip/virtualenv).
I had to deal with the libcamera-still command generating DNG files for raw data and I just hard coded the bayer pattern in my code for now.