Raspberry-PI logo Raspberry-PI ready SD card image


GUI mode and Console mode
Working headless
Full console mode
Sending data to RMOB
Flashing your SD


This image contains a Raspberry PI 64 bit OS based on Debian 11 (briefly Raspbian11), the meteor scatter suite Echoes 0.52 + Ebrow 0.1.59 + RMOBclient_arm64 0.1 and all the libraries and packages they need to work, as Python3.11 that has been built from sources and installed in /usr/local to avoid clashing with Python3.9 that is installed by default since it's the basement for many system utilities and other programs.

This image is also a complete development system for the suite itself; it contains git, Qt Creator the Qt5 development libraries and sqlitebrowser. After power up, the system starts in graphical mode and auto-logins as user echoes with password echoes. I choose for the system to left the English language, but timezone, locale and keyboard are italian. Obviously feel free to personalize them for your country.

GUI mode and Console mode

Echoes and Ebrow can be started manually from the menu Other. You will find two entries because Echoes can be run with full GUI or in console mode, for this reason there are two configuration files provided under /home/echoes/echoes, called GUI_SETTINGS.rts and CONSOLE_SETTINGS.rts.

When launched in console mode, Echoes opens a terminal window and displays the current values of S, N, and S-N, capturing dumps when the upper threshold gets crossed. Both files use the GRAVES as signal source, so non-europeans users will have to patch the device settings to tune their reference transmitters. Since no screenshots are captured in this mode, The events spectra needs to be plotted with Ebrow to be seen.

The two rts files differs only in 2 parameters: SamplingInterval and GenerateScreenshots. This because the console mode allows for faster scanning than GUI's; but in console mode - as just said above - there is no way to capture screenshots. The sampling interval should be adjusted to the computing power of your Raspi, in order to get an average CPU load of the running program at about 60-70%.
On my Raspi 3B+ this means 150..200 ms in GUI mode and 50..80ms in console mode. With newer Raspi boards I expect better performances.

Working headless

This image is also ready to work in headless mode, starting Echoes automatically at boot. To do that, one of the two autostart files echoes.desktop.disabled or console_echoes.desktop.disabled must be renamed by removing its .disabled suffix. These files can be found under /home/echoes/.config/autostart.

Launching the command crontab -l in a terminal window, you will see some crontabs ready for use. All of them are commented out, so they won't be active by default.

The first one launches the python script check_alive.py twice per hour to send a warning email in case no progress have been recorded since the last launch. No progress could mean that the program died or hanged for any reason:

# Checks for database activity twice per hour at hh:05 and hh:35 and sends a warning email if nothing has changed in the meantime
# Replace with the name of your rts file and the email with yours before uncommenting:
# 5-35/30 * * * * /usr/bin/python3 /home/echoes/check_alive.py ~/echoes/GUI_SETTINGS/GUI_SETTINGS.sqlite3-wal 30 somemail@somewhere.com sender@fromhere.com 1234 smtp.fromhere.com
# check_alive.py arguments:
# [SMTP port]

The second is executed at 20th minute of each hour to launch Ebrow, generate the RMOB files and send them to RMOB server. The correct station informations must be entered in Ebrow preferences tab first. By default, they are set with generic placeholder values:

# WARNING : the below tasks will run on a graphical system only. They must be commented out when working in multiuser mode.

# Generate and sends RMOB files once per hour at hh:20
# Please fill the station data in ebrow/preferences tab before uncommenting and test this cron with internet disconnected until the
# produced data files under /home/echoes/ebrow looks fine.
# 20 * * * * DISPLAY=:0 /home/echoes/.local/bin/ebrow --rmob

The third one is executed at 01.30 UTC each day to generate the report:

# Generate an automatic report once per day at 01:30
# 30 01 * * * DISPLAY=:0 /home/echoes/.local/bin/ebrow --report

Full console mode

Echoes can run also in full console mode, without any graphical system at all. This can be accomplished by the following commands:

sc enable console_echoes
sc set-default nulti-user.target

then reboot.

sc is an alias for sudo systemctl. There are also other useful aliases defined in /home/echoes/.bashrc

The program starts in background, and the only way to monitor its activity is to browse the journal with the command jcf (another alias for journalctl -f).

Remember that in full console mode Ebrow cannot run; so the crontabs which launch Ebrow should be commented out.
To get the data from the DB, the user should connect the Raspi from a remote computer which runs Ebrow.
To restore the original configuration with GUI:

sc disable console_echoes sc set-default graphical.target

and reboot.

Sending data to RMOB

Ebrow should run locally on the RPI to allow periodic data sending to RMOB via crontab (see here). This means that the system should be configured to run in GUI mode, since Ebrow needs an X server to run.
But an X server can also be run remotely, instead of on the RPI, for instance on a Windows PC that runs VcxSrv. This allow to make the RPI run in full console mode without an X server running aboard and still be able to run Ebrow locally by displaying its GUI on the remote PC.
In this way, one can send RMOB data automatically even in full console mode; the drawback is that one needs 2 computers working 24h for this.
In order to connect the remote X server, please edit the script xremote.sh on the RPI:

export DISPLAY=
xhost +

replace with the IP address of your PC. Now start the VcxSrv on your PC, remember to check the box disable access control while doing this.
Once started the server on PC, run xremote.sh on the RPI, then start Ebrow.

Flashing your SD

This image fits on a 32 GB SD Card. Please pay attention to the fact that the capacity in bytes of the SD card must be sufficient to contain the decompressed image.
I'm unable to install the image on a Lexar card or even on a Kingston card due to their lower capacities (around 200 MB less). I therefore recommend using an SD card of the same model as mine, a SanDisk:
Original SD card
The original SanDisk 32GB SD card from which the image has been generated

  • Back
  • Home
  • Next