I deleted all build folders and it successfully built... it took 2.5 hours in a RaspberryPi 4 with 8Gb, using an SSD.

Thank you!

Read More...

Unfortunately, I am stuck again, since I get an error building one of the 3rd-parties module, the one on astroasis.
I think the root cause is that I first created the build for version 3.6.4 and then I updated the scripts and the git repositories, and to some extent the cmake configuration is not properly updated on my build folder. I am not an expert on cmake, so I don't know how to solve it.
Any advice on how to re-run the initial configuration?
I think that if I delete all the build folders and start from scratch it will work, but I would like to avoid it, since it takes a long time to build everything.

Read More...

Hi!

The scripts are really awesome! They keep building on every new Kstars version! Thank you very much.

I found that it would be great to set the ROOTDIR in a custom location, so I introduced a small improvement on the scripts. Unfortunately, I didn't find the way to submit a Pull Request, so I am including the patch code here for other users:

astro@raspberrypi:/media/astro/rootfs/home/astro/Downloads/astro-soft-build $ git diff
diff --git a/build-soft-stable.sh b/build-soft-stable.sh
index e37f9b7..b105827 100755
--- a/build-soft-stable.sh
+++ b/build-soft-stable.sh
@@ -9,7 +9,8 @@ INDI_3RD_COMMIT="v2.0.6"
 STELLAR_COMMIT="e415e51d99224f239c24634519c030ef60969723"
 KSTARS_COMMIT="origin/stable-3.6.9"
 
-ROOTDIR="$HOME/astro-soft-stable"
+HOME_DIR=${HOME_DIR:-$HOME}
+ROOTDIR="$HOME_DIR/astro-soft-stable"
 
 JOBS=$(grep -c ^processor /proc/cpuinfo)

export HOME_DIR=/YOUR/CUSTOM_FOLDER
./build-soft-stable.sh

Thank you!

I know wire is more robust but I would like to reduce the amount of wiring. Wireless comes at the expense of more battery, but anyway, I will give WiFi a try.

I am planing to use it for the dome and dust cap, that are used very little during a session, so I expect it will not interfere among other devices.

In the case of the dust cap, it probably requires another approach, as you said, they may be required during a session in case flats or darks are scheduled. In that case, I should orchestrate it properly.

I was more concerned about Ekos requiring the devices to be active during a session, due to any rule. I have seen this flag on the dome to lock it to the mount and the other way around, lock the mount so the dome is open before unparking the mount. In the case of this lock, I think I should run it this way:
1. Power on dome
2. Connect Dome driver
3. Perform dome action
4. Unpark the mount.
4. Disconnect Dome driver (e.g. indi_setprop MyDome.CONNECTION.CONNECTION.DISCONNECT=On)
5. Power off the dome

Will step 4 work as expected? Or should I configure the mount and dome to be unlocked each other?

Read More...

Hi!

I am developing a DIY remote observatory, controlled by a RaspberryPi 4B and several microcontrollers. The observatory is in a remote location with no access to main electricity and thus, one of the requirements it is that it must run on batteries. In addition, I am trying to avoid wires, by using ESP8266 microcontrollers and connecting by WiFi. In order to save battery, I am try to optimize the use of devices.

I know that connecting devices to the RPi by wire will save more battery, but it will be a nightmare on cabling. Using WiFi is a bit in contradiction with the battery-efficiency, but I will give a try.

Having a look at drivers code, I realized they mainly use a continuous polling to get status, so it is to difficult to keep the devices saving energy, since they are waken up every 1-2 seconds.

I was considering that it will be interesting exploring how to connect and disconnect devices in the middle of a session. For example, the dome, dustcap, etc... I am considering this sequence:

1. Switch on the power of all devices
2. Start kstars and ekos,
3. Open an ekos profile,
4. Ekos connects to devices,
5. Start session by opening the dome.
6. Once dome is open, switch off dome controller to save power
7. Once dome is required again, switch on dome controller and reconnect to ekos.

Hi!

I am involved in a DIY project to build a remote observatory. I found some tutorials to build my own dust cap using an Arduino or ESP8266 microcontroller and a small servo.

I have created the firmware for the dust cap based on the SnapCap/Flip-flat protocol.

The point is that I created the firmware on a ESP8266 connect over WiFi, but I just realized that the Indi SnapCap driver only supports Serial communication.

I was reviewing the source code and get into INDI::DustCapInterface does not include support for TCP connections, but there are other drivers that have support for TCP on the base class, for example, INDI::Dome or INDI::Telescope.

I feel the place will be the INDI::DustCapInterface or the like, but I think I don't have the development competence to do it properly, and it will require a more gifted mind.

But I think I can make it on the SnapCap class. Did anyone consider it before? Adding it on the SnapCap driver?

Read More...

I also attach a screenshot of the additional data error in the last screen of the setup wizard

Thank you!!

The link you provided is working, my browser is a little bit fussy and I had to use https, like in www.indilib.org/jdownloads/Mac/gsc.zip

I attach a screenshot of the GSC problem.

Hi
I just installed Kstars 3.5.8 on an Apple Silicon running Monterey.
Using the setup wizard, I tried to install the GSC but it didn't install it. I clicked on the link that shows on the wizard screen but it links to a non-existent page on Google: drive.google.com/file/d/0B_ivMJINsdQ8cDh...Z0E/view?usp=sharing

I also tried to install additional data in the last screen of the setup wizard, but it failed with a message:

Loading providers from file: indilib.org/jdownloads/knewstuff/providers.xml failed.

But the point is that I manage to download the file manually

Any idea about this issue? Is it a bug?

Read More...

SkyWatcher ED 80, AZGTi with equatorial wedge, ZWO ASI 120MM, 9x50 guider