raspberry-noaa-v2: a satellite imagery ground station on a Pi

A ground station rebuilt around one install script

raspberry-noaa-v2 is a spinoff of the original raspberry-noaa project, and the readme is careful about the credit. The original was created by Nico, who graciously permitted this version to be pushed forward with a major refactor to enhance things such as usability, style, and general updates, and all of the original content has been preserved, including the commits up to the point this repository was created, to retain the credit of the original creators.

That is an unusual and generous arrangement, and it tells you something about the project. It is a community project with a history, not a rewrite that starts from a blank page.

The stated reason for the second version is practical. A lot of the work done by Nico and the original Instructables poster was excellent and simple, but as the new maintainer started using the framework they found themselves making a lot of changes and finding it hard to get those changes in place in a manageable way. The agreement with Nico was that there is a logical next maturity step, and the answer was a simple one command script and a corresponding framework to manage and maintain the whole project whenever a change happens, plus a significant refactor of the web panel so that features can be added later.

The result is a project that does two things: it gives you a working weather satellite receiver on a Raspberry Pi, and it gives you the infrastructure to keep changing it without hand editing a pile of scripts.

The project is GPL-3.0 licensed, the last push was on 2026-05-16, and the release history is in the 1.x line, with 1.8.0 from October 2021, which is worth noting because it tells you the versioning continued from the original project rather than restarting.

There is a Discord server for support and for talking about new features, and a migration document for anyone moving across from the original version.

The quick start, and the one command that does the work

The quick start is deliberately short, and the order of it matters.

# update os localisation settings like timezone, locale and WiFi country, and expand the filesystem
sudo raspi-config

# install git
sudo apt install git -y

# clone repository
cd $HOME
git clone --depth 1 https://github.com/jekhokie/raspberry-noaa-v2.git
cd raspberry-noaa-v2/

# Edit settings to match your station's location, gain and other things
nano config/settings.yml

# perform install
./install_and_upgrade.sh

Four things happen there, and the first is the one people skip. The localisation step sets the time zone, the locale, and the WiFi country, and it expands the filesystem, which is the step that decides whether the captures have room to live. A satellite receiver that fills its partition in a week is a common and avoidable failure, and it starts here.

Then git, then the clone with a shallow history, which is the right choice for a deployment and means an update is a fast fetch rather than a history negotiation.

Then the settings file, edited by hand, and the fields that matter are the station location and the gain. The location matters for the pointing and for the pass predictions, and the gain matters for the receiver front end. The readme says to match the settings to the station, which is a hint that this file is the one thing you have to think about before the install.

And then the install script, which is the point of version two. The same script is named for upgrading, so the same command is the one you run when a new version is released, which is what makes the update path a single command rather than a sequence of steps that differ per release.

After the install, the log for a capture event is at a fixed path under the system log directory, and there is separate documentation for running the web panel behind a TLS terminating web server, with an admin login and a certificate from a public certificate authority.

Prebuilt images, and the trade they make

For anyone who does not want to build from source, the readme points at a set of maintained images, and it is unusually open about what the trade is.

The first is an image maintained by VE3ELB, and the setup instructions are in a PDF that ships with it. The second is an image maintained by Jochen Köster, and the readme notes that his image is the base of an off-grid system in northern Norway, which is the kind of detail that tells you more about an image's quality than a version number does.

The third is an image by MihajloPi, and it is described as oriented towards the general user, coming with little software installed beyond what is necessary, and built from the minimal desktop version of the Raspberry OS.

The caveat is stated once and applies to all of them: the images are not always up to speed with the latest code, and the readme says lots of people find images a great way to get started quickly.

That is an honest framing of what a prebuilt image is. The install script, the settings file, and the receiver configuration are the parts that are fiddly, and an image removes all of that friction. What it costs is that the image is a snapshot, so a bug fixed in the project is not in your image until you rebuild it or the maintainer refreshes it.

For a first installation, that is almost always the right trade, because the first run of a satellite receiver is not the time to also be debugging an installation script. For a station that has been running for months and depends on the latest decoding software, it is the wrong one.

The web panel, the database, and the template layer

The repository layout shows how the project is put together, and the interesting part is that the web interface is not a single program.

There is a webpanel directory, which is the user interface, and a templates directory, and the primary language recorded for the repository is a templating language rather than Python or shell, which tells you the panel is rendered rather than assembled by hand. A templates directory next to a web panel is a server side rendering setup, and that is what makes the panel able to show a capture, a graph, and the settings without the front end carrying the model.

Then there is a database directory, with separate directories for backups and for migrations. A satellite receiver that shows you what it received an hour ago needs the metadata of the previous captures, and a database is how you get that, and the migrations directory is the evidence that the schema is versioned rather than created fresh on every install.

The install and upgrade script at the root is the single entry point, and the support script next to it is presumably the diagnostic tool for when something is wrong. There is an ansible directory, which is how the install is made repeatable, a software directory for the pieces the receiver depends on, a scripts directory, a config directory holding the settings file you edit before installing, and a temporary directory.

Two operational details are documented rather than assumed. The capture log is at a fixed path, so you can read it after an event to see what happened. And the migration document explains how to carry your existing captures across from the original version, which is the single most valuable piece of documentation in a project like this, because the captures are the thing users do not want to lose.

Bookworm, and saving the captures before you reinstall

The announcement section carries the most operationally important news in the readme, and it is a retirement notice with a deadline attached.

As of 31 July 2024 the legacy Debian Bullseye support for Raspberry Pi and x64 PCs is being sunset. That support had continued for some time after Bookworm support arrived in May 2024, and the new updates for SatDump and the other features related to it will only be available for 64 bit Raspberry OS Bookworm and for 64 bit Debian Bookworm based distributions on x64 machines.

The advice for anyone still on the old system is a full reinstallation of the operating system and a fresh installation of the project, rather than an in place upgrade.

The useful part is what survives that. It is possible to keep previously received images by making a copy of the panel database file inside the project database directory and the whole service directory, and those files can be restored once the new installation has finished. If you are satisfied with the features you already have, the readme says you are free to use the system as is.

That is a careful piece of release management, and it says something about how the project is run. The decision to drop a base image is usually taken because the software that does the decoding has to be rebuilt against the new one, and a satellite receiver whose decoder is a year out of date is a receiver that misses the newer satellites.

It also explains the recommendation about the operating system elsewhere in the readme, and the compatibility section, where a note about 32 bit systems remains. That note and the announcement point in opposite directions, since the announcement is about 64 bit Bookworm systems, so the compatibility section is the part of the documentation to read with suspicion.

The project has been developed and tested on LMDE 6, the Debian edition of Linux Mint, and since September 2023 it is said to work on any Debian based distribution.

The hardware question, and the documentation that answers it

The last piece of the readme is a link, and it is a good one to have in mind before buying anything.

If you are looking for one of the cheapest ways to get started from the antenna side, the readme points at a page about using a cheap rabbit ears antenna as a dipole for capturing NOAA and Meteor images. That is the single most useful piece of practical advice in the whole document, because the failure mode of this project is almost never software, it is a station that cannot hear the satellite.

The rest of the documentation is organised as a set of files in the docs directory. There is the migration document, which is the first thing to read if you are coming from the original project, since it explains the few commands you need to run and how to keep your original data visible. There is the document for the TLS enabled web server, which covers the admin login and the certificate. And there is the document with screen shots of the web panel, which the readme notes is now mobile friendly, and which is the quickest way to see what the project produces before you install it.

The release notes are called out as well, one set per version since the split, which is the part to read before upgrading a station that is currently working.

So the shape of the project is: a device, an antenna, a decoder, a database, and a panel, with an install script that ties them together and a documentation set that covers the parts that are not code. The parts that are code are in the repository, and the parts that determine whether it works are the antenna and the operating system.

Editorial conclusion

raspberry-noaa-v2 fits an amateur radio operator or a teacher who wants to receive live weather satellite images and has a Pi and a television card to spare, and who is comfortable with a shell and a YAML settings file. It does not fit a Raspberry Pi 5 or a current Raspberry OS install you do not want to reflash, because the supported base is a 64 bit Bookworm system and the old Bullseye support is being retired. Verify first which operating system you are on and whether the satellite decoding software you need is still receiving updates for it, that your antenna arrangement can actually receive the passes you want, since the documentation is explicit that even cheap rabbit ears work as a dipole, and that you have copied the panel database and the service directory before you reinstall anything.

Frequently asked questions

Official sources

1. Issues
2. jekhokie/raspberry-noaa-v2 on GitHub
3. License: GPL-3.0
4. README
5. Releases