Each of the four fixes its own breakage​

First the shortest version, with a schoolyard analogy. After that each one is taken apart separately, with a diagram showing exactly what happens to a message.

They are not competitors — they are on different floors​

Comparing Nostr with Reticulum is like comparing Instagram with optical fibre. Here is what each one takes on itself and what it borrows from the existing internet.

Reticulum​

Since 2016 · Python, Reticulum License · by Mark Qvist · rides on LoRa, radio, wire, TCP

A yard with no grown-up in charge. Everyone has their own seal that cannot be forged. A note goes into a sealed envelope and is passed hand to hand. If the recipient has gone home, the envelope waits in somebody's pocket until they come back.

Reticulum is not "yet another messenger" but a complete network stack, written from scratch for channels on which the ordinary internet simply will not start. It does not know what an IP address, a port or DNS is. No central registry: addresses are generated by the nodes themselves, and nobody can either issue them or take them away.

An address (destination) is 16 bytes of truncated SHA-256 of the public key and the application name. To be found, a node throws an announce into the air; transport nodes remember which way to go to reach it, and the path table builds itself. Encryption cannot be switched on — it is already on and cannot be switched off. In detail — in Reticulum up close.

What is inside

• address — 16 bytes (128 bits) of truncated SHA-256 of the key and the application name
• crypto — X25519 for key exchange, Ed25519 for signatures, AES-256-CBC + HMAC-SHA256; ephemeral keys on links, i.e. forward secrecy
• MTU — 500 bytes: not an oversight but design, everything must fit into a LoRa frame
• carrier — LoRa (RNode), packet radio / AX.25, serial cable, TCP, UDP — and even I2P
• offline — LXMF and propagation nodes: mail waits for the recipient
• applications — Sideband (messenger), MeshChat, Nomad Network (something like a BBS)

Pros and cons

• ✓ The only one of the four that survives when there is no internet at all
• ✓ Encryption has no off switch — an "open mode" simply does not exist
• ✓ No need to ask anyone for an address: generate a key and you have one
• ✕ Not anonymous: transport nodes see the destination hash, and announces are public anyway
• ✕ Speed is in kilobytes. A photo will get there, video will not
• ✕ Real autonomy needs hardware: an RNode on LoRa
• ✕ The ecosystem is small, a lot has to be done by hand

I2P​

Since 2003 · Java router and i2pd in C++ · garlic routing · a network in itself

The note is passed through six children, and each knows only two: who gave it and who to hand it to. And the reply goes an entirely different way. Nobody, even if they peek, can put together the picture "this one wrote to that one".

I2P does not hide the content — any TLS hides the content. It hides the metadata: who with whom, when and how much. It does this with two tricks. The first is layers of encryption: a message is wrapped so that each next node peels only its own layer and sees exactly one address — the next one. The second is unidirectional tunnels: the request goes along one chain and the reply comes back along another, so even someone who sees both ends cannot stitch them together.

I2P is most often confused with Tor. The difference is in the goal: Tor is built to exit to the ordinary web (and has centralised directory authorities for that), while I2P is a self-contained network within itself: .i2p sites, torrents, mail, IRC. Exits to the outside (outproxies) are rare here and not the point. And one more thing: Tor has separate relay nodes, whereas in I2P every participant is a router and carries other people's traffic — so your own gets lost among the transit.

What is inside

• address — a Destination (387+ bytes, 516 characters in base64), shown outside as a short base32 hash: ukeu3k5o…q3a.b32.i2p. There is no DNS; human-readable names come from subscription address books
• tunnel — unidirectional, 3 hops by default, rebuilt every 10 minutes
• directory — netDb, a Kademlia-like DHT: RouterInfo (where the routers are) and LeaseSet (where the destination's inbound tunnels are right now)
• transport — NTCP2 (TCP) and SSU2 (UDP), both encrypted and obfuscated
• garlic — several messages ("cloves") are packed into one encrypted garlic envelope
• applications — eepsites, i2psnark (torrents), mail, IRC — all inside the network

Pros and cons

• ✓ The strongest of the four at hiding metadata: who with whom and when
• ✓ No centralised directories — the whole network holds the directory together
• ✓ Everyone carries other people's traffic, so your own does not stand out
• ✕ Slow: hundreds of milliseconds of latency, modest bandwidth
• ✕ For the first 10–20 minutes after start the router "warms up" and carries almost nothing
• ✕ Anonymity is easy to break yourself: just log in to your ordinary account
• ✕ Needs the ordinary internet — it will not run on bare radio

Yggdrasil​

Since 2017 · Go · a world tree of IPv6 · ordinary programs work unchanged

Everyone got their own name that cannot be forged — it grew straight out of a key. And the yard, with no teacher, agreed by itself how to reach everyone: it drew a tree of paths and keeps it in its head.

Yggdrasil solves the most boring and most important question: how to find each other when there is no provider, NAT, public IPs or administrator handing out addresses. The answer: the address is the key. An Ed25519 key is run through a transformation and yields an IPv6 address in the 0200::/7 range. Nobody issued it and nobody can take it away.

Then the network builds a tree (spanning tree) out of all the participants and can find a way to any address, and since version 0.5 it also looks for shorter direct paths instead of sending everything through the root. Neighbours are found automatically via multicast on the local network or configured by hand — public nodes over TCP, TLS, QUIC.

The main practical value: a network interface simply appears in the system. ssh, http, Syncthing, a home NAS — all of it works over Yggdrasil without any changes, as if every device had a public IP. But this is not anonymity: neighbours see both your real IP and your public key.

What is inside

• address — IPv6 from 0200::/7, computed from the Ed25519 key; a /64 from 0300::/8 is given for a subnet
• routing — a global tree (spanning tree) plus path lookup; since v0.5 — direct routes bypassing the root
• neighbours — multicast autodiscovery on the local network or manual peering: TCP, TLS, QUIC, WebSocket
• encryption — end-to-end between the endpoint keys; a transit node carries but does not read
• interface — an ordinary tun in the system: every program just sees IPv6
• control — yggdrasilctl getSelf, getPeers

Pros and cons

• ✓ Nothing has to be rewritten: all existing programs work straight away
• ✓ The address is permanent and your own — neither NAT nor a change of provider moves it
• ✓ The easiest way to "stitch" your devices and your friends' into one network
• ✕ Not anonymous at all: neighbours see IP and key
• ✕ Traffic goes through other people's volunteer nodes — speed depends on them
• ✕ You need at least one neighbour with connectivity; on its own a node gets nowhere
• ✕ The network is still young; routing at large scale is an open question

Nostr​

Since 2020 · "Notes and Other Stuff Transmitted by Relays" · by fiatjaf · WebSocket and JSON

The note is signed with your own signature, which cannot be forged, and copies are pinned to three notice boards. One board is taken down — the note hangs on the other two, and everyone who knows the signature will find it.

Nostr is the simplest of the four and the only one that is not a network at all. It rides on the ordinary internet, over ordinary WebSocket. All it invented is two rules. First: an identity is a secp256k1 key pair, not a row in someone's database. Second: a message (an "event") is JSON with kind, content and tags fields, signed with that key; its id is the SHA-256 of the event itself.

Relays are deliberately dumb servers: accept, store, return by filter. They do not talk to each other — the client itself spreads copies across several relays. That is where all the magic comes from: if a relay bans you, you take another, and your followers do not go anywhere, because they follow a key, not an account on a server.

There is a price for this too. A relay sees your IP and all your events — anonymity here is zero (unless over Tor). Spam is held back only by relay policy, paid relays and a web of trust. And losing the private nsec key is irreversible: there is nobody to "restore access".

What is inside

• keys — secp256k1; the public one is npub1…, the private one nsec1… (bech32 encoding, NIP-19)
• event — {id, pubkey, created_at, kind, tags, content, sig}; id is the SHA-256 of the canonical form, the signature is Schnorr (BIP-340)
• kinds — 0 profile, 1 note, 3 follows, 7 reaction, 30023 long-form
• relay — a WebSocket server with three main commands: EVENT, REQ, CLOSE
• private — old DMs (kind 4) leak metadata; modern ones use NIP-17 on top of NIP-44 encryption
• money — zaps via Lightning (NIP-57): tips right in the feed

Pros and cons

• ✓ Identity does not belong to a platform: followers are tied to the key
• ✓ A relay is up in five minutes, there are dozens of clients
• ✓ Fast and familiar — it is just WebSocket over the ordinary internet
• ✕ Zero anonymity: a relay sees your IP and everything you write
• ✕ Lose your nsec — lose your identity for good, there is nobody to restore it
• ✕ Spam is held back only by relay policy, paid relays and a web of trust
• ✕ When the internet dies, Nostr dies too: it has no transport of its own

The same questions — four different answers​

Nobody wins on all three axes — and that is no accident​

Anonymity is bought with latency, autonomy with speed, convenience with dependence on someone else's infrastructure. Each of the four consciously chose how to pay.

The ratings are qualitative, not measured: they show the direction of the trade-off, not a benchmark. The most interesting thing here is that no dot sits on the right of all three scales.

They stack inside one another​

Since each occupies its own floor, there is no need to choose "either-or". Here are three combinations that really work, and one that will not.

Each can be tried in an evening​

# the stack itself
pip install rns
rnsd

# messenger: Sideband
# (Android / iOS / desktop)
# radio needs an RNode

apt install i2pd
# i2pd console: http://127.0.0.1:7070
# Java router: http://127.0.0.1:7657
# give it 15 minutes to warm up

# package from the project's repository;
# the config appears by itself: /etc/yggdrasil.conf
apt install yggdrasil

# add a public peer to Peers, then:
systemctl restart yggdrasil
yggdrasilctl getSelf   # your own IPv6 is here

# nothing to install:
# Damus — iOS
# Amethyst — Android
# snort.social — web

# nsec1… — straight into a password manager

What problem it solves​

To understand Reticulum, first look at the assumptions the ordinary internet rests on. It is not universal — it is optimised for a particular world. Reticulum is built for the opposite one.

The name is Latin: reticulum, "little net". Its author, Mark Qvist, started from a simple question: what must a network have if you take away providers, address registries, certificate authorities and the assumption that the channel is always wide? It turned out almost everything had to be rewritten — from addressing to the packet format. The author dedicated the protocol itself to the public domain back in 2016; the reference Python implementation is distributed under its own Reticulum License.

Three ideas that hold everything up​

There will be plenty of detail below, but all of it grows out of exactly three decisions.

Identity and address: where <a4f1…> comes from​

The most important five minutes of the whole text: once it is clear how an address comes out of a key, the rest is just consequences.

An identity is two key pairs​

On the first run of any Reticulum application an Identity is created — not a login and not an account, just two generated sets of keys:

The public halves of both keys together are exactly 64 bytes. That is all the network needs to know about a participant.

Then — two rounds of hashing​

Packet anatomy: all 500 bytes​

The packet shows the whole philosophy. When the channel gives 250 bit/s, every header byte is real milliseconds on air and real milliamps from the battery. So the header is indecently ascetic: two bytes of control fields — and straight to the address.

What is inside the first byte​

Eight bits holding everything the stack must know about a packet before it even starts parsing it:

Four packet types — and that is the whole protocol​

How a node is found: announce​

The address is computed — but the network knows nothing about it. There is no DNS, no registry, no server to "sign up" with. There is exactly one mechanism: the node shouts an announce into the air, and everyone who hears it remembers which way to go to reach it.

An announce carries: the destination address, 64 bytes of public keys, the application name hash, a random hash (so two identical announces do not look the same), a signature — and optionally a small piece of application data, such as the name a messenger will show in its list.

Transport: who actually relays​

A detail almost everyone misses: not every node relays other people's traffic. By default a node serves only itself.

For a node to become a transport node, enable_transport = Yes must be set explicitly in its configuration. Such a node takes on the postman's job: it keeps path tables, moves packets from interface to interface and stitches a radio segment to an internet segment. Transport nodes are what turn a set of isolated islands into a network.

Interface modes — a tool few people know about​

Every interface can be given a mode, and that changes how announces spread through it and how paths are built. This is how a narrow radio link avoids being flooded with control traffic from a wide internet channel.

Link: a session with keys that will later vanish​

So far it has been about single packets: encrypt for someone's public key, throw it into the air, forget. That works, but it has a weak spot: if someone records all the air and one day obtains the recipient's private key, they can decrypt everything recorded retroactively. Link was invented against exactly that.

Resources: when there is more data than 500 bytes​

A photo, a file, a page with pictures do not fit in one packet. There is a separate mechanism for that — the Resource. It does not just cut data into pieces: it survives losses without starting over.

Interfaces: what it really rides on​

The stack knows nothing about physics. It only knows an "interface" — a thing that can take a block of bytes and try to deliver it; the rest is driver detail. So one node can hold radio, cable and TCP at the same time, and for the network it is all one seamless fabric.

Hardware: RNode and radio physics​

This is where software ends and things no code can get around begin: the antenna, the terrain and the laws of radio propagation.

What an RNode is​

An RNode is an open radio modem design: a microcontroller plus a LoRa chip, flashed with special firmware. It is built from cheap development boards (T-Beam, Heltec, RAK and others). To the stack it is just a serial device; to its owner, a standalone node that runs on a battery and asks nobody for anything.

Why LoRa hears what "cannot be heard"​

LoRa sends data not as a steady tone but as a whistle of rising frequency — a chirp. The receiver knows the exact shape of that whistle, so it pulls it out even when the signal is weaker than the noise on air. The price is time: the more "stretched" the whistle (the higher the spreading factor), the farther it is heard and the slower data goes. In detail — in the LoRa deep dive.

The numbers are approximate: speed also depends on bandwidth and coding rate, and time on air on the overhead. But the order is right: going from SF7 to SF12 costs roughly a twentyfold slowdown.

How much really gets through​

The most common disappointment looks like this: a LoRa network is up, a photo is sent — and it takes an hour. Here are honest numbers so that does not happen. The size slider shows any case of your own.

The conclusion is not "LoRa is bad" but "LoRa is for text". The long-range mode does not exist to move megabytes but to get a message 30 kilometres across a mountain where nothing else works.

LXMF: mail that can wait for the recipient​

Reticulum by itself has no notion of a "message" — it carries packets. Messengers on top of it speak a separate format, LXMF. That is what makes sure a message waits for a person who switches their radio on once a day.

What Reticulum does not do​

The quickest way to be disappointed in a tool is to expect from it what it never promised.

• ✕ Does not anonymise. Announces are public, destination addresses are visible to transport nodes, and on shared radio you can see who went on air and when. The content is closed, the fact of communication is not.
• ✕ Has no global names. There is nothing like DNS. The other party's address has to come from somewhere: a QR code, a slip of paper, an announcement on air, a shared directory node.
• ✕ Does not guarantee delivery by itself. A guarantee appears only where there is a PROOF or a resource with retries. A packet sent "opportunistically" can simply vanish.
• ✕ Does not carry the ordinary web. HTTP and the browser will not come here: a 500-byte MTU is another world. Instead of the web there is Nomad Network with its own lightweight page markup.
• ✕ Does not replace the everyday internet. Streaming, calls, clouds — no. Text, positions, small files, device control — yes.

And it is not Meshtastic — the most common confusion, because their hardware is the same.

Reticulum and Meshtastic: same board, different ideas​

Both projects are alive and both run on the same cheap boards: Meshtastic gives a ready-made scenario, Reticulum a construction kit. You can try both on one board just by changing the firmware.

Practice: up and running in an evening​

The cheapest way to understand it is to run it. The first step needs no hardware at all: two computers on the same Wi-Fi are enough.

# the stack itself and its utilities
pip install rns

# the daemon: holds interfaces and paths
rnsd

# what the interfaces are doing right now
rnstatus

# the path to an address and how many hops
rnpath <hash>

# ping a transport node
# (it must have respond_to_probes enabled)
rnprobe rnstransport.probe <hash>

# fetch a file from a remote node
rncp --fetch ~/file.txt <hash>

[reticulum]
  enable_transport = No
  share_instance = Yes

[interfaces]

  [[Default Interface]]
    type = AutoInterface
    interface_enabled = True

  [[LoRa]]
    type = RNodeInterface
    interface_enabled = True
    port = /dev/ttyUSB0
    frequency = 867200000
    bandwidth = 125000
    txpower = 7
    spreadingfactor = 8
    codingrate = 5

  [[Public hub]]
    type = TCPClientInterface
    interface_enabled = True
    target_host = amsterdam.connect.reticulum.network
    target_port = 4965

Step 3 — flash a board when you get to radio. Connect the board over USB, then follow the utility's prompts:

rnodeconf --autoinstall

What to put on top​

Glossary​

• Identity — a pair of key pairs (X25519 + Ed25519), a persona. A file worth guarding: it cannot be recovered from anywhere.
• Destination — an address: 16 bytes of hash of the identity and the application name. What you give to the other party.
• Aspect — part of the application name, e.g. lxmf.delivery. Determines who inside the node gets the packet.
• Announce — the "I exist, here is my key" packet. The only way into other nodes' path tables.
• Path — a table entry: "to reach this address, hand it to this neighbour". It has an expiry time.
• Transport node — a node explicitly allowed to relay other people's traffic. Without them the network falls apart into islands.
• Link — a session with one-time keys. Gives forward secrecy, delivery confirmation and resources.
• Proof — a signed proof of receipt. "Delivered" cannot be forged.
• Resource — the mechanism for data larger than a packet: compression, slicing, a hashmap, targeted retries.
• Interface — a carrier driver: AutoInterface, TCP, RNode, KISS, Serial, I2P. The stack essentially does not tell them apart.
• IFAC — an interface access code. Other nodes do not even recognise the traffic as Reticulum.
• MTU / MDU — the packet size ceiling (500 bytes) and what remains for payload after the header.
• LXMF — the message format on top of Reticulum. What messengers actually speak.
• Propagation node — a node that holds encrypted mail while the recipient is offline. It has no keys.
• RNode — an open LoRa modem design: a cheap board plus firmware. To the stack, an ordinary serial device.
• Spreading factor — how "stretched" the radio signal is. Higher means heard farther and slower data.

The speeds here are calculated; specific configuration parameters are worth checking against the project documentation.

What it is — and what it is not​

Meshtastic is firmware for cheap boards with a LoRa radio plus a phone app. A board for 20–40 dollars, flashed straight from the browser, a phone over Bluetooth — and you have a chat that does not know the word "provider".

The key difference from an ordinary walkie-talkie: a message does not have to reach the recipient directly. If somebody else with the same kind of node is between two people, it hops through them. Every participant is both a client and a relay at once — that is what turns a pile of separate radios into a network.

How it works in sixty seconds​

The setup has four parts, and it is easy to mix up who does what.

The node: name, number, role​

The network has no registration and no accounts. A node simply switches on and starts telling the air about itself — and from those stories every neighbour builds its list of participants.

Channels and keys: who reads what​

This is where the most confusion and the most mistakes are: the word "encrypted" in Meshtastic means something quite different from what people usually imagine.

A channel is a "name + key" pair. Everything sent in the channel is encrypted with that key — AES, 128-bit for the default channel, 256-bit for one generated by the app. Whoever has the key reads everything. Channels are shared through a QR code or a link, and the key sits right inside it.

The catch is that the default channel, LongFast, has a public key that is the same for everyone on the planet. That is deliberate: so two strangers who switch on their boards for the first time hear each other straight away. But it means the default channel is a public square, not a private room.

Packet anatomy: 16 + 237​

The radio frame here is limited to 256 bytes. Sixteen of them are header, the rest is payload. That number explains half of Meshtastic's limits.

The flags byte​

Managed flooding — the heart of the network​

Meshtastic has no routing tables and nobody who knows the network map. Instead there is a deliberately primitive rule: heard it for the first time — retell it once. All the engineering is in the word "managed": how to stop that rule turning the air into mush.

Node roles — and why ROUTER is not a compliment​

The role is a single setting that changes how a node behaves on air. And it is the most common way well-meaning beginners harm a network.

This list once also had a REPEATER role — a "mute" relay brick that does not show up in the node list. Since firmware 2.7.11 it is deprecated; masts now get ROUTER or ROUTER_LATE.

Radio presets: far versus fast​

The radio settings here come down to one choice from a list — the preset. The most important thing about it: it is not a quality knob but a shared language. Nodes with different presets simply do not hear each other.

Besides the eight presets on the diagram there is also LONG_TURBO: SF11 on a 500 kHz band, 1.34 kbit/s. The wide band is not allowed in every region, so check your band's rules before using it. What lies behind SF and bandwidth is in the LoRa deep dive.

The air is finite: time on air and duty cycle​

The most important section for anyone who wants their mesh to work. The whole network shares one frequency: while someone transmits, everyone else is silent. And transmission here is inconveniently slow.

The LONG_FAST preset gives about 1070 bits per second. A full packet is 253 bytes, that is over two thousand bits, so one long message occupies the shared air for over two seconds — with the preamble and LoRa's overhead symbols it comes to 2.1 s. And every node that relays it transmits it once more.

Computed with the Semtech formula for LongFast: SF11, 250 kHz bandwidth, CR 4/5, a 16-symbol preamble — which is what Meshtastic uses. You can estimate your own case with the time-on-air calculator in the LoRa deep dive. And each of these numbers still has to be multiplied by the number of nodes that relay the packet.

Telemetry, positions, traceroute​

Most of the traffic in a typical mesh is not people chatting but nodes talking about themselves. It is worth knowing what exactly flies and why.

MQTT: when the mesh climbs onto the internet​

A node with Wi-Fi can become a bridge: everything it hears on air it forwards to a server on the internet — and back. This is Meshtastic's most controversial feature, because it is both the most useful and the most harmful.

Hardware: boards, antenna, solar​

There is no "right" board — there are a few families, each for its own scenario. The difference between them is not speed but how long a node lives away from a socket.

A standalone node on a mast​

The most useful thing you can do for a local network is to raise one node high and leave it there for good. It looks roughly like this:

What Meshtastic does not do​

An honest list, so there are no disappointments. Almost everything here is not a missing feature but a direct consequence of the network being free, infrastructure-less and sharing one narrow frequency.

• ✕ Does not anonymise. A node tells the air its name and number, often its position too. Anyone nearby sees who it is and where.
• ✕ Does not hide by default. The default channel's key is the same for everyone on the planet. Privacy starts only with your own channel or with private messages.
• ✕ Does not wait for the recipient. If a node is off right now, a message for it simply does not arrive. There is a separate Store & Forward module that stores and repeats messages, but it is a feature of a particular node, not of the network.
• ✕ Does not guarantee delivery in a channel. Private messages are acknowledged; group ones fly "as they will".
• ✕ Does not scale without limit. A few dozen active nodes in range — fine. A few hundred — the air runs out, and the network works worse precisely because there are more participants.
• ✕ Does not carry data. No files, no photos, no voice: 237 bytes per packet and a kilobit per second is the ceiling.

And one more thing: the network does not work if the neighbours are set up differently. Region, preset and channel must match — the most common reason for "I see nothing".

Meshtastic and Reticulum: one board, different ideas​

Their hardware is so alike that one board can run one and then the other. But they are tools for different jobs, and confusing them is very common.

Practice: from the box to a chat​

The longest part is waiting for the parcel. The rest takes about an hour.

# node management utility
pip install meshtastic

# which node this is and how it is configured
meshtastic --info

# region — first and most important
meshtastic --set lora.region UA_868

# preset: change only together with everyone else
meshtastic --set lora.modem_preset LONG_FAST

# node names
meshtastic --set-owner "Petro's node" \
           --set-owner-short "PTRO"

# report about yourself less often — saves airtime
meshtastic --set telemetry.device_update_interval 3600
meshtastic --set position.position_broadcast_secs 3600

# join a channel from a link
meshtastic --seturl "https://meshtastic.org/e/#..."

# post to the channel and list the nodes
meshtastic --sendtext "hello"
meshtastic --nodes

# which way packets go to a neighbour
meshtastic --traceroute '!8ab21044'

Glossary​

• Node ID — the node number: four bytes from the board's MAC address, shown as !127a3f19.
• Short name — four characters that label the node on the map and in the list. The long name is for people.
• Channel — a name plus a key. Whoever has the key reads everything in the channel. Shared by QR code or link.
• LongFast — the default channel and preset. Its key is public — it is the common air, not a private room.
• Preset — a set of radio parameters. A shared language: nodes with different presets do not hear each other.
• Hop limit — how many times a packet may be relayed. 3 by default, 7 at most. Every extra hop multiplies traffic.
• SNR / RSSI — how well a neighbour is heard. The delay before relaying is computed from SNR.
• Airtime — how long a packet occupies the air. A full message on LongFast takes over two seconds.
• Duty cycle — the legal limit on the share of time spent transmitting. The firmware enforces it and may not send a message.
• Channel utilization — how busy the air is. The main health indicator of a mesh.
• Role — how a node behaves on air: CLIENT, CLIENT_MUTE, ROUTER, ROUTER_LATE, TRACKER, SENSOR and a few narrower ones.
• NodeInfo — a node's periodic report about itself: number, names, hardware, role.
• Traceroute — the chain of nodes to the recipient and the signal quality on each leg.
• MQTT gateway — a node with Wi-Fi that forwards traffic between the air and a server on the internet.
• Store & Forward — a module on a particular node that stores messages and repeats them for those who were offline.
• PKC — per-node keys (Curve25519, since version 2.5) for private messages: they encrypt between specific nodes and confirm the sender.

Parameter and region names are worth checking against the documentation for your firmware version: the project moves fast.

Three words that keep getting mixed up​

Most arguments about LoRa start with one word being used for different things.

The physics: what a chirp is​

Ordinary radio sends bits by changing something in the carrier: amplitude, frequency or phase. The weaker the signal, the harder those changes are to see against the noise. LoRa does it differently — and that is where all of its "magic" lives.

A chirp is a whistle: a signal whose frequency sweeps evenly from the bottom to the top of the allotted band. One whistle is one symbol. The data is encoded in where the whistle starts: it begins somewhere in the middle, climbs to the top of the band, jumps down and runs back up to the starting point. The starting point is the number being sent.

Switching SF on the diagram shows the key point: the higher the SF, the more possible starting points (2^SF) — and the longer each symbol lasts. The receiver does not have to catch subtle changes of amplitude or phase; it only has to find where the whistle began. And the whistle is spread over the whole band and the whole symbol time, so a narrow interferer does not kill it, while a frequency offset shifts every symbol equally and is easy to compensate.

How the receiver pulls the signal out of the noise​

The most beautiful part. The receiver does not try to "hear a quiet signal" — it adds up all of the whistle's energy over the whole symbol. Random noise does not add up like that.

How big the gain is​

The practical measure of that gain is the minimum signal-to-noise ratio at which a symbol can still be read. Negative numbers mean the signal is weaker than the noise:

Sensitivity is for a typical SX127x-family receiver; newer chips do a few decibels better. Exact numbers are in the datasheet of the particular chip.

Spreading factor — the main knob​

If you turn only one thing in the settings, make it SF. It sets everything: speed, range, time on air and how much battery one message eats.

The rule worth remembering: +1 to SF means a symbol twice as long and roughly +2.5 dB of sensitivity. In free space 2.5 dB is about a third more range. In a city or a forest noticeably less, because there the obstacles matter more than the distance.

Bandwidth, coding, preamble​

The other knobs get turned less often, but each has a price — and this is where the answers to "why can't my neighbour hear me" hide.

Time on air: the formula everything follows from​

Time on air is not just "how long it flies". It is at once battery consumption, the allowed duty cycle being spent and the probability of colliding with someone else's packet. That is why this quantity decides how many nodes a network can carry.

A packet has four parts: the preamble (typically 8 whistles plus 4.25 sync symbols), the header, the data and the checksum. Everything is counted in symbols rather than bytes — and each symbol lasts its 2^SF/BW.

Here PL is the payload in bytes, CR = 1…4 for coding rates 4/5 to 4/8, and DE = 1 when low data rate optimisation is on. Rounding up means the data is always padded to a whole block — which is why one extra byte sometimes costs five whole symbols.

Computed with the formula above: CR 4/5, explicit header, CRC on, 8-symbol preamble. The SF11 · 250 kHz column is exactly Meshtastic's LongFast preset.

Link budget: how many decibels you have to spare​

All radio connectivity comes down to one piece of arithmetic: how much power went out, how much was lost on the way and whether enough is left for the receiver to hear.

By default the diagram shows a typical European link: 25 mW (+14 dBm), +2 dBi whips, 10 km line of sight at 868 MHz. The path eats 111 dB and more than forty decibels of margin remain. That looks like a lot. But in the real world it is eaten by terrain, trees, walls, rain and your own body if you hold the device in your hand: the "obstacles" slider shows how fast. So engineers reserve another 10–20 dB for the unexpected — and that is why a calculated hundred kilometres becomes five in practice. The same arithmetic for your own numbers is in the link budget calculator.

Real range: terrain and the Fresnel zone​

The most common disappointment goes like this: "there is line of sight, but no link". The reason is usually the same, and beginners are almost never told about it.

A radio wave does not travel as a thin beam but as a three-dimensional spindle around the straight line. That spindle is the Fresnel zone, and it has to be clear. If a hill, a roof or a row of trees gets into it, the signal drops even when the antennas formally "see" each other.

The practical consequence: raising the antenna by a few metres often gives more than any radio setting. It does not "add power" — it pulls the spindle out from under the obstacle. That is why one node on a hill changes a network more than a dozen on windowsills. The zone radius for your own path is in the Fresnel zone calculator, and the horizon for your masts in the line-of-sight calculator.

Hardware: what is actually on the board​

A LoRa modem is one transceiver chip plus support parts. All the chirp "magic" is baked into silicon: the microcontroller only says "send these bytes at this SF" and gets the finished result back.

Chip families​

Current figures are approximate, from datasheets; the details depend on supply voltage and amplifier mode.

The antenna — the cheapest upgrade​

No setting gives as much as a proper antenna, correctly oriented and raised. And no mistake costs as much as a wrong one.

The practical consequence of the "doughnut" radiation pattern: a drone right overhead or a node one floor up can be heard worse than the same node a kilometre to the side. And one more thing: the antennas at both ends must be oriented the same way — vertically. One vertical and the other horizontal costs about 20 decibels for nothing. The whip and radial lengths for your frequency are in the Ground Plane antenna calculator.

LoRaWAN: what gets built on top​

The most widespread protocol on top of LoRa. It is built for one scenario: millions of cheap sensors, each waking a few times a day, saying one sentence and going back to sleep for years.

The key idea of the architecture: a device knows nothing about gateways and does not "connect" anywhere. It simply shouts into the air. Whoever heard it forwards it, and the server drops duplicates and works out who it is dealing with. So a device can move between cities without noticing: there is nothing to break, because there is no connection.

Security and adaptation​

Meshes, drones, satellites​

LoRaWAN is the best known, but far from the only thing built on this modulation.

Regulation: duty cycle and power​

LoRa lives in licence-free bands — the same ones used by baby monitors, weather stations and gate remotes. Nobody pays for access, but there are rules, and they are built right into how devices behave.

The main European rule is the duty cycle: the share of time you are allowed to transmit. Typically it is one per cent. That sounds harmless until you count it in seconds: after every transmission you must stay silent 99 times longer than you transmitted.

This is not theory but firmware behaviour: the stack counts the airtime used and simply does not send the next packet until the pause is over. So "the message vanished" sometimes means "the limit is used up" rather than "no signal". The pause for any packet is shown by the time-on-air calculator above.

How it looks by region​

The limits: collisions and network capacity​

The last thing people usually keep quiet about: LoRa has no conductor. Devices transmit whenever they like, and now and then they speak at the same time.

This is called the capture effect, and it is what saves real networks: in real life signals are rarely of equal strength. But it does not cancel the statistics — the more devices, the more collisions, and they grow faster than linearly.

Glossary​

• Chirp — a whistle: a signal whose frequency sweeps evenly through the whole band. One chirp is one symbol.
• CSS — Chirp Spread Spectrum, the modulation itself. What people call LoRa.
• SF · spreading factor — 7–12. How many bits a symbol carries and at the same time how long it is. Each +1 doubles the time.
• BW · bandwidth — 125 / 250 / 500 kHz. Wider is faster, but 3 dB deafer with every doubling.
• CR · coding rate — 4/5 to 4/8. Redundant code against short interference.
• Preamble — a series of identical chirps at the start of a packet that the receiver latches on to.
• Sync word — a byte that separates "private" and "public" networks. Different values — nodes do not hear each other.
• Time on air — how long a packet actually occupies the air. The key quantity in all of LoRa.
• SNR — how much stronger the signal is than the noise. In LoRa it can be negative — and that is normal.
• RSSI — the absolute received signal level in dBm. Together with SNR it shows link quality.
• Sensitivity — the weakest signal the receiver can still decode: from −123 to −137 dBm depending on SF.
• Link budget — power plus antennas minus losses minus sensitivity. How many decibels are to spare.
• Fresnel zone — the spindle around the straight line that has to be clear. Line of sight alone is no guarantee.
• Duty cycle — the share of time you may transmit. Typically 1 % in Europe.
• CAD — a cheap mode in which the chip checks for a preamble on air, spending almost no energy.
• LoRaWAN — a protocol and architecture on top of LoRa: gateways, a network server, classes, two keys, adaptive data rate.

Sensitivity and current figures are typical values from Semtech datasheets; time on air is computed with the Semtech formula. Before relying on them in practice, check them against your chip's documentation and your region's rules.

On 8 December 2023 I built a proper centre: a balun on a ferrite toroid inside a sealed box. And, more to the point of this note, I checked it with an analyser — and then worked out that I had checked something other than what I thought.

Why a dipole needs a balun​

A dipole is balanced: two identical legs about the feed point. Coax is unbalanced: the centre conductor and the braid are not equals. Join one straight to the other, and part of the current that should have gone into the second leg flows instead down the outside of the braid towards the rig.

The cable becomes a third leg of the antenna. On transmit that means a distorted pattern and an SWR that changes when you move the cable. On receive — and a receiver is what I had then — the consequence is nastier: the braid picks up whatever it passes. Switch-mode power supplies, LED lamps, chargers — everything that makes noise in the house lands on the cable and walks into the receiver alongside the wanted signal.

In my case that was not marginal theory. The wire hangs six metres up — not “well away from the house” but directly above it, in the same field of noise. There was nowhere to move the antenna to, so the least I could do was stop the noise taking a second route in, along the cable.

A 1:1 balun breaks that path: it passes the differential current, which is what the whole thing was built for, and opposes the common-mode current, the one that flows on the braid.

What that toroid turned out to be​

The markings on the toroid itself cannot be read: it is wrapped first in white tape and then, all together, in black. Unwrapping proved unnecessary — the markings turned up somewhere else, in a purchase history: an M2000NM K32×20×9 ferrite toroid and PETD2-200 enamelled copper wire, 1.0 mm.

Size. K32×20×9 reads straightforwardly: 32 mm outside, 20 inside, 9 high. My estimate from the ruler in the photograph — “about 35–36 mm” — was three or four millimetres too generous: the winding and the tape add more to the overall size than the eye credits. In Western terms the core sits between an FT-114 (29.0 mm) and an FT-140 (35.6 mm).

Material. M2000NM is a manganese-zinc ferrite with an initial permeability of 2000. The closest Western equivalent is Fair-Rite 77: the same MnZn, the same μ_i = 2000. The guess — “a high-permeability ferrite, not powdered iron” — turned out right, and the core is exactly the class you would choose for this job deliberately.

The winding: 14 bifilar turns. Each turn is two wires laid side by side — the classic Guanella arrangement, where the two conductors form a length of transmission line on a shared core. The numbers agree with the photograph: 14 turns of a pair means 28 passes through the window, a millimetre and a bit each with the enamel, about 30 mm in all against an inner perimeter under the tape of roughly 56 mm. One layer with gaps — exactly what the close-up shows.

The white tape under the winding is not decoration, and it now has two reasons. The first is obvious: a ferrite toroid has sharp edges, and they cut the enamel where the wire bends over the rim. The second arrived with the markings: manganese-zinc ferrite is electrically conductive, its resistivity orders of magnitude lower than nickel-zinc. Laying bare wire straight onto a core like that is not a good idea, even with the enamel intact.

What that gives. The core constant comes from the geometry: mean magnetic path length l_e = π·(32 + 20)/2 ≈ 81.7 mm, cross-section A_e = 9·(32 − 20)/2 = 54 mm², hence A_L = μ₀·μ_i·A_e/l_e ≈ 1.66 µH/turn². On 14 turns that is 0.33 mH — but only if the permeability held at 2000. It does not: in MnZn ferrite μ′ starts falling above a megahertz while the losses rise. For a choke that is no misfortune but the working regime: the impedance simply stops being inductive and becomes resistive. Substituting the complex permeability of mix 77 — which is how the common-mode choke calculator works it out — 14 turns on this core give:

So from 160 down to 10 metres it is three or four kilohms, and from forty metres upwards almost purely resistive. The “few kilohms” benchmark mentioned below is met — though without much margin. And this is a calculation from an equivalent material's data, not a measurement; why that wording stands as final will become clear.

Will it take transmit power. The very losses that make M2000NM a good choke turn into heat on transmit: common-mode current warms this core, and high-permeability MnZn is more vulnerable in that respect than nickel-zinc mixes 43 or 31. In December 2023 the question did not arise — a receiver was connected to the box. But later my first digital contacts went out through this same assembly, so the core did work on transmit, and in a mode where the carrier is held for the whole transmission. It survived. I would still not repeat that blind at a hundred watts: a core for that kind of power gets calculated afresh.

The box​

The enclosure is an ordinary junction box. Through-bolts with washers and wing nuts pass through opposite walls: the antenna legs fasten to them, and they can be tightened in winter wearing gloves, with no soldering iron up the mast. The toroid lies flat, wrapped in black tape. One joint is made with a blue crimp terminal, the rest are under heatshrink.

That is the standard of work one need not be ashamed of, and at the same time the standard that can be reached in an evening out of what is in the drawer.

The measurement​

A NanoVNA, sweeping from 1 MHz, S11 from the cable side. On the output terminals, in place of the antenna legs, a 50 Ω resistor. That matters: what was measured was the assembly itself, not the antenna along with it.

At 3.660 MHz: 51.5 Ω with 198 nH in series, SWR 1.097. Four and a half ohms of reactance against fifty of resistance.

At 14.300 MHz: 50.19 Ω, SWR 1.040. Practically a perfect fifty ohms.

So from 80 to 20 metres the assembly stays transparent: it introduces neither loss nor a shift in impedance that would show at this scale.

And here is the point​

This measurement is not a test of the balun as a balun.

I fed a signal into the cable side and looked at what the instrument saw. It saw fifty ohms. But it would have shown the same fifty ohms had I connected that same resistor through a length of cable — no ferrite required. S11 into 50 Ω measures the differential path: whether the transformer has eaten the match, whether it has losses or stray resonances in the working range. That question has been answered, and the answer is good.

The question a balun is fitted for in the first place — how much impedance it presents to common-mode current — this measurement does not touch at all. Common-mode current flows on the outside of the braid, that is, on the very conductor that does not exist in the S11 setup.

This is not an error of the instrument, nor of the method. It is an error of interpretation, and I made it: I saw an SWR of 1.04 and decided the assembly had been checked. Half of it had.

How to measure it properly​

The common-mode impedance of a choke is measured differently: the two leads on one side are shorted together, the two on the other side likewise, and the impedance between those two points is measured. That is what common-mode current sees on its way. On HF the benchmark is a few kilohms across the working range; less means the braid is still acting as an antenna, just slightly worse at it.

It is done with the same NanoVNA and the same pair of hands. The only difference is where the leads go — and whether you have asked yourself the right question.

What can no longer be found out​

The right measurement — common-mode impedance between the shorted pairs — was never made, and can no longer be made: the assembly is not available for it. The three or four kilohms in the table above remain a calculation from an equivalent material's data. A well-founded calculation, but not a measurement.

The box with its toroid did its job honestly: first quiet reception, later the first digital contacts. The one thing left undone was a single measurement — precisely the one the instrument had been taken out for.

And that is probably the thing worth taking from this note. The instrument was in hand, the assembly on the bench, time was unlimited. Only one thing was missing: the right question. Next time the list of what to measure gets written before the leads touch the terminals.

What exactly I was building​

“JUNIOR” is a kit by Serhii Belenetskyi, US5MSQ: a beginner's HF receiver for two bands, 80 and 20 metres. A receiver only: there is no transmit path in it at all — an antenna at the input, headphones at the output, and nothing going back on the air. I read his article about building it and bought the kit directly from him.

Choosing a kit rather than my own design from scratch was deliberate. A first receiver has one trap: it stays silent, and it is not clear why. The circuit? The assembly? The components? The antenna? Propagation? A ready kit crosses the circuit and the components off that list. What remains is my soldering and my antenna — exactly what I wanted to learn.

The circuit in one paragraph​

A single-conversion superheterodyne. The antenna signal passes through an adjustable attenuator and a two-pole bandpass filter into the first SA612 mixer. The local oscillator is a VFO at 8.5–8.8 MHz for 80 metres or 9–9.35 MHz for 20; a relay switches the bands. The 5 MHz intermediate frequency goes through a four-crystal filter 2.4 kHz wide, is amplified by a single transistor stage, and reaches a second SA612 working here as a product detector with a 4998 kHz carrier oscillator. Then an LM386 and the headphones. Tuning is by varicap from a potentiometer — the knob turns a voltage, not a capacitor.

These are the author's figures from the description, not my measurements. I did not yet know how to make my own.

Three evenings with a soldering iron​

12 November 2023, the bare version 2.5 board. Double-sided glass-epoxy with mask and full silkscreen: every position is labelled, nothing has to be hunted for. Both mixers, in SOIC packages, were already on the board — the author solders the SMD parts himself, and for a beginner's kit that is the right decision: the finest work is already done, and everything left can be soldered with an ordinary tip.

The author's order: resistors and capacitors first, then the chokes L1–L4 standing 1–1.5 mm above the board, L6 vertically, then connectors, the relay, the transistors, and the integrated circuits last.

The 1–1.5 mm requirement looks like pedantry one is tempted to ignore. Do not: L1–L4 are not “supply-rail chokes” but the inductors of the input bandpass filter. How high they stand above the solid ground plane goes into the tuned circuit along with them.

By 14 November the board was assembled. The four filter crystals ZQ1–ZQ4 lie flat in a row down the middle; the fifth, the carrier crystal, sits apart beside coil L6. The only chip in a socket is the LM386, and that too makes sense: if a beginner burns something out, it will be the audio amplifier.

17 November, the connectors. All external wiring goes to screw terminals, with no wire soldered straight into a hole: the board can be lifted out of the case without switching the iron on. At a stage when you do not yet know what will need checking, that saves you.

Alignment: four steps and a screwdriver​

Here is where a kit from its designer differs from “built from a magazine article”. The whole procedure is written as a sequence in which each step is verified before the next.

1. Operating points. Voltages at the test points, tolerance ±10 %. If one is wrong, you cannot go on, because the remaining steps measure its consequences.
2. Carrier frequency. Set trimmer C37 to 4998.00 kHz. This is the adjustment that decides how people sound: the crystal filter stands still, and where the audio zero lands within its passband is set by the carrier oscillator. An error of a couple of hundred hertz does not break reception — it makes voices either nasal or thin.
3. Setting the band edges. On 20 metres the top edge with the core of L5 and the bottom with resistor R9; on 80, the bottom edge with trimmer C15.
4. Input circuits. On 80 metres, trimmers C6 and C14 for maximum signal around 3650 kHz; on 20, C4 and C13 at 14150 kHz.

No instruments beyond the digital display were needed: it is also the frequency counter.

The case​

28 November, into the case. The board stands on pillars in the far corner, with the A16-PLL digital display in front of it. The panel holes are marked out from a template supplied with the kit, and a self-adhesive fascia goes over the top. It looks incomparably better than my metalwork deserves — which is exactly why the template is in the kit.

The green PLL TUNING lamp is the display's automatic frequency control. The VFO here runs on a coil and a varicap, and it drifts: for the first few minutes after switch-on the frequency moves noticeably. The display not only shows the frequency but also pulls the oscillator back, and with it the set stays on a station for as long as the station is talking.

What it draws​

12.8 V, 0.06 A. Sixty milliamps including the display — which fits the specification: the author quotes 30 mA on 80 metres without the display, plus up to 40 mA for the display itself.

The figure matters not in itself. A receiver with that appetite runs a day from a power bank and does not care whether the mains is on.

The antenna: forty metres of twisted pair​

The most interesting thing in this story cost less than the connectors on the back panel.

Two legs of twenty metres each, ordinary twisted pair, six metres up. Forty metres of wire in all.

Now let us work out what came of it. At 3.605 MHz a wavelength is 83.2 m and a half wave 41.6 m; with the shortening factor applied, a real resonant dipole comes out at about 39–40 m. So “just the wire that happened to be there” turned out to be almost exactly a half-wave dipole for 80 metres. The resonance happened by itself, with no intention on my part.

Six metres of height is 0.07 of a wavelength. By any textbook that is “low”, and by any textbook that is bad. For what I wanted to hear it is exactly right. An antenna's pattern does not care which way the signal is travelling: a dipole that at this height would radiate almost straight up equally hears mostly from above. And what comes from above on 80 metres is whatever bounced off the ionosphere close to vertically — stations thirty to a hundred kilometres away. That is precisely the distance at which the regional roundtable's members sit.

The angle is easy to work out. In the morning on 3.6 MHz the signal is turned back by a layer two to three hundred kilometres up; for a correspondent a hundred kilometres away that is an arrival angle of about eighty degrees above the horizon, and for one thirty kilometres away, practically vertical. The closest are also audible by ground wave, which on 80 metres reaches a few tens of kilometres, but the rest arrives from exactly there — from above.

And here is where the advice “hang it higher” hides its catch. That advice is about DX, that is, about low angles, and to get them on 80 metres a dipole has to go up half a wavelength — forty metres. At exactly that height a null appears at the zenith, and such an antenna hears a neighbour thirty kilometres away worse than mine at six. All I lost by hanging it low is not direction but efficiency. In English this mode is called NVIS, and my antenna is a textbook case of it, arrived at with no intention whatever.

Ground losses under a wire that low are appreciable. On receive that barely matters: on 80 metres the floor is set not by the receiver but by atmospheric noise, and that arrives through the same antenna. The losses attenuate signal and noise alike — the ratio between them does not change.

On 20 metres the same wire is 1.9 wavelengths: a multi-lobed antenna, sensitive to low angles. So 14 MHz comes in as well, except that the antenna chooses the directions for itself rather than for me.

The roundtable​

The Volyn Radio Amateurs League meets every Sunday at eight in the morning on 3.605 MHz.

24 December 2023, 8:43, a Sunday. The display reads 3.605.00, and beside it an open notebook in which I wrote down the callsigns as they were spoken: UR3PD, UR4PWL, UT1PA, UR3PF, UT1PQ, UR3PBW. Lower on the same page, a line reading “750th anniversary”: the roundtable does not talk only about equipment.

That was the moment the whole thing was for. Not “the receiver works” — it worked on empty hiss too. But when voices came out of the headphones calling each other by name and arranging the next Sunday, it became clear that the wire outside and the box on the table were connected to something alive.

What I took from it​

Selectivity is made of hardware. The 2.4 kHz bandwidth is set by the crystal filter, and it cannot be “adjusted”. Narrow or wide was decided when I laid four crystals in a row.

The carrier frequency decides how people sound. One trimmer, two hundred hertz, and the timbre of the whole band is different. Before JUNIOR I thought sidebands were a matter of theory.

The attenuator is not decoration. In the evening on 80 metres a strong neighbour overloads the front end, and the RF knob is needed not “just in case” but every evening.

Stability is an engineering problem of its own. A VFO on a coil and a varicap drifts, and no quality of soldering fixes it. What fixes it is automatic frequency control — digital laid over analogue.

The antenna is half the receiver. Forty metres of twisted pair six metres up gave more than any amount of trimmer-turning inside the box. That is the cheapest lesson of the lot, and the most important.

What it does not do​

To be honest, so that nobody buys the kit with the wrong expectations:

• it does not transmit — it is a receiver, full stop;
• one bandwidth for every occasion: no narrower filter for Morse, and no wider one;
• no S-meter, so a correspondent's strength is judged by ear;
• two bands, 80 and 20, and nothing else.

These are not complaints. They are the boundaries at which the next set begins — and that is exactly why the next one on my bench is a direct-conversion receiver, built from scratch, with no kit and no one else's board.

Sources​

• Radio kit: the JUNIOR receiver for the beginning short-wave listener — description, circuit design, assembly order and alignment by the author, US5MSQ.
• Volyn Radio Amateurs League — the frequency, day and time of the regional roundtable.

In short: the first two say how much the Sun is giving out (and therefore how dense the ionosphere is), and the last two say how quiet the Earth's magnetic field is (and therefore whether a storm is choking that ionosphere).

Below is a full account of each index: what it means physically, how to read it, what it affects and when it is worth getting on the air. Beside each section there is a live gauge that pulls the current value from NOAA and shows where we stand.

Note that the colours run in opposite directions: SFI and SSN turn green upwards (more light, better conditions), while K and A turn green downwards (quiet is better for the low bands). That is not a whim but physics, and it is explained below.

Two pairs of indices​

It helps to hold all four in your head as two pairs, because they answer two different questions.

Solar (what the Sun is giving):

• SFI — the Sun's radio flux at a wavelength of 10.7 cm;
• SSN — the number of spots on the solar disc.

These decide how dense the F layer of the ionosphere is, and therefore whether the high bands (10–20 m) will open.

Geomagnetic (what is happening at the Earth):

• K index — the highest geomagnetic activity over 3 hours;
• A index — the average geomagnetic activity over a day.

These decide whether a magnetic storm will blow that ionosphere away, and therefore whether the low bands (40–160 m) hold up.

The ideal condition for HF is a high SFI and a low K. Now each index in turn.

SFI — the solar flux index​

What it is. The solar flux index is the power of the Sun's radio emission at 2800 MHz (a wavelength of 10.7 cm), measured by the observatory at Penticton, Canada, and published by NOAA. The unit is the sfu (10⁻²² W·m⁻²·Hz⁻¹). It is a convenient proxy for ionising ultraviolet: the brighter the Sun shines at 10.7 cm, the more it ionises the F layer.

Hence the main rule: the higher the SFI, the denser the ionosphere and the higher the ceiling (the MUF — the highest frequency the ionosphere will still reflect).

The current SFI, right now:

How to read it:

• 60–80 (red, “poor”) — solar minimum. The high bands (10–15 m) are dead; 20–40 m work, and even then unreliably.
• 80–100 (yellow, “middling”) — moderate activity. 20 m works decently, 15 m opens from time to time.
• 100–250 (green, “good”) — a high SFI. 10, 12 and 15 m open, and long DX paths on HF come alive.

What it affects. Chiefly the high bands (10–20 m). There the SFI decides whether there will be a contact at all. On the low bands (40–160 m) the SFI matters little — there it is geomagnetic quiet that rules.

In practice: once the SFI reaches about 100 it is worth trying 10 and 15 m; at 150–200 you can count on transcontinental paths on the high HF bands all day long.

SSN — the sunspot number​

What it is. The sunspot number (the Wolf number) counts the groups and the individual spots on the solar disc, weighted by size. Spots are regions of heightened magnetic activity, and they radiate more ionising energy.

Why it tracks the SFI. Spots and the 10.7 cm emission are both products of solar activity, and they are related almost linearly (a correlation above 90 %). So reading the SSN largely repeats the SFI, but it states the number of spots on the Sun directly, which many people find more vivid.

The current SSN, right now:

How to read it:

• 0–30 (red, “minimum”) — solar minimum. The high bands barely work.
• 30–60 (yellow, “moderate”) — activity rising; 15–20 m are steady.
• 60–250 (green, “high”) — an active Sun, good HF conditions, frequent flares and storms.

What it affects. The same as the SFI: the density of the F layer and the high bands. The SSN swings through the eleven-year solar cycle: at the peak it can run into the hundreds, at the minimum it falls almost to zero.

In practice: watching the SSN tells you where in the eleven-year cycle we are — whether activity is rising or falling.

The K index — geomagnetic activity over 3 hours​

What it is. The K index measures the disturbance of the Earth's magnetic field as seen by individual observatories. The planetary Kp averages them worldwide. The scale is logarithmic, from 0 (completely quiet) to 9 (an extreme storm), in thirds of a point.

Every 3 hours NOAA issues a new Kp — the fastest pulse of the geomagnetic state you get.

Why it matters on HF. A magnetic storm disturbs the lower ionosphere (the D layer) and chokes propagation on the low bands. The higher the K, the worse conditions get, especially on 40–160 m and on polar paths.

The current K index, right now:

How to read it:

• 1–3 (green, “quiet”) — ideal. The low bands are at their best.
• 3–6 (yellow, “unsettled”) — moderate disturbance. 40 and 80 m are somewhat worse; on the high HF bands it is barely noticeable.
• 6–9 (red, “storm”) — a magnetic storm. 40–160 m are heavily suppressed, aurora is possible, and polar paths collapse entirely.

In practice: Kp ≥ 5 is a signal that the low bands will be poor; Kp ≤ 2 is the best time for 40, 80 and 160 m.

The A index — geomagnetic activity over a day​

What it is. The A index is a daily roll-up of the K index. Each three-hourly K is converted into an “equivalent amplitude” (a), and the eight intervals of the day are then averaged. The result is a linear scale from 0 to a few hundred, which compares one day with another more conveniently than the logarithmic K.

How to read it:

• 0–40 (green, “quiet”) — the magnetosphere is in good shape, HF is normal.
• 40–100 (yellow, “unsettled”) — disturbed; the low bands are noticeably worse.
• 100–400 (red, “storm”) — a strong storm; 40–160 m are effectively closed.

The current A index, right now:

What it affects. The same as the K index, but on a daily scale. The difference is speed: K catches the short shove of a storm, A shows what the day was like as a whole.

In practice: the A index is useful when going back over logs — it makes it easy to see which day was geomagnetically quiet.

Two kinds of index, two directions of colour​

Look at the zone scales once more and remember the central symmetry:

The practical conclusion: the best conditions come when the SFI is high and the K is low. That combination is what gives you open high bands and working low ones at the same time.

Where the data comes from​

The live gauges and all the zone thresholds take their data from NOAA's open sources:

• SFI and SSN — the daily table daily-solar-indices.txt;
• K index and A index — the series noaa-planetary-k-index.json (updated every 3 hours).

The zone boundaries for the SFI (green begins at 100) and for the K index (quiet from 1 to 3) follow the way these indices are usually shown on DX clusters.

What to watch next​

Once these four numbers make sense, so does a propagation forecast:

1. Look at the SFI: if it is 100 or more, try the high bands (10–20 m).
2. Look at Kp: if it is 2 or less, take on 40–160 m without hesitation.
3. Compare the A index with the day before: if it has doubled or tripled, the magnetic background is deteriorating — wait.
4. When going through a log, remember: the number of contacts depends more on the calendar (weekends) than on the Sun, whereas the high bands depend on the SFI exactly as described.

The interesting part is not that it works. The interesting part is how many ways there are to get it wrong, none of which announce themselves with an error.

The signal path​

sound card (48 kHz)
   → AudioWorklet → ring buffer
   → resample to 3200 Hz with a filter
   → FFT 256, periodic Hann window, reflect padding
   → spectrogram, 65 bins over 400–1200 Hz, log1p
   → squelch: is there a tone or not
   → ONNX: 8 seconds of audio → per-frame distributions
   → greedy CTC decoding
   → stitching onto the previous window

An eight-second window is taken every two seconds, so neighbouring passes share six seconds of audio. That is the main difficulty, but more on it below.

The browser spoils the audio by default​

A microphone input arrives with three “improvements”: echo cancellation, noise suppression and automatic gain. For a weak Morse signal each of them is fatal, and the worst is noise suppression: a steady tone is literally the thing it knows how to remove.

audio: {
  echoCancellation: false,
  noiseSuppression: false,
  autoGainControl: false,
}

The second problem from the same family: capture lives in an AudioWorklet, not on a timer. In a background tab timers are throttled to roughly one firing a minute, while a real-time audio stream is not throttled at all. On a timer, the decoder would work only while somebody was looking at it.

The preprocessing is not a matter of choice​

The network learned one particular input, and every constant here is taken from its metadata rather than chosen: a periodic Hann window (hanning(N+1)[:-1], not hanning(N)), reflect padding of 128 samples, bins 32…96 at 12.5 Hz per bin, log1p.

A spectrogram that differs from the trained one by a window or half a bin does not degrade gracefully — it produces confident nonsense. The most treacherous part is the padding: numpy's reflect does not repeat the edge sample, so [1,2,3] becomes [3,2,1,2,3,2,1]. Getting that wrong shifts every frame by half a window and costs you the first letter of every decode.

That is why the project has scripts/check-dsp.ts: it synthesises Morse with known text, runs it through the real sample rate, the real resampler and the real spectrogram, and then asks the model what it heard. Unit tests of the transform alone are not enough for this.

Resampling that must not be done naively​

The model author's example changes the rate by linear interpolation alone — and says so plainly: it is an example with minimal dependencies, and the documented way to prepare audio there is ffmpeg, which filters first.

Copying the interpolation alone would fold everything above 1600 Hz back into the band the model looks at, and a card delivering 48 kHz has plenty up there. So the filter ffmpeg would have applied is applied here: a 255-tap windowed sinc, Blackman window, cutoff 1400 Hz — below the Nyquist of the target rate and above the 1200 Hz the network reads.

The kernel is evaluated only at the positions actually needed, so the cost scales with the output rate rather than the input: about 1.6 million multiply-accumulates per second of audio.

Why CTC, and why greedy decoding​

The model is trained with CTC, so the output is one distribution per 15 ms frame over 41 symbols plus a blank. The best path is read greedily: take the most likely class in each frame, drop the blanks, collapse runs of identical symbols.

This is not the best decoder available — a beam search with a language model would read better. But a Morse decoder that quietly invents plausible words is worse than one that prints what it heard. Predictable behaviour is worth more here than a few percent of accuracy.

The most expensive mistake: stitching the windows​

Neighbouring windows share six seconds of audio, so they share text as well. But not the same text: the shared seconds get decoded afresh and come back a letter or two different. So comparing for equality does not work — one discrepancy inside the overlap and the whole window is appended a second time.

That is exactly what turned the first live decode into EN35UKR PSE K, repeated fifteen times over.

The working solution is to find the overlap by agreement rather than equality: the longest tail of what has already been printed that matches the head of the new window on at least 75 % of its characters.

And the other half of the same problem: the search width has to be bounded by time, not by a round number of characters. An operator calling CQ repeats the same text every fifteen seconds, and a search wide enough to span two calls will happily merge them into one and lose a transmission.

Silence that reads as text​

Left to itself, the model reads noise as a stream of E, I, T and S — the shortest patterns in the alphabet. Something has to be the most likely class in every frame, and noise looks more like a short element than a long one.

This decoder behaves that way, and so do the commercial phone apps. The only difference is whether the result is shown to the operator.

Telling one from the other takes a single number: how far the strongest spectral bin rises above the typical one, averaged over the window. A carrier is narrow and steady; noise is neither. There is no dependence on absolute level anywhere in this, which is why it works equally well from a cable off the rig and from a microphone held to a speaker.

The threshold was not chosen but measured: noise sits around 1.5, even a deeply buried signal does not drop below 3, so the line is drawn at 2.5 — deliberately low. Losing a real transmission is worse than printing a little rubbish.

Two stations at once​

The model has one output and cannot follow two senders: given both, it produces text belonging to neither.

But its entire view of the world is the spectrogram. So zeroing the bins away from the wanted tone is exactly the same as filtering the audio, and it costs one pass over an array.

With two synthesised stations 350 Hz apart, together they decoded as C?Y06IXA3PKI K; with everything outside ±100 Hz zeroed, as CQ CQ DE UR3PKI K and TEST DE DL6LD K, both word for word.

Shifting the analysis window instead does not work: it spans 812 Hz, and a neighbour a few hundred hertz away stays inside it.

A line not to cross​

The decoder never writes to the log by itself.

In FT8 automatic logging is justified: there is a checksum, and a false decode is practically impossible. Morse has no checksum at all — the software cannot tell UR3PKI from UR3PKJ if the last dot drowned in a fade.

The most that is allowed is to drop a callsign into a field visibly marked as the decoder's guess. The reason is not technical but substantive: a log is a record of what happened on the air, and one invented callsign in it costs more than all the convenience of autofill.

Why this is a separate project​

The model comes from e04/deepcw-engine under AGPL-3.0. That licence extends to software provided over a network, so the source has to be available to everyone who opens the page.

That is why the decoder lives in its own repository, PetroOstapuk/cw-decoder, rather than as a page inside the platform: the licence condition is then met in full, and the platform's own code remains separate work.

To see how the alphabet itself is built, look at the code tree; to work out how long a dot lasts and how much bandwidth the signal takes, use the timing calculator.

It is in fact a binary tree, and in that form you can see the engineering decision taken in the 1840s: the frequency of a letter sets its depth. E is one dot, T one dash, because those are the commonest letters in English. Q, J and Z sit all the way down on the fourth level. Alfred Vail arrived at this not by theory but by counting: he counted the letters in the type cases of a local newspaper.

A variable-length code, allocated by symbol frequency. A hundred-odd years before Shannon and Huffman explained why that works.

The tree​

Left is a dot, right is a dash. The four letter levels are completely filled — there are no free nodes. The digits are longer than any letter and sit a level below.

Two things are immediately visible here that the table hides.

Frequent letters sit close to the root. Not roughly but systematically: the diameter of a pad here is the letter's frequency, and the largest ones have gathered at the top.

A dash costs three times a dot. So the depth of a node and the cost of a letter are different things: O (---) sits on the third level, as does S (...), but it takes more than twice as long to send — eleven units of time against five. The timing diagram under the tree shows this directly.

How well Vail aimed​

The correlation between a letter's frequency and the duration of its code — Spearman's rank correlation — comes out strong and negative. For work done by counting letters in type cases, that is almost indecently good.

The exceptions stand out on the chart. The loudest is O: the fourth commonest letter in English has the longest code the third level can offer.

Why this is not a Huffman code after all​

Here it gets interesting, because the analogy “Morse is Huffman” is pleasing and wrong, for two separate reasons.

Morse is not a prefix code. E is . and I is .. — the code for one letter is the start of the code for another. A prefix code forbids that, and it is precisely the prohibition that lets a stream be decoded without separators. Huffman always produces a code where symbols sit only at the leaves; in Morse a symbol sits at every node, internal ones included.

That is why Morse cannot be sent as a continuous stream: between letters there must be a gap three units long. So the alphabet is not binary at all but ternary — dot, dash and gap — and it is the gap that carries what the shape of the tree carries in Huffman.

And optimality is not measured the same way. Huffman minimises the number of symbols, on the assumption that every symbol costs the same. In telegraphy a dash costs three times a dot, so what has to be minimised is time, not the count of marks. That is a different problem — coding with unequal symbol costs — and it was not solved until 1961 (Karp, via integer linear programming), with workable approximations later still.

In short: Morse is not Huffman and was never meant to be. But the question “how close is it?” remains a fair one, and it can be answered exactly.

What the allocation error costs​

Let us compare fairly: take the same twenty-six codes and hand them out to the letters in the best possible way — the cheapest code to the commonest letter, and so on down. That this really is the optimum follows from the rearrangement inequality: no other allocation gives a shorter mean time.

Seven percent. So an allocation made in the 1840s by eye and by ear loses to the exact optimum for the same set of codes by less than a tenth.

The table shows where the time goes, and O heads it by a wide margin: eleven units where there should have been five.

But Vail cannot be blamed for it. The code we have just taken apart is not his. American Morse had different codes for a good dozen letters and used gaps inside symbols (O was sent there as two dots with a wide space between them). In 1848 Friedrich Gerke reworked it for the Hamburg telegraph line — he removed the internal gaps and evened out the lengths. In 1851 the German-Austrian Telegraph Union adopted that revision, and the international alphabet grew out of it.

So the frequency optimisation was Vail's, while the particular allocation we are measuring is Gerke's — and his aim was regularity, not the shortest time. Seven percent is what that regularity costs.

And a practical conclusion, the opposite of what you would expect​

The tree explains why the alphabet is the way it is. But you must not learn Morse from it.

Anyone who traces a finger down the tree while a transmission runs in the headphones is putting counting where hearing should be: heard → counted → recalled. That intermediate step hits a ceiling around ten words a minute, and unlearning it afterwards is harder than learning properly from scratch. The method that works is Koch with Farnsworth: characters at 20–25 WPM from the very start, only the gaps stretched, and no table in front of you.

The tree is a good answer to “how does this work” and a poor answer to “how do I learn it”. They are different questions, and confusing them costs six months.

An open question I am leaving for later: everything counted above is for English letter frequencies. What a code optimised for someone else's language costs a Ukrainian operator, and what the same table looks like for the Cyrillic Morse alphabet, is a subject for another time — and one to begin by checking the Cyrillic table against a primary source rather than against memory.

On 6 March 2026 I showed it running for the first time — from my own laptop, through ngrok, with a link that lived until midnight. Even then it kept a shared log, accepted contacts from WSJT-X over UDP, imported ADIF with duplicate checking, and had separate dashboards for hunters and for organisers. The next evening the bridge for digital modes appeared — for Windows, Linux and macOS.

In April, seven weeks after that demonstration, the special callsign EN40CNP was on the air for the 40th anniversary of Chornobyl. Two weeks, 1565 contacts, several operators — and the whole log was merged by hand: the platform was not yet ready for real use. Vitalii, UT0UI, put the experience most precisely: “merging logs after the fact by hand is a right pain”.

By August it was ready. What follows is what came of it: the platform uahamaward.com, on which the “35th anniversary of Ukraine's independence” award made 17,387 contacts in 31 days, and not one of them was merged by hand — neither during the month nor after it.

The problem first​

Everyone keeps their own log. Then it all gets merged into one file. Then it turns out two people were working the same band and mode at the same time. Then somebody has lost their ADIF. Then LoTW refuses the duplicates.

At 1565 contacts that is a few evenings. At seventeen thousand it is no longer work but an impossibility.

Four requirements​

For the August activity I set myself not the task of “building a site” but four specific pains to remove.

1. Two people must not land on the same band and mode at once. Somebody has to see who is on the air and where — and see it now, not afterwards.
2. The log must be shared and live. Not a file at the end of the month but a table everyone sees in the same second.
3. The certificate must count itself. Conditions, points, number, PDF — with no human in the loop.
4. The ADIF that comes out must be accepted by LoTW and QRZ without edits. Not “almost the right format” but one that goes in first time.

What the platform does​

This is not a site with a table. It is several separate programs that work together — and each can be used on its own.

A shared log: everyone sees the same thing, now​

An operator opens the activator panel, presses “go on the air”, picks a band and a mode — and that slot is taken. The rest of the team sees it instantly, with no page reload: who is sitting where, on what frequency, in what mode.

• Every contact appears in the shared log within a second.
• Duplicates do not get through. The same correspondent, band, mode and minute will not be written twice — even if two tabs send them simultaneously. That is not rare: one program sends to two tabs, and both try to write.
• A session someone forgot to close shuts itself after an hour without contacts, so a band is not held by somebody who simply closed their laptop.
• A mistake in the log can be corrected or deleted; the edits are visible to everyone.
• The event page and the hunter page are public, with no registration: anyone can watch the activity and their own progress.

CAT: the radio straight from the browser​

Connect the radio over a COM port and the site fills the frequency and mode into the contact form by itself. Nothing has to be installed: it works in the browser.

• Frequency and mode are read from the radio rather than typed.
• VFO and band control from the same page.
• 172 models out of the box: Icom, Yaesu, Kenwood, Elecraft, Ten-Tec, Xiegu, FlexRadio, Alinco, JRC, AOR, Elad, Expert Electronics. The profiles come from the OmniRig format, so a radio not on the list is added with a description file rather than by rewriting code.
• If you do not need CAT, just pick the band and mode by hand; everything else works the same.

The bridge: WSJT-X writes to the log by itself​

A small program on your computer: it catches packets from WSJT-X and puts the contact straight into the award log. Make a QSO and it is already in the shared table, where the rest of the team can see it.

• Seven builds: Windows, Linux, macOS (x86 and ARM) — downloaded from the page and started with a double click.
• It updates itself, but only when you press the button: the bridge holds the port WSJT-X knows about, and an unexpected restart in the middle of an activation means lost contacts.
• Settings in a browser window, not on a command line.
• It forwards the packets on, so JTAlert, GridTracker or N1MM work alongside it. WSJT-X can only send to one address, which is why you previously had to choose just one.

Custom builds of WSJT-X and WSJT-Z with a country filter​

Two builds of the popular digital-mode programs, with what the originals lack.

• A country filter at the decoder level. You pick countries from the DXCC list: hidden stations do not appear in any window, and the program will not answer them even on a direct call. Unlike the existing filters it works by country rather than by text match — “Japan only” catches every prefix at once.
• A direct link to the platform. Log a QSO and it is on the award page immediately. No separate bridge needed.
• A Ukrainian interface: menus, settings, tooltips, errors. Mode and band names stayed in English — that is what people are used to.
• Callsign data from QRZ.com right in the program window.
• Along the way a bug in the inherited code was fixed: filtering out one signal made every subsequent signal in the same period disappear.

Spotting: announcements to the DX cluster​

From the log page, in two clicks — or automatically while you work.

• Manual spots and an automatic mode with a timer.
• The timer knows the node's rules, so you will not be refused for repeating. And it knows that after a frequency change you may spot immediately.
• A spot feed on the log page: other people's and your own, with the author's callsign.
• A cluster monitor of our own — like dxheat, but ours.

Certificates: counted, numbered and assembled automatically​

The organiser describes the conditions in the award settings, and the platform does the rest.

• Conditions: a minimum number of contacts or points, separate conditions per mode and band, several groups of conditions at once.
• Special days. A multiplier can be assigned to particular dates — for us those were 23 and 24 August. The multiplier applies to the score rather than to a log line, so the holiday rewards three bands rather than three hundred calls on one.
• The certificate number is your place in the log. The queue is worked out from contact dates, not from who pressed “download” first. And every condition has its own numbering.
• The PDF is generated in two languages — whichever one the hunter opened the site in.
• An ADIF that arrives a week later takes the place in the queue its dates have earned: the roll is recomputed from the log.

QSL cards — electronic and for printing​

• An electronic QSL for each contact individually: the hunter opens their page, hovers over a “band × mode” cell, and downloads the card for exactly that contact.
• A 140 × 90 mm layout for printing, if paper cards are being ordered.
• Nothing has to be written out by hand — in August that produced 62 certificates and all the cards.

ADIF: import, export, and what LoTW accepts​

• Import of files up to 20,000 records with a progress bar — a full month's log goes in within 15–20 seconds.
• An export that QRZ.com and LoTW accept without edits: the right format version and correct submodes (ADIF does not know “FT4” as a mode — it is a submode of MFSK, and that is how it gets written).
• Frequency is in kilohertz everywhere — in the form, in the session, in the bridge. On output it is converted as it should be, so a contact does not end up 430 Hz away from where the other station logged it.
• A daily copy of the whole log emailed to the organisers — from once to eight times a day.

QRZ.com: contacts upload themselves​

If you have an XML Logbook Data subscription on QRZ, paste your logbook key into the settings and there is nothing more to do. The platform uploads every contact you make to your QRZ logbook by itself. No exports, no uploading ADIFs by hand.

• It works in two places: your personal log goes to your logbook, and the award log to the award's logbook.
• They are deliberately not the same: a QRZ logbook belongs to one callsign, and contacts made under an event callsign simply will not be accepted into your own. So the award has a key of its own.
• The state of each contact is visible separately: sent, duplicate, error — and exactly what QRZ replied if it did not go through.
• Contacts made before you pasted the key can be sent retrospectively.
• The key is stored encrypted and never shown back — the interface shows the last four characters.
• From the other side, QRZ is a directory: empty locators in the log are filled in automatically. Only the empty ones: a locator given on the air is worth more than a guess about where a station usually operates. Portable callsigns are skipped, because QRZ would return the home square and the contact was not made from there.

Statistics: what is visible about the event in real time​

• Each activator's output: how many contacts, on which bands, in which modes.
• Band coverage by hour — you can see where work has been done and where you are still awaited.
• A contact map: locator squares at their true boundaries, countries by QSO count, and a separate view by Ukrainian oblast.
• The hunter page: your own progress, how much is left to meet the conditions, and which activators are on the air now.
• A live PNG banner listing the active stations — for a QRZ.com page or your own site.

A personal logbook: not only for awards​

Every account has its own log, separate from any award: enter contacts by hand or from WSJT-X, upload ADIFs, download them back, switch on automatic syncing with your QRZ logbook. An award is one log and your personal one is another, and they do not mix: a contact made under an event callsign will not land in your own log, nor the other way round.

What the month produced​

Not one contact was merged by hand. Neither during the month nor after it.

How many people saw it​

Since the platform launched on 25 July.

The last line is the most important. 4,376 people used the platform and 123 created an account. That is not a registration failure — it is the design: a hunter does not need an account at all. They open the event page, type in their callsign, see their own progress and collect their certificate. Registration is only needed by someone who goes on the air themselves.

59 countries is no longer about us. Those are people who went looking for what they had been credited with and found a Ukrainian page.

Where this came from​

I built the platform myself — from the idea and the architecture through to production, the server and the domain. The first demonstration was on 6 March 2026 from a laptop; the first real event was on 1 August.

I say this not for applause but so it is clear what we are talking about: this is not a page with a table knocked up over a weekend.

What it costs you​

How to start​

If you are organising an activity​

1. Register at uahamaward.com — a minute, an email address and a callsign.
2. Write to me and I will set the award up for you. Name, callsign, dates, certificate conditions, artwork. After that you run it yourself.
3. Invite activators by callsign. They accept the invitation in their dashboard and can go on the air straight away.
4. Operate. The log, the certificates, the QSLs, the statistics and the QRZ upload take care of themselves.

If you are a hunter​

No registration at all is needed. The award log is public: type your callsign on the event page and you will see your own progress, how much is left to meet the conditions, and which activators are on the air. The certificate and the QSL download from the same place as soon as the conditions are met.

The platform will run any award — regional, club, national, a single day's activation or a whole month. Write to UR3PKI. I will help you set it up, configure the conditions and get to grips with the bridge, especially the first time.

And something interesting from the data​

When a log sits in a database rather than in thirty files, you can learn something from it. I went through August: how the daily volume depends on the solar indices (hardly at all — the calendar rules), while the high bands really do depend on them; why the median distance falls as the flux rises; how far radioteletype reaches and who worked through the geostationary satellite.

→ 17,387 contacts in August: an analysis of the log

73! Petro, UR3PKI

What follows is what can be seen in it. Not “the award was a success” but concrete numbers: when the bands opened, why Saturdays weigh more than the Sun, how far FT8 reaches compared with SSB, and why amateur radio remains a hobby of wealthy countries.

At a glance​

The map: the locator puts down a point, the callsign colours a country​

There are two different layers on the map, and they should not be confused. The squares are locators from the log, that is, the physical place a station worked from. The country colour comes from the callsign, that is, from where the operator was licensed. A German on holiday in Croatia puts a square in JN and colours Germany all the same — that is not an error, they are two different questions.

16,823 contacts (96.8 %) have a locator and appear on the map; 564 (3.2 %) do not, and those points are missing.