I am likewise a little confused, but it should work if they want to run it unless there is some custom installation stuff that Astroberry has. One issue I have seen on a couple of systems is that the installation directory for the libraries is different and so when building, the Indi drivers are looking for them in one directory when they were installed in another directory. This sort of thing is not actually a problem with my script but a build issue for INDI, because for the most part, my script is using the standard installation procedure for INDI.

Hello,

Because the gadgets of AstroPi3 on AstroBerry 1.1 are not on 2.0. That is why. The serial tool and others were not there. Although, the serial tool needs help. It’s better than nothing.

I miss the log viewer. Raspbian does not have one. The tool dmesg is ok. I want to see specific things.

If by gadgets you are referring to the scripts that I put into the utilities folder, basically those are scripts that I wrote to make it easier to set up things like persistent serial ports. They could probably use some improvement, but as you say they are better than nothing. If you have suggestions for improvement or changes you would like to make for them, you can let me know.

As for the QHY driver, that is probably a general INDI problem. Did all of the drivers including QHY build or were there errors in the build? Also, can you see where the qhy library got installed? As I was mentioning earlier, sometimes on some systems the library gets installed in an odd place and then the drivers are looking in the wrong place to link them. I need to mention that to Jasem.

For the frozen one, I would probably just run it again. See if it has an issue at a similar spot the second time.

Thanks,

Rob

Hello,

Yes. This command in UDEV rules helped solve my UBLox GPS and AstroEQ conflict. ATTRS {KERNEL==ttyACM*} added ttyACM1. The ttyACM0 was consumed by the GPS. Only one ttyACM type is given in Buster. To get another, the rules have to be added. Basically, serial communications requires a dedicated COM port. Throwing everything to SUBSYSTEM==usb is a free for all for the one ttyACM, ttyACM0. Last one standing is left out.

The QHYCCD issue is resolved after the update from yesterday occurred to KSTARS. I conducted a test run yesterday with AstroBerry 2.0 and no ret=-1 occurred. I got a big white screen to resolve. I don’t think ASTAP and Astrometry have any images of out of focus white walls. It was very fast also.

Ok thanks, that is good to know. I’m glad it helped you. So basically the main issue is that the script is using the bleeding edge version instead of a stable release and a bug was causing you issues. In the future I hope to add an option to use stable releases if desired, but that will make it more complicated.

Hello,

Every run hangs with a processor lock with compiling INDI at 12%. Last night, I let it run overnight. A processor lock is when the screen is frozen. Keyboard commands are gone.

I opened process up before running the script. When it is processor locked, six to seven threads of C++ threads are running. Memory is not the issue. I have 150mb free. I going to see if zram is not setup.

One question, why does this script install and remove anything without doing a status check?

How would you suggest doing a status check? The script builds the latest version of the astronomy software. If it was building stable releases, it could check the installed version number. But there is no way to check the installed latest version.

The only thing I could think of is that you could check to see if the downloaded repo is up to date. If it is, don’t build, and it if isn’t, update it and build/install. That might work to speed things up, but if there was an incomplete previous install, where some piece of software downloaded but didn’t install properly, rerunning the script would not fix it. As long as it works properly every time this solution is good. But I think the current setup is more robust. Basically if there are issues, re run the script.

Hello,

I started with AstroBerry 2.0. I was surprised that so many things had to updated. Didn’t AstroBerry 2.0 have all of the latest and the best? I wanted the scripts I had under 1.1. But the script has Ubuntu Mate component scripts.

Missing a specific patch level is something to check. Wrong distribution components need to be bypassed.

Also, if zram isn’t setup or insufficient, then warn and halt the script. Compiling anything takes copious amounts of memory and threads. Before starting the next section, halt and ask “Continue? Y or N”. Or pick from this suggested options to install.

LOL. Now, who has time to make this happen?

Hello,

I was not aware the Raspbian distribution was limited to a 100mb swap file. This is default and in a configuration file, /etc/ dphys-swapfile.

I increased the swap file to 1024. The script hung up at compiling wxformbu. Another memory lock. Mouse is dead. Processor is pegged at 100%. I then used the 3x memory option. We shall see if this is the optimum configuration to use for AstroBerry 2.0.

So, the Raspbian OS is limited to a small swap file.

My suggestion is to increase it to the 3+x or risk never to compile INDILIB, KSTARS, or another big application.

FWIW, in my experience I can compile Indi and KStars on my 4Gb RPi4 no problem. It's certainly not as quick as compiling them on my mac laptop, but it works for me and is usable for me. I've done it as well on a 2Gb RPi4, and the difference is noticeable, but still works OK. I would not recommend compiling these programs on a 1Gb machine (last year I tried and gave up on my Rpi3b+, I guess you can get lucky, but...).
You certainly want to run parallel make (e.g. 'make -j 6 kstars') on the 4Gb RPi.

I'm not on top of swap space for linux, but I checked my Raspbian RPi4 4Gb just now, and I had the 100Mb setting you mentioned active in /etc/ dphys-swapfile. However, running 'free -h' or 'top' shows that I currently have 4Gb swap, not 100Mb. I guess this is due to running zram en.wikipedia.org/wiki/Zram (something I didn't actively setup, but I guess I'm using, as I checked and it is in my /etc/rc.local file, and visible with '/etc/swapon -s'.

(I don't use Astroberry, just raw Raspbian with Rob's script).
Hy

Hello,

The script is rated for multiple versions of hardware. I never worried about Ubuntu Mate’s swap file. I was shag grinned to find Raspbian gasping for breath and dying under the load. I set up a zram under Ubuntu Mate for buffering images not compiling code.

I use INDI and KSTARS to run an AstroEQ driven OTA. I have several CCD cameras to try alignment, guiding, and capture. This is all under RPI3B+.