Overlap resolution — recommended defaults¶
SCOPE.md: "Merging five inventories without curation produces four ADS-B
decoders and no opinion about any of them — the opposite of what this project is
for." This is the opinion.
Recommendations only. Every one of these is the maintainer's to accept or reject. Nothing here is written into a manifest.
Per PARITY-POLICY.md, a recommended default never removes working software.
Alternatives stay in the catalog with the trade-off documented; the default is
what an operator gets when they install a profile and express no preference.
Availability was checked against sources.debian.org and the Blend task
files, so the cost of each recommendation is known rather than assumed.
1. ADS-B and aircraft tracking¶
| Candidate | Source | Availability |
|---|---|---|
dump1090 (FlightAware) |
AHRL — source build from a master zip |
not in Debian |
dump1090-mutability |
Debian Blend (nonamateur) |
in unstable only — not in Debian 13 |
readsb |
— | in Debian |
| Virtual Radar Server | AHRL — Mono + .exe |
not in Debian |
tar1090 (web UI) |
— | not in Debian |
Recommended: readsb¶
Actively maintained, in Debian, and it supersedes both dump1090 forks at once — AHRL's unpinned
mastersnapshot and the Blend'sdump1090-mutability, which AHRL itself dropped in v27.
Also carry: dump1090-mutability — it is the Blend's own choice and removing
it would break parity with a team-governed source for no user benefit. Note,
measured 2026-08-25, that it does not install on Debian 13 either; it is in
unstable. That strengthens rather than weakens the readsb recommendation, since
readsb is in Debian 13 and every other target.
Recommend RETIRE: Virtual Radar Server. Mono was handed off by Microsoft in
2024, the AHRL install needs a second tarball purely to patch a runtime error,
and its launcher starts a decoder and killall -9s it on exit.
Flagged cost: tar1090, the modern web UI, is not packaged. It is
carried since 2026-10-02 as a pinned data unit that hammunition reference
serve serves on 127.0.0.1 (D-071), which needed no new backend. The decoder
half is apt-only.
2. Logging¶
| Candidate | Source | Availability |
|---|---|---|
cqrlog, xlog, klog, tlf, tucnak, pyqso, trustedqsl |
Blend logging |
in Debian 13 |
qlog, not1mm |
Blend logging |
in unstable only — not in Debian 13 |
fllog, flnet |
AHRL — source | not in Debian |
| HAMRS | 73Linux — AppImage | not in Debian |
Recommended: qlog for general logging¶
Modern, actively developed, and already the agreed default in
PARITY-POLICY.md.
⚠️ Corrected 2026-08-25 — qlog does not install on Debian 13. A probe of
all 152 Blend packages inside a debian:13 container found qlog and not1mm
present in unstable (qlog 0.52.0-1) and absent from stable. The earlier claim
that this default "costs no backend work" was wrong on our primary targets,
which derive from Debian stable.
The recommendation is unchanged — qlog is still the right default, and it
arrives in Debian 14. What changes is what the catalog must say in the meantime:
| Option | Consequence |
|---|---|
Recommend qlog; declare it unavailable on stable in the capability matrix; fall back to cqrlog ⭐ |
Honest, costs nothing, and is exactly what the capability matrix exists for. cqrlog is in Debian 13 and works. |
Ship a source or upstream-.deb path for qlog on stable |
Gives everyone the default. Adds a backend obligation for one package, for a gap that closes on its own. |
| Change the default to something in stable | Optimises for today's package archive over the software. Wrong trade. |
Recommendation: the first. Per D-005, coverage counts only where it installs, and per D-019 "in the Blend" is not the same claim as "installable". Recorded rather than papered over.
These are not all the same job, and treating them as one overlap would be a mistake:
| Job | Recommended | Why |
|---|---|---|
| General station log | qlog |
Active and modern; sid-only, see above |
| Contest logging (GUI) | not1mm |
Actively developed; already carried by AHRL; sid-only |
| Contest logging (terminal) | tlf |
The serious contest CLI; no GUI competitor |
| Net control | flnet |
Different workflow entirely — running a net, not logging QSOs |
| Networked shared log | fllog |
Serves a log across machines; not a personal logger |
| LoTW upload | trustedqsl |
Not a logger at all; every operator needs it |
Also carry: cqrlog, xlog, klog, tucnak, pyqso. All work, all
packaged, all have users.
Post-1.0: HAMRS — proprietary freemium, AppImage, and its upstream is discovered by scraping a webpage.
3. SDR receivers¶
| Candidate | Source | Availability |
|---|---|---|
gqrx-sdr |
Blend sdr; AHRL builds from source |
in Debian |
sdrpp (SDR++) |
Blend sdr; AHRL builds a master snapshot |
in Debian |
sdrangel |
Blend sdr |
in Debian |
cubicsdr |
Blend sdr |
in Debian |
quisk |
Blend sdr; AHRL source |
in Debian |
welle.io |
Blend nonamateur |
in Debian (DAB, not general) |
Recommended: gqrx-sdr as the general-purpose default¶
The most documented, most widely used, and simplest receiver to get working with a first SDR — which is the situation most users are in when they open one.
Tiered alternatives, because "SDR receiver" hides three different needs:
| Need | Recommended | Why |
|---|---|---|
| First SDR, general listening | gqrx-sdr |
Simple, documented, forgiving |
| Modern UI, plugin ecosystem | sdrpp |
Actively developed, better performance |
| Multi-channel, transmit-capable, advanced | sdrangel |
Far more capable and far more complex |
| Transceiver operation, not scanning | quisk |
A transceiver app; different job |
This resolves an unpinned snapshot for free. AHRL builds SDR++ from an
unversioned SDRPlusPlus-master.zip. Debian packages it. Preferring apt removes
one of the six snapshot problems in D-006 at no cost — see the same pattern in
blend-inventory.md's M3 cross-reference.
Note the naming trap: the Debian package is gqrx-sdr, not gqrx. A
manifest that guesses will silently resolve to nothing.
4. APRS¶
| Candidate | Source | Availability |
|---|---|---|
xastir |
Blend packetmodes; AHRL apt |
in Debian |
| YAAC | AHRL — Java zip | not in Debian |
| Pi-APRS | 73Linux | not packaged; unlicensed (D-001) |
aprsdigi |
Blend packetmodes |
in Debian |
direwolf |
Blend; AHRL source | in Debian |
Recommended: xastir¶
Mature, packaged, in the Blend, and already installed by AHRL — the only candidate that is simultaneously maintained, free of licence questions, and apt-installable.
Also carry: YAAC. It has a genuinely better map UI and an active author, and some operators strongly prefer it — but it needs a JRE and a binary backend, so it should not be the default.
Cannot carry: Pi-APRS. KM4ACK's own work in an unlicensed repository (D-001); we have no right to redistribute it regardless of merit. If the licence question is resolved this reopens.
Not competing, do not conflate: direwolf is the TNC — the modem layer
underneath any of these. aprsdigi is a digipeater. Both belong in the packet
profile alongside a client, not instead of one.
5. Satellite imaging¶
| Candidate | Source | Availability |
|---|---|---|
satdump |
Blend satellite; AHRL source snapshot |
in Debian |
noaa-apt |
AHRL — RETIRED | not in Debian |
xwxapt |
AHRL — RETIRED | not in Debian |
wxtoimg |
— | not packaged, abandoned |
gpredict |
Blend satellite; AHRL source |
in Debian |
Recommended: satdump¶
The only live option — it handles the LRPT and HRPT services that still transmit, and it is already the agreed supersede target for both retired APT decoders.
There is no real overlap here to resolve. Both alternatives are retired because the NOAA APT satellites were decommissioned on 2025-11-09. This section exists so the reasoning is written down where someone looking for an APT decoder will find it.
Second free snapshot fix: AHRL builds SatDump from SatDump-master.zip while
shipping an unused pinned SatDump-1.2.2.zip. Debian packages it. Prefer apt.
Not competing: gpredict is tracking — where a satellite is and when it
passes. SatDump is decoding what it transmits. An operator needs both.
6. HF data modems¶
Added 2026-09-30 from the gap analysis (catalog-gaps-2026-09.md section B,
Group 3; Q-022 #6). Unlike the five sections above, this one is decided:
Mercury and FreeDATA are carried beside ardopcf in the packet profile.
Availability here is the seven-target apt-cache policy sweep of that day.
| Modem | What it is | Interface it offers | What Pat uses | Licence | Availability |
|---|---|---|---|---|---|
ardopcf |
ARDOP ARQ modem | ARDOP host TCP (8515) and a web view | ardop:// |
MIT | source build, every target |
mercury |
OFDM ARQ modem, FreeDV-derived modes | VARA HF's TCP interface (8300/8301) and a KISS broadcast port | varahf://, unchanged (measured peer to peer, no radio) |
GPL-3.0-or-later | apt on Kali (1.9.13); source build elsewhere |
freedata |
codec2 messaging and file transfer with a browser interface | its own REST and WebSocket API (5000) | none: not a Winlink path | GPL-3.0-or-later | venv from PyPI, x86-64 only |
| VARA HF | closed ARQ modem, Windows | VARA's TCP interface | varahf:// |
proprietary | not carried; post-1.0 Wine prefix, optional |
Recommended: ardopcf or mercury for Winlink, freedata for station to station¶
No single default. The choice is decided by what the station at the other
end runs, because none of these interoperate on the air: an ARDOP gateway
needs ardopcf, a Mercury station needs mercury, a VARA-only gateway needs
VARA. Mercury does not make a VARA gateway reachable; it makes Pat's VARA
transport useful with free software at both ends. FreeDATA answers a
different question, messages and files between two FreeDATA stations with no
Winlink account.
What VARA still buys is the gateways that run only VARA. That is why its
Wine prefix stays post-1.0 rather than being retired, and why it is now
optional rather than the only HF upgrade over ARDOP (SCOPE.md).
Also overlapping, already raised¶
Not in this queue item, but they are the same class of problem and each already has an open question:
| Overlap | Where |
|---|---|
FT8 family — wsjtx / wsjtx-improved / jtdx / mshv |
dispositions.md, NEEDS-DECISION |
Rig control — flrig / grig / wfview / libhamlib-utils |
dispositions.md, SUPERSEDE #5 |
| HamClock clients — four options | Q-006 |
RigExpert analysers — flaa / antscope2 / aa-analyzer |
dispositions.md, SUPERSEDE #3 |
The pattern worth noticing¶
Four of the five recommendations above land on a package Debian already
carries, and three of them (sdrpp, satdump, and the readsb supersession)
eliminate an unpinned master snapshot from AHRL's inventory as a side
effect.
That is not a coincidence. Preferring the packaged option where one exists is
usually also the option with a maintainer, a version, and a signature — which is
why SCOPE.md puts the Blend first in the staging order. The exceptions worth
building a backend for are the ones where Debian genuinely has nothing:
tar1090, YAAC, HAMRS.