Profile: propagation¶
Band conditions, grey line, beacons and DX spotting
Stage: 1.0
Who it is for¶
An operator who wants to know when a band is open, where the grey line is, what the beacons are doing and what the DX cluster has spotted.
At a glance¶
| Stage | 1.0 |
| Units | 12 |
| Disk | about 450 MB |
| Hardware | None. It reads public data and runs on your clock. A radio is useful only to act on what it tells you. |
| Consent | none |
| Install | hammunition install propagation |
What it installs¶
Two HamClock successors — a browser dashboard and a desktop program — each a live map showing the grey line and solar indices; two DX cluster clients, a sun clock, the VOACAP propagation engine with a graphical front end that makes its output readable, a monitor for the international beacon network, and grid-square tools in command-line and graphical form.
Disk footprint: Around 450 MB. pythonprop's cartopy, scipy and matplotlib stack is the largest piece, openhamclock's pruned Node tree is about 140 MB (measured; the build copy under ~/.cache is the same again), and hamclock-next is a source build against SDL2.
Why these belong together¶
Every one of these answers the same question from a different angle: is the band open, and to where. They are grouped rather than spread through the mode profiles because they are genuinely optional — a station that works one local repeater needs none of it — and because most of them depend on web services, which makes this the first profile a low-bandwidth or offline station skips. The beacon monitor is the one to notice. The NCDXF/IARU beacons transmit on a fixed three-minute rotation from known transmitters at known powers in known places, so listening to 14.100 and noting which callsigns you hear is a real measurement of your own antenna and receiver. No website substitutes for that.
Packages (12)¶
openhamclock, hamclock-next, xdx, flcluster, sunclock, voacapl, pythonprop, ibp, wwl, qgrid, python3-pyhamtools, twclock
What it deliberately excludes¶
Nothing that Q-006 chose. Both HamClock continuations ship: openhamclock, the default, is a Node and Vite web application built by the node backend (D-037) and needs Node.js 20.19 or newer from the distribution — Debian 13, Parrot and Ubuntu 26.04 offer it; Ubuntu 24.04's 18.19 does not, and there the plan refuses openhamclock by name (it builds on 18 and its server dies at first start, measured). A refused unit refuses the transaction (D-016), so on 24.04 this profile does not install as a whole — voacapl and pythonprop have no candidate there either — and the operator installs the units that do resolve by name, hamclock-next among them. hamclock-next is the SDL2 rewrite that runs as an ordinary desktop program with no Node involved; an operator who wants the original's look, or no web server on the machine, uses that one. Excludes SPLAT!, which answers "what does the terrain do to this specific path" and lives in antenna.
Install it¶
Read the plan first. It changes nothing and prints every package, build, file and system change, and every consent gate you will meet:
Then do it. The engine asks for your sudo password once, near the start,
and shows the same plan again before it asks you to confirm:
A member your machine cannot take is deferred by name and the rest installs (D-039); the plan lists each under Will NOT happen, with the reason and the command that fixes it. Installation explains how to read every part of the plan.
What you configure by hand afterward¶
A DX cluster client needs a node address and your callsign, and neither is chosen for you. VOACAP needs a smoothed sunspot number for the month you are asking about, which is itself a prediction you supply, and antenna descriptions if you want the answer to be about your station rather than about a default dipole — treating that default as your station is the commonest way to get a confidently wrong answer. openhamclock needs your callsign and grid in its .env (the path is in its package page); it starts with N0CALL at FN31 until you edit it. hamclock-next's data backend defaults to ohb.works, a community-run service, and is user-configurable; nobody has yet run a client end to end against it, so confirm before relying on it. The beacon monitor is a schedule computation, so a system clock a minute out tells you confidently about the wrong beacon.
Your first ten minutes¶
- Check your Node.js version if you run Ubuntu 24.04.
openhamclockneeds 20.19 or newer and the plan defers it by name where the archive's Node is older. - Read the plan:
hammunition install propagation --dry-run. - Install:
hammunition install propagation.hamclock-nextbuilds from source. - Open
openhamclock's.env(its package page gives the path) and replace theN0CALLandFN31defaults with your callsign and grid, then start it and open the page in a browser. - Check your clock: the beacon monitor is a schedule computation, and a clock a minute out names the wrong beacon.
hammunition doctorshows it. - Give your DX cluster client a node address and your callsign. Neither is chosen for you.
- For band predictions, read Propagation and solar conditions before you trust a VOACAP answer; it needs a smoothed sunspot number and your own antenna.
Take it off again¶
This removes what Hammunition itself installed and nothing else. It does not remove dependencies apt pulled in, group memberships or configuration files it wrote; the plan says so and the transaction log records them (D-004).