Artemis: an RF signal identification workbench built on PySide6

A reference tool for what is on the air

Artemis is described as the reference for radio signal identification, and the readme describes it as software designed to assist radio frequency signal identification and storage. The stated problem it solves is that real time spectrum analysis is hard to do properly on its own, because a waterfall of noise is not an answer.

The approach is to pair the analyser with a database. Artemis draws on one of the most extensive, community driven databases, which contains over 500 recognised signals, and the readme is explicit that the database is a separate artefact with its own release cadence.

The user story is a specific one. You point the software at a frequency and it shows you the spectrum; you can collect signals with specific parameters such as frequency, bandwidth and modulation; you can store spectrum waterfalls, audio samples and documents for later reference; and when you recognise something on the waterfall you record what it was, which is how the database grows.

That last point is the mechanism worth understanding. This is a community project, and the community contribution is the signal knowledge. The software gives you the tools to identify and record, and the database gives you the accumulated answers from other people. The signal count in the badge is the measure of what the crowd has contributed so far.

The audience is radio hobbyists, RF engineers and anyone who has ever watched a waterfall and wanted a name for what they were seeing.

The signal database is a project of its own

The badges at the top of the readme show two release versions, one for the application and one for the database, and a third that counts the files in the static directory of the database repository.

That separation is the most structural fact about the project. The database is distributed as its own repository, Artemis-DB, with its own version and its own publishing cycle, while the application is what you install and run. The consequence is that the two can be at different versions, and that is the first thing to check when a signal is not recognised.

The people credited in the readme explain where the data comes from. Carl Colena is listed as the Sigidwiki admin, a beta tester and a signals expert, and Sigidwiki is the signal identification wiki the project is closely tied to. Paolo Romani is listed as the lead beta tester and an RF specialist, and several others are credited as beta testers.

That list of roles is a good description of the project's working method. There is a lead developer for the earlier versions of the application, a lead developer for the third version, a macOS deployment contributor, an ARM port contributor, a wiki page author, and a group of beta testers who are mostly radio people rather than programmers.

So the knowledge in the database is reviewed by radio specialists, and the software is reviewed by developers. That division is why the project has a database that can be trusted to name a signal correctly, and also why a new signal is not in there the day it appears on the air.

What you can collect, and what the archive holds

The readme is specific about the parameters and the artefacts, and they are the two halves of what the tool does.

On the collection side, you collect RF signals with specific parameters such as frequency, bandwidth and modulation. Those three are the identity of a signal, and storing them with a capture is what turns a waterfall into a record.

On the storage side, the readme names three kinds of artefact: spectrum waterfalls, audio samples, and all types of documents. The waterfall is the visual record of the spectrum over time, the audio sample is the demodulated or recorded sound, and the documents are the supporting material, which for a signals project means things like a modem manual, a datasheet or a screen capture of a decoder.

Keeping those together matters more than it sounds. A waterfall without the audio is a picture of a signal, and the audio without the parameters is a recording. The value is in the combination, and a tool that stores them in one place with a shared identifier makes the combination searchable later.

The readme also lists data and a scripts directory at the top of the repository, alongside the artemis package, the ui directory, the config directory and the docs, which is consistent with an application that keeps a local archive on disk and ships reference material with the code.

Packaging with Briefcase and PySide6

The packaging metadata in pyproject.toml says a lot about the intended shape of the software, and it is the most concrete part of the documentation.

[project]
name = "artemis"
version = "4.2.0"
description = "Radio Signals Recognition Manual"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "packaging==26.2",
    "peewee>=4.2.6",
    "pyside6==6.11.1",
    "requests==2.34.2",
]

The project is a Python application with a Qt user interface through PySide6, pinned to a specific version, an ORM through peewee, HTTP through requests, and a floor of Python 3.12. The project description, Radio Signals Recognition Manual, is the giveaway that the tool is a reference work as much as an analyser.

The packaging itself is done with BeeWare Briefcase, and the configuration shows a bundle identifier of com.aresvalley.artemis, the sources being the artemis and config packages, and a project URL of aresvalley.com.

[tool.briefcase.app.artemis.macOS]
universal_build = true
min_os_version = "13.0"
requires = [
    "std-nslog~=1.0.3",
]

The macOS section builds a universal binary and requires macOS 13.0 or later, with the standard library logging dependency included, and there is a Linux section as well. There is also a .qmlproject and a .qrc resource file in the repository, which are Qt project artefacts, and a uv.lock for the Python environment, alongside a python3-requirements.json.

Windows signing, macOS builds and the Raspberry Pi port

The readme notes that free code signing on Windows is provided by SignPath.io, with the certificate from the SignPath Foundation. That is worth understanding as a distribution fact rather than a sponsorship fact, because it is what allows the Windows build to be delivered without the user seeing an unverified publisher warning, which for a tool that captures radio data and talks to a server is a meaningful difference in how it is received.

The macOS build is a universal binary with a minimum system version of 13.0, and the macOS deployment is credited to one of the contributors. The ARM port is credited to Eric Wiessner, who is listed as the ARM port contributor for the Raspberry Pi 3B+ and Pi4B. That is a good sign about the shape of the tool, because a spectrum analyser on a single board computer next to the antenna is a natural deployment, and the contributor list shows it was actually done.

So the platform coverage is broad. A desktop application on macOS, Linux and Windows, plus a port to a Raspberry Pi, all built from the same Python codebase with a Qt interface, and all signed or buildable in a way that a user can install without friction.

The readme itself, though, does not print an installation command for any of them. The documentation section sends you to the main website and to the documentation hosted at aresvalley.github.io/Artemis, and that is where the packaging per platform is explained.

Where Artemis is the wrong tool

Four limits, and the first one is about what the tool is not.

Artemis identifies and stores signals, it does not decode them. A demodulator that turns a waveform into readable data is a different program, and the readme describes nothing of that kind. If the question is what a transmission says rather than what it is, this is the wrong tool, and the software you want is an SDR decoder that speaks the protocol.

The second is the hardware and environment. A spectrum analyser needs an SDR dongle or a receiver and a working antenna, and identification depends on a clean enough signal. That is a physical constraint on the whole workflow, and it is why the project is for radio people rather than for software people who want a database.

The third is the knowledge currency. The database holds over 500 recognised signals and grows through the community, which means a brand new or deliberately obscure transmission is unlikely to be in there, and the readme does not describe a way to add a signal definition yourself. You can record the observation, and you can annotate it, but a name for an unknown signal has to come from outside.

The fourth is the installation story. The readme contains no command to install the application, no supported package manager for Linux, and no instructions for connecting a specific SDR. Everything about getting it running is in the external documentation, which for an adopter is a step that has to be done before anything else.

Licence, releases and how the project is put together

Artemis is licensed under the GPL-3 licence, with the LICENSE file linked from the readme. That is a strong copyleft, and for a desktop application that people install rather than distribute it is mostly a non-issue, but anyone bundling it into a larger product should take legal advice rather than assume. This is not legal advice.

The release history is steady. Version 4.1.1 was published on 2026-06-27, 4.1.5 on 2026-07-03 and 4.2.0 on 2026-07-18, which is a patch and a minor release in the space of a month. The last push to the default branch was on 2026-10-06, and the repository is not archived, so work continues after the last tag.

The repository is a mature one. There is a CHANGELOG.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md, a docs directory, a scripts directory and a config directory, plus the artemis package, the ui directory and the launcher. The Python environment is locked with uv, and the documentation site has its own zensical.toml configuration.

What the readme does not do is document the application itself. There is no feature list beyond the opening paragraph, no description of the database schema, no explanation of how the analyser is configured for a particular receiver, and no statement of what the current release changed beyond the version numbers and the changelog. For a project with a nine person contributor list and a decade of version history, that is a documentation gap rather than a quality signal, and it is the practical thing to weigh against a tool that does one job well.

Editorial conclusion

Artemis is the right tool for a radio amateur, an RF engineer or a spectrum monitoring group that wants to identify what is on the air, capture waterfalls and audio samples, and keep the observations in a searchable local archive. It is the wrong tool for decoding protocols, for a monitored production environment, or for a team that needs a documented installation path today, since the readme sends you to the documentation site rather than printing commands. Before adopting, read the documentation for the hardware setup it expects, check that the signal database release matches the application release you install, and confirm the licence terms suit how you intend to distribute it.

Frequently asked questions

Official sources

1. AresValley/Artemis on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases