×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Installing on Rpi 4, running Ubuntu 20.1 - the why and how (sort of)

  • Posts: 407
  • Thank you received: 74
"I do not read manuals!" - nobody did before 1990's and electronic bullitin boards (pre cursor to Internet) - as by the time the "manual" and the associated pages of "updates" arrived by POST (thats the old fashion letter type) you had figured it out and the manual/updates were out of date anyway - LOL. Bit like Wright brothers - ok maybe not!

Like you write up - nice one.
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
3 years 2 months ago #67259

Please Log in or Create an account to join the conversation.

  • Posts: 396
  • Thank you received: 17
I want to add a couple more clues here in case anyone decides to go hunting around concerning the 'crashes' I experienced running the Astroberry Server. As I said I am running on an Rpi 4 with 8 Gb of Ram. I was running Astroberry Server 2.0.3 and Kstars 3.5.0. Initially, I had a lot of index files loaded, because occasionally I would try to solve using the main camera (ASI533 on an SCT 9.25, FOV ~ 17 arcmin!), while most of the time I would solve using my e-finder (ASI120 on an Orion 9x50 - FOV~1.2 degrees). The first clue that something was not right was when the program tired to load all the index files into memory (2.6 Gb), I did have enough memory to do that, but the logs indicated some were not getting loaded. So I reduced the index files to only those for the e-finder (.6 Gb), that solved the loading issue, but I was still experiencing crashes during "capture, solve and sync." We have had a week of clouds and rain, so I was running everything in my garage, using all the equipment, but simulating imaging. I would run a sequence that would consist of "load and slew" to a saved image (NOTE: the program rarely crashed on this, I say rarely only because 'never' is too strong a statement, I don't recall it every crashing on "load and slew," even in real use under the stars. I would say 90% of the crashes were associated with "capture, solve with sync checked"), then I would do a blank "capture, solve and sync" and repeat this sequence until the system crashed or didn't (after say 6 tries). I ran this "experiment" under different settings of the StellaSolver; 1) - default (which I assume means parallel processing, and 2) - single thread solving. I don't recall it ever crashing under the second condition. Our options (I did have help) at this point where to dig deeper into the program to figure out why it was crashing (the logs were leading us to the routines associated with KdTree ) or go a different route with a different OS or even processor. A couple of quick tests suggested that the Ubuntu 64 bit OS was handling the math (no very small or very large numbers in the logs) better than the Raspbian 32 bit OS. So that is how I ended up where I am now.

Now I will add a few more key items in setting up Ubuntu 20.1 on this Rpi.

# - to install ssh: sudo apt install openssh-server after doing this I could then use putty on my laptop to log into the Rpi if I had been running headless.
# - installing Lightdm and x11vnc - I found this YouTube very helpful.
# - when I installed Lightdm it told me that I already had the latest version, however it did not activate it and gdm3 was still the default display manager,
had to run sudo dpkg-reconfigure lightdm to bring up the screen that allows you to switch between the two display managers.
# - install x11vnc with this first: sudo apt update then: sudo apt -y install x11vnc and this: sudo ufw allow 5900/tcp
# - after installing x11vnc you need to set up and store a password: sudo x11vnc –storepasswd YOURPWD /etc/x11vnc.pass
and modify the .service file using 'nano' editor as root: sudo nano /lib/systemd/system/x11vnc.service
My file looks like this:
[Unit]
Description=Start x11vnc at startup.
Requires=display-manager.service
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -env FD_XDM=1 -auth /var/run/lightdm/root/:0 -forever -loop -display :0 -geometry 1024x768 -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -o /var/log/x11vnc.log

[Install]
WantedBy=multi-user.target

the meaning of these settings are explained in the X11vnc Manual
once you have modified the .service file you need to reload the vnc Daemon: sudo systemctl daemon-reload and enable the service: sudo systemctl enable x11vnc.service
If you make any changes to any of the .service files (in /lib/systemd/system) you should stop that service first, make change, reload the Daemon and restart the service using the "systemctl" command
you can check on the status of any service with that command as well, as in: sudo systemctl status x11vnc.service

# - Now you are reading to install the programs, but you need the Python Package installer: pip3 sudo apt-get -y install python3-pip
# - Install INDI, Kstars and INDI Web Manager.
sudo apt-add-repository ppa:mutlaqja/ppa
sudo apt update
sudo apt -y install indi-full kstars-bleeding python3-pip python-is-python3
sudo -H pip3 install indiweb

# - install IndiWebManager
wget raw.githubusercontent.com/knro/indiwebma...diwebmanager.service
put your userID in the indiwebmanager.service file and copy it to sudo cp indiwebmanager.service /etc/systemd/system/
make it executable sudo chmod 644 /etc/systemd/system/indiwebmanager.service
reload the Daemon, since you modified the service sudo systemctl daemon-reload
enable the service sudo systemctl enable indiwebmanager.service
# - Reboot to start indi web manager,
# - I found all the Indi device driver files in: /usr/share/indi
# - to run indiwebmanager open browser - go to localhost:8624
# - to install PHD2 sudo add-apt-repository ppa:pch/phd2 and then sudo apt install phd2

At this point I was able to run all the necessary programs to access my equipment and run Kstar/Ekos/PHD2 in the Ubuntu environment. As we are still having several days of rain, it will be some time before I
can actually test this environment out in the real conditions. I am hopeful that it will have solved my previous problems and will be enjoying evenings of imaging again.

thats all and thanks all!
The following user(s) said Thank You: Brian
Last edit: 3 years 2 months ago by Ronald Scotti. Reason: corrections
3 years 2 months ago #67288

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
I too was sick of the 32bit Astroberry. As a Linux user I prefer an Arch Linux based distro, so over the last 2 weeks I've been trying to set up a build that I would be happy with. I did come across a bug with dealing with gpsd due to a breaking change that gpsd in v3.22 (I've submitted a fix to indi-3rdparty which should appear in indi 1.8.9). I need to get around to writing up my Arch Linux install (I did end up using Manjaro RPi as a base as it's a bit more stable and cleaner than Arch Linux ARM).

While I've not used my build for observing yet I can tell that RPi is running more smoothly and the VNC is way better than Astroberry which is Raspbian / Raspberry OS based.
3 years 2 months ago #67337

Please Log in or Create an account to join the conversation.

  • Posts: 396
  • Thank you received: 17
I never had an issue with the server aspect of the Astroberry server. It always stayed connected (over ethernet) to the browser on my laptop in the house and it always stayed connected to the equipment (all connected to a 3.0 USB powered hub on the Rpi). My issues seemed to be associated with possible memory over writing during plate solving and sometimes during image manipulation in the Fits Viewer. Moving from a 32 bit OS to a 64 bit OS seems to have solved those memory issues, but I have not been able to test everything under clear skies. A week of rain has me testing in my garage with simulated image captures, but so far I have not had any crashes like I experienced before. My crashes were just Kstars/Ekos, those panels would just go away, but the server was still running and connected in the background. I liked the implementation of the Astroberry Server, but I don't think the 32 bit OS was up to the task of all the enhancements to Kstars/Ekos over the past year.
3 years 2 months ago #67424

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
Not sure if you're aware but a recent change to the linux-firmware has made the internal RPi4 wifi to stop working, it's happening on all distros. If you have an issue I can point you to the fix.
3 years 2 months ago #67425

Please Log in or Create an account to join the conversation.

  • Posts: 396
  • Thank you received: 17
I would be interested in knowing about this. I am not currently using the wifi on my Rpi 4, but may want to at some point. My Rpi 4 is 4 months old, I updated the eprom back in Dec to allow booting from an SSD, since then I have only installed new OS's on SD and SSD, so I don't know if this applies to my Rpi 4.

thanks,
3 years 2 months ago #67430

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
If you can see your Wifi when doing
ip addr
then there shouldn't be an issue. If you can't then you might be affected by the recent change they did with the linux-firmware, see archlinuxarm.org/forum/viewtopic.php?f=1...b6009e84b45e8c2e6523 (while it's for the ArchLinux ARM, there are other ARM based distros reporting the same thing). The solution is to remove unnecessary files in the firmware directory, based on the forums the following worked for me:
sudo rm /usr/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ Model\ B.txt
sudo rm /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt
sudo rm /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
sudo rm /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
3 years 2 months ago #67431

Please Log in or Create an account to join the conversation.

  • Posts: 396
  • Thank you received: 17
Thanks, I will check my system. I ran my equipment, using the Ubuntu OS, last night under the stars and everything worked great. Multiple capture, solves and sync's and not one crash. It was very satisfying to have this software live up to its potential on my equipment.

thanks all,
3 years 2 months ago #67483

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
I did an engineering test last night with my Manjaro ARM build, except for having WiFi issues (didn't have it work as a hotspot, it was trying to connect to the wifi) it ran smoothly. There were no crashes and all the equipment worked; I even got around to testing out guiding with my OAG. I didn't have time to do an observing run but quite happy with the results.
3 years 2 months ago #67490

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
Over lunch today I think I have sorted out setting up a hotspot using networkmanager properly. The problem I had was the dnsmasq wasn't resolving to RPi properly so my laptop and server were still trying to resolve based on the other NIC that was having poor connectivity. At least I know I can still use my phone's hotspot functionality if need be.
3 years 2 months ago #67497

Please Log in or Create an account to join the conversation.

  • Posts: 396
  • Thank you received: 17
I had no trouble setting up a wifi hotspot, it was more difficult trying to figure out how to get to start at boot. Finally figured out how to add a command line to the "startup applications preferences" file and that did the trick.
3 years 2 months ago #67548

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 8
Yeah, took me a fair bit of googling for answers and getting conflicting things. Just made networkmanager autoconnect and set the priority of the wifi. You try to get it to do a virtual device but since I have a USB Wifi I have used that + the RPI's wifi too.

Anyway I made sure I documented my setup and have all my config on my github page, it is for Manjaro ARM but they're a systemd + network manager system it might be helpful in some parts for anyone who is configuring their own system (other than installing packages) github.com/wgauvin/astrogruff-setup
3 years 2 months ago #67550

Please Log in or Create an account to join the conversation.

Time to create page: 1.302 seconds