Status, up front. QRVnet is in design and early MVP build. The QRV Cloud side (accounts, channels, mailbox) is being built now. The RF data layer exists as a specification and a loopback-tested modem path; no QRV bundle has yet crossed a real radio path in a field trial. Everything below that says "does" describes the design; where something is a goal, a plan, or a later phase, the text says so. Nothing here is legal advice. Read the Part 97 sections with your own eyes and your club's counsel.
Summary
Many EmComm drills go the same way. Traffic flows while the internet is up. When someone pulls the plug on the RMS gateway's uplink, or two stations can't hear each other on simplex, messages get stuck in somebody's outbox, and the net papers over it with voice relays and handwritten ICS-309s.
QRVnet addresses the plumbing underneath that paperwork. It is a layer that sits on top of the gear groups already own (FM repeaters, simplex channels, hotspots, EchoLink and AllStar nodes, APRS, the internet, Starlink) and turns every participating node into a mailbox that holds and forwards traffic. Messages are addressed to a callsign, survive the absence of either party, carry NTS-style precedence, and land in a persistent shared log that a net manager can turn into an ICS-309 without retyping it from memory. QRV Cloud is one more node with a big disk. The rule throughout is radio first, internet when available, never internet-required.
The network is designed to be self-healing in the plain store-and-forward sense. When a node, a repeater, a link or QRV Cloud drops out, traffic keeps moving over whatever paths remain (simplex, another repeater, a LAN, the internet when it's up). Bundles that can't move yet wait on disk, and nodes resync when they reconnect. There is no central switch whose loss stops RF traffic, which is also why Starlink is welcome but never load-bearing (§4.1).
Relays don't have to be trusted, either. Signing is optional and entirely local. The Ed25519 key is generated on the operator's own device, and creating a key, signing and verifying need no server, no account and no internet connection. An operator onboarded completely off-grid can sign from their first message, and anyone holding that operator's public key can check offline that a bundle arrived intact and unaltered, however many untrusted relays carried it (§7).
The RF data layer is tiered. Nodes use the fastest link both ends and the path support and fall back automatically. The design for the universal floor is the QRV audio modem, an OFDM modem built on the techniques of Ahmet Inan's Rattlegram, running through the mic and speaker audio of any stock FM radio, so any FM radio and any analog repeater can still relay. It adapts from about 1 kbit/s on poor paths toward a 4 to 6 kbit/s design target on flat audio. Radios with a data port add 9600 bps 4FSK with M17-compatible framing, enough for live Codec2 3200 voice and metadata. 1200-baud AFSK with AX.25 stays as a compatibility mode for APRS and Direwolf. Analog FM voice works everywhere.
1. The problem: EmComm when infrastructure fails
ARRL's own framing of ARES is that amateur radio "can function completely independently of the internet and phone systems."1 That's true of a voice net. It is much less true of the digital message systems EmComm groups now rely on for formal traffic, because most of them assume, in normal operation, that somewhere in the path there is a working internet connection and a central server.
The real failure modes in an incident are mundane:
- Partition. A neighborhood, a shelter or a county is cut off. Some stations can hear the local repeater; some can only work each other on simplex; the EOC may or may not have backhaul.
- Asynchrony. The shelter operator is on the air at 0900; the EOC radio room is staffed at 1100. Nobody is on at the same time as anybody else for long.
- Heterogeneous gear. A volunteer shows up with a 15-year-old HT and a phone. A served agency has a Starlink dish and a laptop. The repeater on the ridge belongs to a club that isn't part of your ARES group.
- Accountability. After the incident the served agency wants to know what was passed, when, by whom, and whether it was delivered. The answer is usually a stack of paper and a few people's sent-items folders.
1.1 What Winlink does well, and where it hurts
Winlink deserves respect. It's an all-volunteer system run by the Amateur Radio Safety Foundation, with over a thousand gateway stations,3 an openly published message structure and forwarding protocol (B2F),2 radio-only forwarding for internet outages,3 forms that served agencies recognize, and a long track record. It is also used by SHARES on government frequencies.3 Nothing in this paper argues you should stop training on it. Anyone who has run it under drill conditions knows where it chafes, and those pain points come from the architecture.
Winlink is CMS-centric by design. In conventional operation a client connects by radio to an RMS gateway, the RMS connects over the internet to a Common Message Server, and the CMS is the central repository where messages wait until the recipient connects.4 B2F itself is an extension of the FBB BBS forwarding protocol, oriented around a client-server session that proposes, accepts and transfers batches of messages.2 That design is efficient when the internet is up. It is also why conventional Winlink is, operationally, internet email with a radio last mile.
Radio-only and Hybrid operation exist, and they work under separate rules. The Hybrid Network lets RMS gateways forward radio-only traffic among themselves toward a user's chosen Message Pickup Stations (MPS) when the internet is gone.3 As originally announced, RMS-to-RMS forwarding in that network runs on HF via Pactor 2/3/4 under RMS Trimode, and users pick their MPS with a setup tool in RMS Express (now Winlink Express).3 Winlink's own traffic-handler guide is blunt about the gotcha: a radio-only session and a normal session are "completely separate," so if you make a normal connection you will not receive, or be notified of, radio-only mail waiting for you, and your radio-only outbox won't move. You may need two connections to transact both.5 That is a lot of mode-awareness to ask of a tired volunteer at hour 14.
Peer-to-peer (P2P) requires both stations on the air at the same time. P2P bypasses RMS and CMS entirely, which is exactly what you want when everything is down. But the Hybrid network's designer lists the disadvantages plainly: both stations must be on the air simultaneously, must coordinate a clear frequency, must use the same protocol, and can't reach internet addresses.4 Winlink's VARA FM setup guide adds that P2P messages can only go to the callsign in the To: field and only while in a P2P session with that station.6 There is no third station in the picture that can hold the message for the absent party and hand it over later. If the EOC isn't listening when the shelter calls, the message sits in the shelter's outbox.
Delivery is POP-style, and there is no shared persistent log. Winlink's FAQ says that when you download a message, it "is immediately deleted from the CMS"; unread messages live 21 days.7 Your client keeps local copies, and that's fine for a personal mailbox. But for an incident, there's no shared, server-side record of what the net passed that net control, the EC and the served-agency liaison can all look at. The ICS-309 is rebuilt from individual sent folders.
The reference client is Windows-centric. Winlink Express is supported on Microsoft Windows; on Mac and Linux, Winlink's own page says to use a virtual machine or dual boot.8 In fairness, there are alternatives: Pat is an open-source cross-platform client,9 and in September 2026 the Winlink Development Team announced a native macOS client in public beta.10 But the reference client, the forms library and most training material assume a Windows laptop, and the most popular sound-card modem, VARA, is itself a Windows program.
The fast modem is closed and licensed. VARA is a proprietary modem. The free versions are speed-limited; a $75 licence (permanent, covering VARA HF, FM and SAT) enables full speed, and organizational users like SHARES are told to contact the author.11 On HF the free tier is reported by VarAC's developer to stop at speed level 5, which is 177 bps at 500 Hz and 270 bps at 2300 Hz.12 $75 is not much money for one ham. It is a real line item for a county that wants twenty loaner kits, and a closed modem is one that you can't independently decode or fix.
Forms are a strength of Winlink, and they also add friction. They are HTML templates that live in the client and update over time, and the operator has to know which template, which version and which session type to use. The ICS-213 itself is fine; the trouble is the machinery around it (§5.4).
Situational awareness and group traffic are thin. Winlink supports multiple addressees, tactical addresses, position reports and bulletin catalogs.2 What it doesn't give a net is a shared operating picture: a live roster of who is checked in, who has traffic, where stations are on a map, and a channel everyone on the net can read. Broadcast traffic is something each station pulls from a catalog, so the net never sees one shared conversation.
None of this is a knock on the people who built Winlink. It was designed in a different era, around HF and internet email, and it does that job. The problem is that local EmComm in 2026 is mostly VHF/UHF FM, mostly asynchronous, mostly partitioned, and increasingly has intermittent satellite backhaul. That calls for a different shape.
2. Why a layer over existing gear
The single most important design decision in QRVnet is that it does not ask anyone to replace anything. It is a layer over infrastructure groups already own and already know how to run.
- Repeaters stay repeaters. A QRV node pairs with a repeater controller or a radio the way an EchoLink or AllStar node does: audio in, audio out, COS, PTT. The repeater keeps its callsign, its tone, its coordinator's blessing, its trustee. No firmware flash, no new controller, no digital-capable hardware required. Analog-only nodes still get voice linking, DTMF control and spoken mailbox readback; data bursts are an opt-in flag that requires the trustee to attest they have permission.
- Simplex stays simplex. Any two stations with FM radios and a node or app with a radio interface can exchange traffic directly at the fastest tier both support (§3), and any third station that hears it can carry it further.
- EchoLink, AllStar, M17, DMR, YSF and D-STAR stay what they are. QRVnet bridges to them rather than competing with them: AllStar via the USRP channel driver out of process, DMR/YSF/D-STAR through DVSwitch (which holds the AMBE vocoder, so we don't), M17 natively as the open digital-voice interop, EchoLink through a SvxLink sidecar. IRLP comes later as a co-located integration that works inside IRLP's rules.
- APRS stays APRS. Position beacons map to APRS positions, and short texts can be bridged to APRS-IS when the operator marks them. An IGate is a trustee decision, default off. We don't dump email onto the APRS frequency.
- The internet and Starlink are opportunistic backhaul. When a node has any IP path, it syncs. When it doesn't, it keeps working on RF and LAN and catches up later. Why Starlink still isn't the backbone is spelled out in §4.1.
The reasons are practical.
- There's no forklift upgrade in a disaster. The gear you have when the power goes out is the gear you have. A system that needs every site to buy new radios first won't be on the air when it's needed.
- The infrastructure is not ours. Most repeaters are owned by clubs and individuals who aren't going to rip out a working controller for an experiment. A node that hangs off the side of their system, behaves like a polite EchoLink node, and can be unplugged in thirty seconds is something a trustee can say yes to.
- Every existing network has users we want to reach. The goal is that a message can originate on an app, cross a simplex hop, ride an analog repeater, go out over Starlink (when that path is up, §4.1) and land in someone's internet inbox, and that the voice side can link a QRV channel to an AllStar node or an M17 reflector without anybody on the far end changing anything.
3. Tiered RF links over a plain FM audio floor
The RF data layer is a ladder of links; every node speaks the bottom rung. Nodes announce their modems, radio interface and, at repeater sites, whether the trustee measured flat audio. A sender uses the fastest tier and profile both ends and the path support, steps down after repeated failures and probes upward later, which is §4's self-healing applied to modems. Analog FM voice works everywhere.
Design direction. The node built so far (P4) runs the 1200-baud AFSK modem in loopback. The audio modem, the 9600 4FSK link, wideband (§10.2) and HF (§10.1) are roadmap, and nothing has crossed a real radio path yet.
The QRV audio modem, the universal floor. The floor is an OFDM modem in the style of Ahmet Inan's Rattlegram, running through the radio's microphone and speaker audio path (§3.3 explains why OFDM). Rattlegram's source sets the starting point: 8 kHz sampling, 160 ms symbols plus a 20 ms guard, 256 payload carriers 6.25 Hz apart (about 1.6 kHz), differential QPSK, and a length-2048 polar code carrying 85, 128 or 170 bytes in four payload symbols. Each burst opens with a Schmidl-Cox sync symbol and a BCH-protected preamble holding the callsign and mode, and the encoder adds a CRC, PAPR reduction and an adjustable center frequency.63 A burst lasts about 1.1 s, so 170 bytes move at about 1.25 kbit/s. The code is under the permissive 0BSD licence, so QRV can reuse it. The QRV modem keeps OFDM, polar codes and Schmidl-Cox sync, and goes faster in five ways:
- It uses more of the roughly 300 to 3000 Hz voice passband,67 about 2.4 kHz or some 384 carriers.
- It adapts modulation to the link: BPSK, QPSK, 8PSK or 16QAM, with a code rate chosen from the SNR measured on the preamble.
- It streams. Shorter guard intervals and continuous multi-frame transmissions spread one sync across many frames instead of paying for it every second.
- Bulk transfers use longer frames, which spread the overhead further.
- On a bad path it falls back automatically to a Base profile that matches Rattlegram.
| Profile (design target) | Path | Band, carriers | Modulation and code | Target net rate |
|---|---|---|---|---|
| Base | Speaker to mic, unknown or poor paths, fallback | 1.6 kHz, 256 | Differential QPSK, polar, single bursts | 0.6 to 1.25 kbit/s |
| Wide | Typical mic and speaker FM path | 2.4 kHz, about 384 | BPSK or QPSK, rate 1/2, streamed | About 1 to 2 kbit/s |
| Standard | Good mic and speaker path | 2.4 kHz, about 384 | QPSK or 8PSK, rate 2/3, streamed | About 2.7 to 4 kbit/s |
| Fast | Flat audio: data port or flat repeater audio | 2.4 kHz, about 384 | 16QAM, rate 1/2 to 3/4, streamed | About 4 to 6 kbit/s |
The Base row is Rattlegram's own numbers. The other rows are design targets worked out by arithmetic, not measurements, assuming 170 ms symbols (a 1/16 guard) and 16 payload symbols behind each sync and preamble. At 16QAM that is about 9 kbit/s of coded bits, and rate 1/2 to 3/4 leaves about 4 to 6 kbit/s before the pilots that coherent 16QAM needs. Pre-emphasis and voice filtering are what hurt dense constellations. Direwolf's author found 4800 bps 8PSK failed through one radio pair's mic and speaker yet decoded through the receiver's data connector.67 The upper profiles therefore belong on flat paths, and a speaker-to-mic acoustic path stays near the Base profile's 1 kbit/s. On a shared repeater the §3.2 burst limits still apply, so streaming pays off mainly on simplex and data-port links.
Voice on the audio modem. Live Codec2 3200 with link metadata needs a little more than 3.2 kbit/s after framing. That takes the Fast profile, or Standard at its top end, on a clean path, or the 9600 4FSK link below, and live voice also wants short frames to hold latency down, which costs some rate. On typical mic and speaker paths, voice goes as Codec2 clips, or near real time at 700 to 1300 bit/s where the profile allows. 700C fits the Base profile with margin, and 1300 needs Wide at QPSK.60 Live analog FM voice always works.
9600 bps 4FSK, for data-port radios. M17 specifies 4FSK at 4800 symbols/s in a 9 kHz channel. Its frames carry Codec2 3200 voice and spread link metadata (addresses, type, 14-byte META field) across each six-frame superframe; voice plus data drops to Codec2 1600 with 1600 bit/s of data.62 The symbols drive the FM modulator directly, so like 9600 G3RUH it needs a data port, discriminator tap or QRV hardware. It fits Part 97's data limits on 2 m (20 kHz, 19.6 kilobaud) and 70 cm.24
1200-baud AFSK, legacy and compatibility. Bell 202 AFSK in AX.25 UI frames with FX.25 Reed-Solomon FEC, the signal Direwolf and every APRS tracker speak, stays as a compatibility mode for APRS interop and for stations running Direwolf or a TNC.13 It is also the modem the P4 node runs today. At about 800 bit/s of payload (§3.1) it is slower than the audio modem's Base profile.
The audio-path floor is the design's most important decision. It buys five things:
- Any FM radio. The audio modem lives inside the voice passband, so anything that passes intelligible voice passes it: a $30 HT through a sound-card cable, a mobile through its mic jack, a repurposed commercial radio. It needs no data port, discriminator tap, firmware change or digital-voice board.
- Any analog repeater. A stock analog repeater with CTCSS, pre-emphasis and a hang timer repeats it like your voice, and an unknown repeater starts at the Base profile. The repeater needn't be digital-capable, networked, or aware QRV exists. It needs only the owner's permission, which node setup requires you to attest to before it keys data.
- Any simplex channel. Two operators on 146.52 with radios they borrowed this morning can move traffic.
- Improvised paths. Cross-band repeat, a linked analog system, or at worst a phone held against an HT speaker is lossy but still audio. Rattlegram already runs from one phone's speaker to another's microphone, and OFDM, polar codes and fragment retransmission absorb that abuse (§3.3). A baseband digital mode wouldn't survive those paths.
- Open monitoring. The modem specification and source are to be published, Rattlegram's code is public, and Direwolf decodes the AFSK compatibility frames. The QRV bundle format is published. That matters for §97.113 and §97.309 (see §7).
3.1 The throughput trade-off
Audio links are slow. The Base profile moves 170 bytes in about 1.1 s, so a compact ICS-213 takes a burst or two. AFSK compatibility mode is slower still: a 200-byte payload plus AX.25 headers and FX.25 parity takes roughly 1.7 seconds on air by arithmetic, about two seconds with keyup delay, or about 800 bit/s. Live Codec2 doesn't fit on AFSK. Its 3200, 1600 and 1300 bit/s modes exceed that rate, and 700C would fill more than 80 percent of a simplex channel with no room for repeats.
QRVnet narrows the throughput gap in several ways:
- Compression. Bundle bodies are deflate-compressed; forms go as compact JSON.
- RF projection. Each object has an RF projection that fits the burst budget. Images go to RF as a ≤8 KB WebP thumbnail with "full image on IP"; a large email attachment goes as a notice. The full object stays in the log and moves over IP when a path exists.
- FEC and selective repeat. Polar codes (FX.25 in compatibility mode) correct bit errors; missing fragments are re-requested by index rather than resending the whole bundle.
- Store-and-forward. Slowness hurts much less when nobody is waiting on a live session. A bundle that takes four bursts over ten minutes still arrives, at every node that wanted it.
- Priority queues. Emergency traffic jumps the queue; bulk thumbnails wait.
3.2 Being a good neighbor on a shared repeater
Data on a voice repeater is only acceptable if it never steps on voice. The channel-access rules are designed so trustees can sign off on them:
- Never start a burst while carrier (COS) is present, a voice floor is granted, or the node is transmitting voice; wait 3 s of idle after the channel drops.
- p-persistent CSMA (p = 0.25, 100 ms slots) so multiple nodes don't collide on the tail.
- Bursts ≤ 2.5 s on a repeater, ≤ 5 s on simplex.
- Hard duty-cycle cap (default 10 % per hour) and configurable quiet hours that suppress data but not voice.
- Forward selectively: always for local mailboxes, broadcast and emergency traffic; otherwise only if the addressee is local or recently heard, with a small probability of discovery forwarding.
These are starting defaults, and the field trial will tune them.
3.3 Why OFDM survives a speaker held up to a microphone
The hardest path the floor has to handle is acoustic: a phone or laptop speaker held up to a radio's microphone to send a burst. Each weakness of that path matches something OFDM was built to absorb.66 A speaker-to-mic hop runs the Base profile, and wired or flat paths step up automatically as the measured SNR allows.
- Room echo. Sound reflects off walls and hands, so the microphone hears the burst plus late copies of it. Each OFDM symbol starts with a guard interval that holds a copy of the symbol's own tail, the cyclic prefix, so echoes that arrive within the guard land inside the same symbol instead of smearing into the next.66 Rattlegram's 20 ms guard covers about 7 m of extra sound path.63
- Uneven frequency response. A tiny speaker, a cheap microphone, the radio's pre-emphasis and de-emphasis, and its voice filter all tilt and notch the spectrum. Each 6.25 Hz carrier sees a nearly flat slice of that, so the receiver can correct the channel with one complex multiplication per carrier.66 Rattlegram gets the same effect by decoding each carrier against the previous symbol on that carrier, starting from the preamble, so a fixed gain and phase on any carrier cancels out.63 The coherent QRV profiles would measure the channel from the preamble and pilots instead.
- Narrowband noise and dead spots. A hum, a whine or a notch in the passband takes out only the few carriers it touches. Rattlegram's decoder marks carriers that arrive too weak as erasures, and the polar code recovers the missing bits.63
- Timing and clock errors. A 160 ms symbol barely notices a millisecond or two of jitter, and the guard interval reduces sensitivity to timing errors.66 Rattlegram's decoder also fits and removes the phase slope across carriers that a small timing offset leaves behind,63 which is how slow sound-card clock drift shows up. A fixed audio delay through the radio changes nothing once sync has found the burst.
- Finding the burst. The Schmidl-Cox method detects a burst from one training symbol and estimates its start and frequency offset, averaging over many carriers so it works at low SNR.65 Rattlegram opens every burst with such a symbol.63
- Clipping. Many carriers can add up to tall peaks, and a high peak-to-average power ratio is a known cost of OFDM.66 Rattlegram's encoder runs a PAPR-reduction step on every symbol,63 so a cheap speaker and the radio's mic limiter clip less.
Bell 202 AFSK has none of these tools. It sends one tone at a time, 1200 or 2200 Hz,67 and each bit lasts 0.83 ms, so a room echo a few milliseconds late smears across several bits. It has no channel equalization. The demodulator compares the strengths of the two tones, and pre-emphasis, de-emphasis and limiting skew them. On a standard set of test recordings, Direwolf's author measured mark-to-space amplitude ratios from 0.53 to 3.81 and added per-tone AGC and parallel demodulators to cope.64 AFSK does well on a flat, well-adjusted wired path. An acoustic hop strains it.
4. Why offline-first store-and-forward
The networking model borrows from delay-tolerant networking (DTN) and from forty years of packet BBS culture. The core idea is that any node holds and forwards.
- Bundles. Every message, form, position or bulletin is a self-contained bundle with a content-derived ID (a SHA-256 prefix of its canonical bytes), a sender callsign, a destination (a callsign, a channel, or broadcast), a priority and a hop limit (32 on IP, 8 on RF).
- Repeaters and hotspots as mailboxes. A node at a repeater site stores mail for its home callsigns and serves it on request: in the app, over data, or as a spoken "you have traffic" readback for analog-only stations via DTMF.
- Partition tolerance. Nothing requires an end-to-end path at send time. A bundle moves whenever any hop is available: simplex now, a repeater an hour later, Starlink tonight if that backhaul is up (§4.1).
- Dedup and gossip. Because IDs are content-derived, a node that hears the same bundle three times stores it once. Over IP, nodes exchange compact summary vectors (or a Bloom filter when the list is large) and fetch only what they lack. After a link flap, peers replay the summary and skip traffic they already hold.
- Self-healing. Nodes don't keep routing tables that must be rebuilt when something breaks; each bundle moves over whatever hops are up at the moment. If a repeater goes off the air, the same traffic can cross simplex or another machine. If a repeater-site node dies, the other nodes that heard the bundle still hold copies (Flow C, §5.3). If the EOC is off the air, a hilltop node holds its traffic (Flow A, §5.1). If QRV Cloud or the internet is gone, RF and LAN keep working. Bundles that can't move yet wait in storage, within their retention window and hop limit, and move on when a path reappears. When nodes reconnect over IP they swap summaries and fetch only what they lack, and content IDs mean a bundle that arrives by two paths is stored once. Adding or dropping a node doesn't require updating a central route map, so there's no single node whose loss stops RF traffic. Relays don't need to be trusted for any of this: a signed bundle is checked end to end by whoever receives it (§7). Some limits apply. If no path exists at all, traffic waits until one does. Internet email and the permanent archive still need some node to reach QRV Cloud eventually. None of this has been proven over the air yet (field trial, P7).
- Precedence. Every transmitter keeps five queues (emergency, priority, welfare, routine and bulk), following NTS precedence plus a bulk class.
- A persistent log. QRV Cloud keeps every authenticated bundle permanently, and nodes cache with a retention window. Messages aren't deleted when read, so the mailbox works like a chat log. An ICS-309 or an after-action report becomes a query against that log instead of a search through everyone's sent folders.
Everyone with a callsign has a mailbox, even without a QRV account: traffic addressed to a callsign is stored and waits for that operator to show up on a node, in the app, or by DTMF.
4.1 Why Starlink stays a backhaul path
A Starlink kit at every EOC and shelter can look like a complete answer. Starlink is useful, and a QRV node uses it whenever it's up. Using it when it's available is a different decision from building the plan on it, and for EmComm only the first holds up. Starlink is one company's service, delivered to a powered dish under a clear sky, and each of those conditions can fail:
- Power and sky. SpaceX's spec sheets list an average draw of 75 to 100 W for the Standard kit and 25 to 40 W for the Mini, and a 110° field of view for both.3031 That's a continuous load on a shelter's generator or battery, and the dish needs a spot where trees, buildings and debris don't block the sky.
- Weather. An independent study of minute-level telemetry from 1,292 Starlink terminals across the continental U.S. (February to April 2025) found baseline performance was good, but 55 % of severe-weather hours showed substantial degradation (over 70 % in thunderstorms with heavy rain), with impairments and full outages lasting from minutes to over an hour.32 Severe weather is also when EmComm groups get activated.
- Shared capacity. Capacity is shared among the users in an area. SpaceX already waitlists residential service where it's "Sold Out," and its plan terms let it, "in its sole discretion," charge a Roam Unlimited user more or limit them to the Starlink account page after 60 days in a congested, sold-out area.33 A disaster area where agencies, utility crews, media and evacuees all light up dishes at once is the worst case for shared capacity.
- Account and policy. Service rides on an account, a bill and terms one company sets. Where and for whom it works is also decided centrally: in 2023 Elon Musk said SpaceX had not activated coverage to Sevastopol and declined an emergency request from Ukrainian authorities to do so;34 in early 2026 Starlink deactivated terminals Russian forces had been using in Ukraine,43 and from February 2026 terminals there worked only once they were on a government verification whitelist, updated once per day at first.44 Whatever you think of those calls, nobody on the ground could override them.
All traffic still comes down through SpaceX's ground network. It goes up to a satellite, down to a gateway, then over terrestrial backhaul to a Starlink point of presence before it reaches the internet. Laser links let it cross the constellation to a gateway; they don't remove the need for one.37 And it all runs on one operator's network core. On July 24, 2025, Starlink suffered a global outage of about 2.5 hours; SpaceX's VP of Starlink engineering, Michael Nicolls, said it "was due to failure of key internal software services that operate the core network."35 SpaceX later told resellers it traced the failure to an upgrade procedure on its "ground-based compute clusters," according to PCMag.36 The dishes had power and clear sky, the satellites were flying, and no traffic moved. That is a correlated failure, where one fault takes out the EOC, the shelter and the agency 300 miles away at once. A bad repeater controller takes out one repeater.
In a war, Starlink is a target, and it already has been one. The record from the Russia-Ukraine war so far:
- In early March 2022 Musk said Starlink terminals in Ukraine were being jammed and a software update countered it;43 the Pentagon's director of electronic warfare said Starlink "had slung a line of code and fixed it" the next day.38
- In April 2023 The Washington Post reported a leaked U.S. intelligence assessment that Russia had been experimenting with its Tobol electronic-warfare system to disrupt Starlink;39 Defense Express, summarizing it, put the experiments at more than five months and a jammer near Bakhmut, with results undisclosed.40
- Ukrainian troops told Defense One in 2023 that Russian forces were locating and jamming their dishes. Each terminal then used GPS to pick its satellite, which left it exposed to GPS jamming.41 SpaceX has since reduced that dependence, according to a Ukrainian engineer who studies Starlink.43
- In December 2024 a Russian defense-industry group announced "Kalinka," a direction finder it says detects Starlink terminals at up to 15 km.42 In 2026 Ukraine reported growing use of what it identified as the Volna-Kupol-Garant jammer, built to blind the satellites themselves, and in June released video of a strike on one.43
To SpaceX's credit, by most accounts the effect has been limited and local; a RUSI electronic-warfare analyst told France 24 that the Russians "have been trying really hard, but they've not had much success."43 For EmComm planning, the relevant fact is that Starlink is in that fight at all. In any serious conflict or deliberate attack, Starlink will be a primary target, along with its gateways, its network core and the GPS so much else depends on. An EmComm plan that needs it to be up is a plan an adversary can switch off from one place.
A distributed RF network has no such place. Independently owned FM stations and repeaters, each with its own power, antenna and trustee, have no core to jam, no account to suspend and no software push that reaches all of them. A jammer near one repeater takes out that repeater's coverage; QRV traffic routes around it on simplex or another machine and catches up later, and the audio modem needs no satellite positioning or timing. It's slow and local (§3.1), and it fails one site at a time.
So QRVnet treats Starlink like any other IP path. When a node has it, bundles sync. When it's gone (outage, congestion, a suspended account, weather or jamming), traffic keeps moving on RF and LAN and the log catches up later. That is the same self-healing behavior §4 describes for any failed link. When Starlink goes away, one path drops out and the network keeps running. Bring the dish, and plan as if it won't be there.
5. Architecture overview
The main components:
- Nodes. A Linux daemon that runs on a repeater-site computer, a hotspot-class board, or a laptop at a shelter, with a USB sound interface and a PTT/COS line. It handles analog voice linking, DTMF, the local mailbox, the optional modem, and bridges. The Android app is also a participant: it can talk to QRV Cloud over IP and, with a radio interface, act as a small node.
- Voice channels. Numbered channels (four to six digits) behave like real repeaters: floor control with hang time, courtesy tones, CW ID on the node's transmitter, and an IRLP-style DTMF dialplan (
*1000to link a channel,73to drop,*99to jump to the ARES priority channel). The app has a keypad that sends real DTMF and T9-style texting. Analog repeaters join a channel the way they'd link to EchoLink or AllStar. Codec2/M17-style digital voice is optional. - Mailbox plane. Text, compressed images, email with attachments, bulletins, positions and forms, all as bundles. Channel-wide or individual addressing. A map of opt-in positions; an APRS-IS bridge (off by default).
- QRV Cloud. Accounts, channel floor control, the permanent log, and an email gateway that gives each licensed ham a real
callsign@qrvnet.comaddress. If QRV Cloud is unreachable, local repeater audio and DTMF keep working and nodes keep accepting and serving bundles from disk and from RF/LAN peers.
No single box in the diagram stops RF traffic when it fails. Lose QRV Cloud, and the field keeps passing traffic on RF and LAN. Lose the club repeater, and stations in simplex range still reach each other. Lose the repeater-site node, and other nodes that heard the traffic still carry it. What does stop without QRV Cloud is the internet-facing work: linked voice channels (floor control lives in QRV Cloud), internet email in and out, and the permanent archive. That work queues and catches up when any node regains backhaul. This is the self-healing behavior from §4, seen from the diagram.
5.1 Flow A: ICS-213 from a shelter on simplex to the EOC
- The shelter operator fills in an ICS-213 in the app (field values, not a scanned PDF). Precedence maps to bundle priority. Optionally the bundle is signed (§7).
- The shelter node compresses the form to compact JSON. If it fits a few fragments, it goes whole; otherwise RF carries the subject, the first 500 characters and an "available in full on IP" notice, and the full form waits for an IP path.
- The node waits for a clear channel and sends data bursts on the agreed simplex frequency.
- The EOC node, or any node in range such as a hilltop node, decodes, reassembles, verifies the signature if present, dedups and stores it. If the EOC didn't hear the first burst, a missing-fragment request recovers it; if the EOC wasn't on the air at all, the hilltop node holds it and forwards when the EOC comes up.
- Net control sees it in the incident's queue and, with one click, appends an ICS-309 line. When either node gets backhaul, the bundle syncs to the QRV Cloud archive.
The 309 disposition is set by a human. A form in the log is not proof the served agency acted on it.
5.2 Flow B: email from the field to a served agency when backhaul is up
- A field operator writes an email to the Red Cross liaison's ordinary address, with a photo attached.
- If the field node has LAN or Starlink (opportunistic backhaul, §4.1), the bundle syncs straight to QRV Cloud, which sends it as standard internet mail from the operator's
callsign@address. Outbound messages are kept small, with large attachments held for radio-friendly delivery. - If the field node has no backhaul, the text body moves over RF to any node that does (the attachment travels as a notice and catches up over IP), and that node syncs.
- The reply arrives at the operator's address, is stored in the same mailbox, and is flagged as third-party traffic. Reading internet mail back onto RF is off by default and is a club/counsel decision (§7).
5.3 Flow C: a cut-off neighborhood relaying via a generic FM repeater
- A neighborhood loses power and cell service. One ham there has an HT, a phone and a cable; a second has a mobile in the garage.
- They can't reach the EOC on simplex, but both can hit a club's analog 2 m repeater on the ridge. The repeater isn't a QRV site; its trustee has simply agreed that QRV data bursts are allowed, and the operators' nodes are configured with that attestation.
- Welfare and priority bundles go up the repeater in short bursts during idle time, below the duty-cycle cap. Every node that hears the repeater's output and has interest in the addressee (including the EOC node and any repeater-site node elsewhere on that machine's coverage) stores a copy.
- The neighborhood's traffic now exists in more than one place. When any of those nodes reaches the internet, it lands in the archive and in addressees' mailboxes; replies come back the same way. None of this required any change to the repeater.
5.4 Forms, and the paperwork after the net
Winlink's forms are good and proven. The field values travel as a small XML file, a plain-text copy rides in the message body for anyone without the template, and another copy of Winlink Express renders the form cleanly from its HTML template.72 The friction is the template layer. Templates are stored on each copy of Express and kept current by an internet auto-update, the interactive form works only inside Express, and for forms outside the standard library, sender and receiver both need the same template installed to see a form instead of plain text.7273 QRVnet keeps forms and drops the template layer.
A QRV form is a bundle of type=form with a kind and a set of named field values. The field lists are part of QRVnet's published spec and are built into its clients and server, so there is no template library to download or keep in sync before a drill. A field that a reader doesn't recognize is kept and ignored, not dropped, so a newer form doesn't break an older client. Only the field values go on the air, as compact deflated JSON, which is how one ICS-213 fits in a burst (§3.1). Because the form is data, the same fields can be laid out as a web page, an app screen, or plain text an operator reads to a voice or CW net. A print layout that resembles the paper form is planned. A form too large for the RF fragment budget travels as a notice carrying the subject and the first 500 characters, and the full form follows over IP (§5.1).
A form is an ordinary bundle, so it moves over every path in this paper: simplex, any analog repeater, a LAN, or the internet or Starlink when they're up. There is no special session type and no gateway connection to set up first. Forms inherit store-and-forward, dedup, precedence and self-healing (§4); a radiogram's precedence sets the bundle's priority. A form can be signed, and the signature covers its field values, so a changed field fails verification (§7). ARRL numbered-radiogram text is expanded only for display, never rewritten into the signed body.
The forms phase (P6) covers this set:
- ICS-213 General Message, the workhorse.
- ICS-205 Incident Radio Communications Plan and ICS-205A Communications List. A 205 row can point at a QRV channel number.
- ICS-211 Incident Check-In List and ICS-214 Activity Log.
- ICS-309 Communications Log, the comm log ARES and AUXCOMM operators keep. CISA's Auxiliary Communicator task book lists "Radio Logs (Form 309)" for the go-kit.74
- ARRL radiogram, with number, precedence, handling instructions (HXA to HXG), check, address, text and signature.75 Welfare traffic goes as a radiogram with WELFARE precedence.
- Lighter QRV net rosters and resource lists.
The ICS forms above are FEMA's.16 FEMA also publishes the ICS-213RR Resource Request Message; it isn't in the P6 list, and QRV's resource list covers tracking for now. Damage-assessment forms aren't specified yet.
Required fields are checked when a form is filed. The spec already prefills net check-ins: the roster entry takes the callsign from the talker and the time from the server. The plan extends that to forms: callsign and name from the operator's profile, the time, the current net or incident, the last reported position, and served-agency contacts from the incident's 205A.
Much of the paperwork after a net can come straight from the log. The persistent log (§4) already timestamps every bundle. Net control's check-in button (or *85 by DTMF) appends roster lines, and "log this" appends ICS-309 lines as the net runs. A scheduled net session exports an ICS-309-shaped record at the close; that export is in the MVP build. Planned for P6 and after:
- each operator's ICS-214 drafted from their own traffic and check-ins;
- end-of-shift and end-of-day packets exported as PDF and CSV for the served agency's documentation unit;
- a status trail on each message (sent, relayed, delivered, acknowledged), drawn from the log and from acknowledgement bundles.
The net manager reviews, corrects and signs the result instead of rebuilding it from memory. Two limits stay in place. An entry in the log is not proof the served agency acted on the message, and the 309 disposition column is a human's call.
6. SHARES
The SHAred RESources (SHARES) HF Radio Program, administered by CISA, provides an additional means for users with a national security and emergency preparedness (NS/EP) mission to communicate when landlines and cellular are unavailable.14 CISA describes more than 3,290 HF stations representing over 590 federal, state and industry organizations as resource contributors, nearly 500 emergency planning and response personnel as participants, and roughly 200 HF channels available to members.14 Participating stations "accept and relay messages until a receiving station is able to deliver the message to the intended recipient," which makes SHARES itself a store-and-forward system.14 SHARES runs weekly national and regional nets on Wednesdays for practice.15
SHARES is not an amateur service. CISA is explicit that "all SHARES stations are Federal government radio stations regardless of who hosts the station," licensed by the SHARES Program Office under an NTIA authorization issued to DHS.15 The channel list, net list and station directory are For Official Use Only and controlled by a non-disclosure agreement.15 Federal SHARES stations may communicate with amateur stations only in specific circumstances: with RACES stations at the direction of an emergency management official, with amateurs engaged in emergency communications on the five 60 m channels, or when necessary for the immediate protection of life and property when normal communications are unavailable.15 For Winlink traffic, SHARES permits only Pactor-3 and Pactor-4.15
QRVnet's ham network will never transmit on SHARES frequencies, and nothing in this paper suggests an amateur station should. QRV's RF is Part 97, on amateur bands, under amateur control operators.
QRVnet can help SHARES participants as a coordination and tracking layer on the ham side and the IP side, where many SHARES-registered people already overlap with ARES and RACES:
- Shared rosters and scheduled nets. The same net-control tools (check-in roster, ICS-211, scheduled net reminders) can track who in a county's ham team is also SHARES-registered and staffed today.
- Message tracking. A served agency handing traffic between an amateur path and a SHARES path needs to know what went where. QRV's log can record the handoff ("passed to SHARES station at county EOC, 1432Z") as an ICS-309 line, without carrying SHARES content on ham RF.
- ICS forms in common. ICS-213/205/205A/214 are FEMA forms both communities already use,16 and the ICS-309 comm log is standard in AUXCOMM go-kits.74 A 205 row can point at a QRV channel number; it can also simply list the agency's own plan.
- Situational awareness. Map, roster and bulletin views over IP can give liaisons a shared picture of where amateur resources are.
QRVnet will not host SHARES FOUO material (channel lists, directories) in a general-purpose ham service or blur the line between amateur and federal stations. A SHARES workspace, if it ever exists, would be a separate, access-controlled, IP-only mode built with the SHARES Program Office's agreement, and any RF use would be on equipment and frequencies authorized by them. No such workspace exists today.
7. Compliance: Part 97, signing vs. encryption
No obscured meaning. §97.113 prohibits messages encoded for the purpose of obscuring their meaning,18 and §97.309 allows unspecified digital codes only if they are not used to obscure meaning, with records on request.25 QRV's ham-mode RF is clear: an openly specified audio modem, AX.25 frames in compatibility mode, a published bundle format, deflate (a public algorithm) and public keys. Anyone with the open modem software (or Direwolf, for compatibility frames) and our spec can read every byte. There is no encryption on amateur RF, and the ham mode has no switch to add it.
Local signing. Signing is optional, and everything it needs lives on the operator's own device. The app generates an Ed25519 keypair on the phone or node; the private key stays there and does not go to QRV Cloud.71 Making a key, signing a bundle and checking a signature are local computations that involve no server, no account and no internet connection. An operator onboarded completely off-grid can make a key and sign their traffic right away.
How signing works. When you sign, the software runs the bundle's canonical bytes through a hash function (Ed25519 uses SHA-512 internally) and uses your private key to turn the result into a 64-byte signature. The bundle carries that signature plus an 8-byte key ID, 72 bytes in all, once per bundle rather than once per RF frame. A plain hash, like the bundle's own content ID, only shows the bytes match what was hashed, and anyone who alters a message can compute a fresh hash for the new text. A signature also proves which key wrote it, because nobody without your private key can produce one that verifies against your public key.
Signing and encryption. The signature hides nothing. The message stays in the clear for anyone to read, and anyone with the sender's public key, including a monitor who has never used QRV, can check it. Our reading is that a publicly verifiable signature appended to a readable message doesn't obscure meaning under §97.113. That is our reading of the rule, and counsel should review it. Signing exists because fake from callsigns are trivial in any open relay, and in EmComm authenticity matters more than privacy.
Offline verification. Checking a signature needs only the bundle and the sender's 32-byte public key, so any receiver can do it offline. The signature covers the whole canonical bundle. The one field relays change, the remaining hop count, sits outside it, and fragments are reassembled before the check. If a bundle verifies, it is byte-for-byte what the key holder signed, whether it crossed one simplex hop or a chain of nodes, repeaters and internet links. A relay that corrupts or edits it produces a bundle that fails, and the receiver marks it invalid rather than authentic. A relay could strip the signature, but then the bundle arrives unsigned and is shown that way. Because integrity is checked end to end rather than hop by hop, relays don't need to be trusted. That is what lets the self-healing in §4 use whatever path happens to be up.
Keys and callsigns off-grid. The key ID travels in every signed bundle. A short self-signed key-announcement bundle, carrying the callsign and public key, rides the mesh like any other traffic, and nodes keep a small cache of keys they've heard. A self-signed announcement proves someone holds the key; it doesn't prove the key belongs to that callsign. Off-grid, operators can close that gap the old way, by comparing key IDs in person or reading them to each other on the air. When connectivity returns, the app can check a key against the one the operator published to the QRVnet directory, and until then it labels a key heard only on the mesh as not yet confirmed against the directory. A signature tells you the message is intact and which key wrote it. How much to trust the key depends on how it was checked.
Identification. Every transmitting node IDs under §97.119:20 each data frame carries the node's callsign (the modem preamble, or the AX.25 source address in compatibility mode), and nodes send CW or voice ID like any repeater controller.
Control operators. Every transmission has a control operator (§97.105).17 Only licensed amateurs transmit on ham channels; anyone can listen. Unattended data nodes rely on the automatic-control provisions for RTTY/data on 6 m and shorter wavelengths (§97.221).21
Third-party traffic. Internet email is third-party traffic, and it can be pecuniary-interest traffic. §97.115 sets the rules19; §97.113 bars communications in which the licensee or control operator has a pecuniary interest, including on behalf of an employer (with narrow drill exceptions).18 That's why internet-mail readback onto RF ships off, inbound email is flagged third_party, and a club must turn it on deliberately.
Commercial LMR (Part 90). A future encrypted mode for licensed Part 90 users is a separate product. It is never bridged to amateur RF; the bridge code refuses it.
Not a 911 center. The UI says so. Life-safety calls go through the public telephone system and the served agency's procedures.
8. How QRVnet compares
| QRVnet (design) | Winlink P2P | Winlink via RMS / CMS | |
|---|---|---|---|
| Both parties on air at once? | No; any node holds mail | Yes, required4 | No; CMS holds mail |
| Third station can hold & relay for absent party? | Yes, any node or repeater-site node | No | RMS to CMS (or MPS in radio-only) |
| Internet needed for normal use? | No; internet/Starlink is opportunistic (§4.1) | No | Yes for CMS mode; radio-only Hybrid is separate |
| Message after delivery | Persistent shared log + local caches | Lives in both clients | Deleted from CMS on download; unread kept 21 days7 |
| Shared incident log / ICS-309 | Built in (one-click 309 lines) | Manual | Manual |
| Group / channel-wide messaging | Channel-wide rooms + broadcast bulletins | Per-callsign sessions | Multi-address, bulletin catalogs |
| Shared map / roster | Map, check-in roster, resources | No | Position reports; no live net roster |
| Works over a stock analog FM repeater with no changes | Yes, audio modem in voice audio, owner-attested | Packet: yes, if owner allows | Via a packet RMS |
| Special modem hardware/software | None; open audio modem, AFSK compatibility, faster tiers negotiated | VARA (licensed for full speed), Pactor, ARDOP, packet | Same |
| Modem openness | Open spec and code; AFSK mode is Direwolf-decodable | VARA closed; packet/ARDOP open | Same |
| Layer over existing gear or a parallel system | Layer: repeaters, EchoLink/AllStar, M17, DVSwitch, APRS | Parallel | Parallel (gateway network) |
| Client platforms | Web, Android, Windows, macOS and Linux desktop apps, iOS; Linux node | Windows-first; Pat, MacWinlink beta910 | Same |
| Internet email | Yes, callsign@qrvnet.com |
No | Yes, @winlink.org |
| Message signing | Optional Ed25519 per bundle; keys made on device, verifiable offline | No | Secure login (account auth), not per-message signature |
| Maturity | Pre-field-trial | Proven, decades | Proven, decades |
The last row matters. Winlink works today, and QRVnet is a design with a build in progress. The useful question for a group is whether QRVnet is worth piloting alongside what it already runs.
9. Inspiration: standing on shoulders
Very little in QRVnet is new. Most of it is good ideas that other hams and engineers worked out, some of them decades ago, recombined for local VHF/UHF EmComm. The criticisms in §1.1 and §8 concern fit for local VHF/UHF EmComm and say nothing against the quality of these projects. Every project below works, and most will keep doing jobs QRVnet can't.
Packet radio, AX.25 and the packet BBS. AX.25 version 2.0 was published in 1984 by Terry Fox, WB4JFI, and TAPR's 1998 v2.2 revision describes a packet network that grew from digipeaters into HF, internet and satellite gateways.45 We keep AX.25 UI frames and callsign addressing for the AFSK compatibility mode (§3). The packet BBS habit of holding mail until the addressee checks in is the heart of §4, and Winlink's B2F itself grew out of FBB BBS forwarding.2
Delay-tolerant networking (DTN). The DTN architecture (RFC 4838, 2007) grew out of work on an "Interplanetary Internet." It drops the assumption that an end-to-end path exists, keeps messages in persistent storage at each node, and borrows postal-style priority classes; the Bundle Protocol is now standardized as BPv7 in RFC 9171.4647 We take the model and the vocabulary: self-contained bundles, hop limits, storage everywhere, priority queues, and the working assumption that sender and receiver may never be on the air at the same time. QRV's bundle format is its own, sized for slow audio links, but the ideas are DTN's.
APRS, and Bob Bruninga, WB4APR. Bob, who died in 2022, grew APRS from a 1982 program that plotted Navy ship positions; it was renamed APRS in 1992.48 He insisted APRS "is not a vehicle tracking system" but "a two-way tactical real-time digital communications system" sharing what's happening in the local area, providing, in his words, "situational awareness to all operators."49 That idea is the core of our map, roster and bulletin views. We also keep 1200-baud AFSK on plain FM for APRS interop, and take position beacons, bulletins, and the lesson of his WIDEn-N "New-N Paradigm": a shared channel stays usable only if relaying is bounded.50 That's why QRV forwards selectively and caps duty cycle (§3.2).
Winlink. ARSFI's volunteers built the system served agencies know. It gives each callsign a real mailbox and an email gateway between RF and the internet, with forms people recognize, over a thousand gateway stations and use by SHARES.3 We keep those ideas: a mailbox per callsign, real callsign@ internet mail, ICS-213 and its siblings, and Winlink form import/export (P6). We drop the parts §1.1 criticizes: P2P that needs both stations on the air at once, separate radio-only and normal sessions, and mail deleted on download.
Meshtastic. Meshtastic made off-grid mesh messaging cheap and approachable: open source, community-driven, on inexpensive LoRa radios that rebroadcast what they hear, with no dedicated router.51 We borrow its channel model (a primary channel for routine broadcasts plus user-defined channels everyone on them can read),52 the pairing of a radio node with a phone app, and position sharing on a map everyone on the mesh can see.53 Its "managed flooding," where a node listens briefly and skips rebroadcasting if another node already did, is a reference point as we tune our own forwarding rules.54 One difference is deliberate. QRV's ham mode never encrypts (§7).
EchoLink, AllStar/app_rpt and IRLP. These three made internet-linked repeaters ordinary. IRLP started in November 1997 to link radio systems across Canada.55 Its inventor, Dave Cameron, VE7LTD, built it around DTMF-dialed four-digit node numbers and multi-channel reflectors.56 EchoLink, designed by Jonathan Taylor, K1RFD, links RF nodes, PCs and phones.5857 AllStarLink's app_rpt turns open-source Asterisk into a repeater controller and VoIP linker.59 QRVnet's voice side copies their best habits. Its nodes hang off a repeater the way an EchoLink or AllStar node does, channels are numbered and dialed by DTMF, and those channels behave like repeaters, with hang time, courtesy tones and CW ID (§5). AllStar and EchoLink get bridges. IRLP integration is planned but deferred (parked in §10), and it will work inside IRLP's own rules.
M17 and Codec2. Codec2 is an open-source speech codec for 700 to 3200 bit/s, built for low-bandwidth HF/VHF digital radio.60 The M17 Project, active since 2019, carries Codec2 voice in an open digital mode.61 Its 4FSK framing is the model for QRV's fast default link.62 We bridge M17 natively; Codec2 voice stays open on the air and decodable by anyone.
Rattlegram. Ahmet Inan's (aicodix) Rattlegram sends up to 170 bytes in an OFDM burst of about a second, 1600 Hz wide, with Schmidl-Cox sync and polar codes, from a phone's speaker to another phone's microphone.63 It showed how much a careful burst modem gets through a plain audio path. Its techniques, and its 0BSD code, are the starting point for the QRV audio modem that forms QRV's floor (§3).
Fldigi, NBEMS and Flmsg. NBEMS proved you don't need special modem hardware or dedicated digital infrastructure to pass verified files and ICS forms. It is open-source software for nearly any computer and any analog radio, on VHF/UHF FM or HF.68 §3 makes the same argument for the audio modem. Flmsg's handling of ICS forms and ARRL radiograms is a model for ours.
JS8Call. JS8Call, built on the WSJT-X/FT8 engine, shows that directed, relayed and store-and-forward messages fit into a keyboard mode on weak HF paths. Heartbeats let stations discover who can hear whom.69 QRV's recently-heard forwarding rule (§3.2) follows the same instinct.
NTS and SHARES. ARRL's National Traffic System keeps trained traffic handlers on local, section, region and area nets every day of the year.70 QRV's five queues follow NTS precedence, and P6 includes the NTS radiogram. SHARES (§6) shows that relaying until delivery is federal practice as well as a ham habit.
If you built or maintain any of these, thank you. If we've described your work wrong, tell us and we'll fix it.
10. Roadmap
Radio first. Internet when available. Never internet-required. Every phase is held to that rule. A feature that only works with QRV Cloud reachable is an IP convenience layered on top, and the radio path has to do the core job without it: holding, forwarding, signing and verifying traffic.
As of this draft, P1 is live at qrvnet.com: listener and ham signup, numbered channels that behave like repeaters (floor control, hang time, courtesy tones, ID), the 9999 echo channel and the DTMF dialplan. The P2 mailbox is in progress. The Android app (P3) has had its first pass. The node (P4) has a first pass in code, tested in simulation and modem loopback. Nothing has crossed a real radio path yet; that is P7a. Phases run in order, and each one's exit gate has to be met before the next starts.
| Phase | Goal and what ships | How it's tested | Exit gate |
|---|---|---|---|
| P1: Server and website | Listener and ham signup, channels and floor control, repeater behavior, echo, legal pages, admin tools | End-to-end smoke test locally; two browsers exchange PCM frames, and a listener is refused the floor | Production hostname registers users; lobby audio works web-to-web |
| P2: Mailbox, store-and-forward, email | Canonical bundle, chat-style mailbox, cursor sync, callsign@ email, signing keys |
Frozen canonical test vectors; a script pushes 1,000 bundles and a duplicate push doesn't fork; a flipped signature byte stores invalid; an oversize email returns 413 |
A callsign mailbox and a real internet address work end to end |
| P3: Android app | PTT over the QRV Cloud voice relay, dial pad with DTMF, chat mailbox, on-device keys | Emulator signup; PTT frame round-trip with no audio before the grant; a phone-signed bundle verifies | Android PTT and mailbox against production |
| P4: Node | Pi or PC plus any FM radio through a sound-card interface with COS/PTT. Analog linking, DTMF and announcements, local mailbox and sync, AFSK/FX.25 compatibility modem (built), QRV audio modem Base profile (planned). Bridges: AllStar and the DVSwitch family (DMR, YSF, D-STAR) over USRP, native M17. EchoLink stubbed and documented; IRLP deferred | CI in simulate mode with no sound card: DTMF vectors, loopback for both modems, USRP and M17 mocks. QRV Cloud is killed mid-test: local inject and readback keep working, and sync uploads each bundle once | Simulate CI green; hardware checklist written |
| P5: Logbook | ADIF round-trip, LoTW log import, duplicate collapsing | Fixture ADIF dedup; a failed import never wipes a log | ADIF round-trips, and one real LoTW import succeeds |
| P6: Forms and paperwork | The §5.4 form set, net-control actions, ICS-309 export, Winlink XML import/export for mapped forms | Every form kind round-trips; a tampered signed form stores invalid; *99 regression |
ICS-213 and radiogram filed, retrieved, and rejected when a required signature is missing |
| P7a: RF field trial | Two nodes, a closed test repeater, one signed bundle over the audio modem's Base profile and one over AFSK | Dedup observed, duty cycle and idle-before-data verified, fallback to Base observed, Direwolf cross-decodes our FX.25 frame | A trustee who isn't the author follows the hardware smoke test and moves one bundle |
| P7b to P7d | Media-server voice (only after measuring the current voice relay on a real net), iOS, and a Part 90 LMR mode (only with counsel) | Mouth-to-ear numbers; Android's mailbox and PTT tests run on an iPhone; an LMR grant can't key a ham PTT | Per sub-phase |
After P7, work continues in parallel tracks. None of them is built yet.
- Pilots with ARES units. After P7a, drills run alongside existing Winlink and voice procedures, including partitioned scenarios, with results written up as field notes (§11).
- Apps everywhere, web parity. Windows, macOS and Linux desktop apps and iOS (P7c), all from the same codebase as Android. Anything an operator can do in an app, they can do in a browser.
- Node packaging. Install packages and ready-to-flash Pi images built around the existing systemd service, with a configuration checklist a trustee can follow.
- Local LAN mesh. Nodes on a shelter or EOC LAN find each other and sync with no internet, using the same summary-vector exchange they use with QRV Cloud.
- RF link tiers. The audio modem's Wide, Standard and Fast profiles with adaptive selection, measured on real repeaters and data ports; negotiation (§3); and 9600 4FSK with M17 packet mode (formerly parked).
- Beacons and the map. APRS-style position beacons and the opt-in map, bulletins on a schedule, and an APRS-IS bridge (off by default).
- SHARES support. Rosters, handoff logging and shared ICS forms (§6). A separate IP-only SHARES workspace happens only with the SHARES Program Office's agreement.
- Open spec, open node, public API. The bundle format is already published. The node software goes open source, and the client API gets documented as a public API so clubs can build on it.
- Documentation and training. A trustee guide, a net-control guide, drill scripts and the hardware smoke test, written for volunteers.
- Parked: Winlink RMS gateway and the IRLP adapter, built within IRLP's rules once they agree.
10.1 HF track: regional and long-haul store-and-forward
Design and roadmap; nothing in this track is built. VHF/UHF FM covers a county. HF closes the gaps between counties and states. The track follows the layer rule from §2: it uses the HF rig a ham already owns, through its audio and CAT/PTT interface, with open sound-card modems and no new radio.
HF data from 160 m through 10 m, except 60 m, falls under §97.307(f)(3). It must use a specified digital code (§97.309(a)), and any technique has to be publicly documented.25 The authorized bandwidth is 2.8 kHz.24 The FCC removed the old 300-baud HF symbol-rate cap and replaced it with the 2.8 kHz bandwidth limit, effective January 8, 2024.76 The 300-baud cap now survives only on 2200 m and 630 m.24 The January 2026 amendment opened 5351.5 to 5366.5 kHz on 60 m. That segment carries data under a 2.8 kHz limit at 9.15 W ERP, with 100 W ERP on the four discrete channels; it is secondary and open to General class and above.7724 No encryption on any band (§7).
The VHF/UHF audio modem and AFSK mode stay on FM. HF uses its own open, publicly documented modes:
- ARDOP. Open protocol; ardopcf is an MIT-licensed cross-platform implementation. Its maintainer has stopped development, so QRV treats ARDOP as a candidate and won't depend on it.78
- FreeDATA. An open-source HF platform built on codec2 data modes, with a REST API. Development has slowed.79
- Fldigi modes. PSK, MFSK, Olivia and MT63, which NBEMS groups already run.8068
- JS8. Weak-signal messaging with heartbeats, relays and store-and-forward.69
VARA HF is widely used, but it is commercial and vendor-licensed.11 It can be an operator-supplied option. It is never the default, and nothing requires it. Every mode is checked against the 2.8 kHz limit before it is enabled.
HF nodes hold and forward under the same rules as §4, retuned for scarce airtime:
- Gateways between VHF islands. A county's VHF/FM mesh hands bundles to its HF gateway. That gateway forwards them to another region's HF node, which drops them into its own local mesh as in §5. No internet sits anywhere in that chain.
- Scheduled, propagation-aware windows. Gateways meet in agreed forwarding windows and pick the band by time of day and recent results. For NVIS out to about 500 km, the reliable range is 1.8 to 8 MHz, typically 80 m at night and 40 m by day, with 60 m as a further option.81 Automatic band and path selection uses decode history from the heard list.
- A calling frequency and a heard list. Between windows, gateways monitor a calling frequency with JS8-style heartbeats.69 The resulting heard list drives forwarding, the same instinct as the recently-heard rule in §3.2.
- Inventory before transfer. Peers swap a summary vector or Bloom filter first (§4) and send only the bundles the other side lacks.
- Precedence first. The five queues apply, so emergency traffic leaves before routine, every window.
- Fragments that survive a fade. Large bundles go in fragments. After a fade, the receiver asks for the missing pieces (§5.1) and the transfer resumes in the next window instead of starting over.
- Custody handoff. On HF, custody acks are on by default. The sender keeps a bundle until the next node acknowledges taking custody, then drops it to cache. That is DTN's custody-transfer idea (§9).46
- Multi-hop relay. When two gateways can't hear each other, a third that hears both carries the traffic, within the RF hop limit.
- One-to-many bulletins. A bulletin goes out once on a schedule. Receivers fill gaps by asking for fragments, with no per-station session.
- Regional HF nets. ARES gateways check in on regional nets. SHARES interop happens at the EOC, as a logged handoff (§6), never as SHARES content on amateur RF.
- Later: ALE-style linking. Scanning a channel list, sounding, and picking the best channel automatically. Hams already run open ALE nets.82
10.2 Future phase: QRV hardware and wideband simplex data
Roadmap; nothing in this phase is built. A QRV radio runs analog FM alongside QRV's digital modes. Its key feature is on-demand wideband simplex: two radios agree on the narrow link ("3 MB of imagery for you; meet on W2"), hop together to a wide channel for the transfer, then return. The narrow link remains the rendezvous and control path. An HF-capable variant or interface brings the same node software to an existing HF rig through audio, CAT and PTT.
The rules shape the channel plan:
- 33 cm (902-928 MHz) is the only home for channels around 500 kHz. §97.305(c) allows data, test and spread spectrum across the band under §97.307(f)(7), which sets no symbol-rate or bandwidth cap. §97.307(a) still requires no more bandwidth than the information rate needs.2324 The ARRL band plan sets aside 909-915, 915-921 and 921-927 MHz for broadband multimedia including SS, and regional coordinators' plans take precedence.29 Amateurs are secondary. They must accept interference from ISM devices, can't transmit near White Sands in Texas and New Mexico or on certain segments in parts of Colorado and Wyoming, and are limited to 50 W PEP within 241 km of White Sands.2227
- Spread spectrum on 33 cm and 70 cm stays inside §97.311 and 10 W PEP (§97.313(j)), with its spreading parameters published.2627
- 70 cm data tops out at 100 kHz and a 56-kilobaud symbol rate (§97.307(f)(6)).24 Line A, the land-mobile areas near Buffalo, Cleveland and Detroit, and the US270 50 W areas (including near Beale AFB and Otis AFB) are enforced by location.222728
- 2 m stays narrow, at 20 kHz and 19.6 kilobaud, for the audio modem, AFSK, 9600 4FSK and rendezvous.24
The radio's firmware enforces band, bandwidth, power and location limits, so the operator doesn't have to remember them at 0300.
11. Call to action
We're looking for a small number of groups to pilot this with us early:
- ARES/RACES/EmComm groups willing to run QRVnet alongside your existing Winlink and voice procedures in a drill, and tell us where it breaks. We especially want ICS-213/309 workflows and partitioned scenarios.
- Repeater owners and trustees willing to host a node on a test basis (voice linking first, data bursts only if and when you're comfortable) and to hold us to the duty-cycle and courtesy rules above.
- Net managers who want to try roster, check-in and 309 tooling on a weekly net.
- Served-agency liaisons and SHARES participants who can tell us what a coordination/tracking layer would need to be useful without stepping on federal procedures.
Sign up and get in touch through the QRVnet site: qrvnet.com.
73, and thanks for reading this far.
Wayne, KC9ZRI · Rift Software
References
-
ARRL, "ARES: When All Else Fails." https://www.arrl.org/ares ↩
-
Winlink Development Team, "Open B2F: Winlink Message Structure and B2 Forwarding Protocol," rev. Feb. 2018. https://winlink.org/B2F ↩↩↩↩
-
Winlink, "Introducing the Winlink Hybrid Network." https://winlink.org/HybridNetwork ↩↩↩↩↩↩
-
P. Sherrod, W4PHS, "Overview of the Winlink 'Hybrid' Network" (operational modes, P2P disadvantages). https://philsherrod.com/Winlink/Winlink_Operational_Modes.pdf ↩↩↩
-
Winlink, "Radio-Only Winlink for the Traffic Handler." https://winlink.org/sites/default/files/RMSE_FORMS/radio-only-winlink-for-the-traffic-handler.pdf ↩
-
Winlink, "Quick Setup Guide for VARA FM for Winlink with Signalink on Windows." https://winlink.org/sites/default/files/RMSE_FORMS/new_quick_setup_guide_for_vara_fm_for_winlink_with_signalink_on_windows_v20190409c.pdf ↩
-
Winlink, "Frequently Asked Questions about Winlink 2000" (Q167; "Life of an unread message: 21 days"). https://winlink.org/sites/default/files/download/wl2k_faq_20230311.pdf ↩↩
-
Winlink, "Winlink Express" (system requirements). https://winlink.org/WinlinkExpress ↩
-
Pat, a cross-platform Winlink client. https://getpat.io/ ↩↩
-
Winlink, "MacWinlink: A Native macOS Client for Winlink," Sept. 21, 2026 (public beta). https://winlink.org/macwinlink ↩↩
-
VARA Modem, licensing and mode specifications. https://varamodem.com/ ↩↩
-
VarAC HF discussion forum, "maximum data rate supported" (free VARA HF limited to SL5). https://www.varac-hamradio.com/group/varac-hf-discussion-forum/discussion/2b821ebf-7049-4d73-9b74-2bde05aee09f ↩
-
Direwolf soundcard modem/TNC (AX.25, FX.25, KISS). https://github.com/wb2osz/direwolf ↩
-
FEMA Emergency Management Institute, ICS Resource Center, ICS forms. https://training.fema.gov/icsresource/icsforms.aspx ↩↩
-
47 CFR § 97.105, Control operator duties. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.105 ↩
-
47 CFR § 97.113, Prohibited transmissions. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.113 ↩↩
-
47 CFR § 97.115, Third party communications. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.115 ↩
-
47 CFR § 97.119, Station identification. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.119 ↩
-
47 CFR § 97.221, Automatically controlled digital station. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-C/section-97.221 ↩
-
47 CFR § 97.303, Frequency sharing requirements (paras. (b), (e), (m), (n)). https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.303 ↩↩
-
47 CFR § 97.305, Authorized emission types. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.305 ↩
-
47 CFR § 97.307, Emission standards (para. (f)(5) to (7)), as amended through 91 FR 1431 (Jan. 14, 2026). https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.307 ↩↩↩↩↩↩↩
-
47 CFR § 97.309, RTTY and data emission codes. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.309 ↩↩
-
47 CFR § 97.311, SS emission types. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.311 ↩
-
47 CFR § 97.313, Transmitter power standards (paras. (f), (g), (j)). https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-D/section-97.313 ↩↩↩
-
ARRL, "47 CFR § 2.106: Footnote US270" (70 cm power-limited areas incl. Beale AFB and Otis AFB). https://www.arrl.org/us270 ↩
-
ARRL, "Band Plan" (70 cm and 33 cm). https://www.arrl.org/band-plan ↩
-
SpaceX, "Standard 4 X Kit Specifications" (average power 75 to 100 W; 110° field of view). https://api.starlink.com/public-files/specification_sheet_standard.pdf ↩
-
SpaceX, "Mini Specifications" (average power 25 to 40 W; 110° field of view). https://api.starlink.com/public-files/specification_sheet_mini.pdf ↩
-
S. Ehsani, B. Pallakonda and P. K. Mishra, "Mapping the Storm: Geospatial Impacts of Severe Weather on LEO Network Performance," ACM SIGSPATIAL '25 (arXiv preprint). https://arxiv.org/html/2606.01724v1 ↩
-
M. Kan, "Using Starlink Roam in a Congested Area? SpaceX May Block Your Access," PCMag, Apr. 17, 2025. https://www.pcmag.com/news/using-starlink-roam-in-a-congested-area-spacex-may-block-your-access ↩
-
D. Jordan, "Elon Musk says he withheld Starlink over Crimea to avoid escalation," BBC News, Sept. 8, 2023. https://www.bbc.com/news/world-europe-66752264 ↩
-
C. Reichert, "Starlink Acknowledges Software Failure Behind Outage of Satellite Internet Service," CNET, July 24-25, 2025 (quoting Michael Nicolls). https://www.cnet.com/news-live/starlink-acknowledges-software-failure-behind-outage-of-satellite-internet-service/ ↩
-
M. Kan, "SpaceX Traces Starlink Outage to Network Upgrade," PCMag, July 27, 2025. https://www.pcmag.com/news/spacex-traces-starlink-outage-to-network-upgrade ↩
-
Clarus Networks, "How the Starlink network works: satellites, laser links, ground stations and points of presence explained," Aug. 3, 2026. https://www.clarus-networks.com/2026/08/03/how-the-starlink-network-works-satellites-laser-links-ground-stations-and-points-of-presence-explained/ ↩
-
S. Losey, "SpaceX shut down a Russian electromagnetic warfare attack in Ukraine last month, and the Pentagon is taking notes," C4ISRNET, Apr. 20, 2022 (quoting Dave Tremper). https://www.c4isrnet.com/air/2022/04/20/spacex-shut-down-a-russian-electromagnetic-warfare-attack-in-ukraine-last-month-and-the-pentagon-is-taking-notes/ ↩
-
A. Horton, "Russia tests secretive weapon to target SpaceX's Starlink in Ukraine," The Washington Post, Apr. 18, 2023 (Discord leaks / Tobol). https://www.washingtonpost.com/national-security/2023/04/18/discord-leaks-starlink-ukraine/ ↩
-
Defense Express, "Does russian 14Ts227 Tobol System Have the Power to Suppress Starlink," Apr. 20, 2023. https://en.defence-ua.com/weapon_and_tech/does_russian_14ts227_tobol_system_have_the_power_to_suppress_starlink-6454.html ↩
-
S. Skove, "Using Starlink Paints a Target on Ukrainian Troops," Defense One, Mar. 23, 2023. https://www.defenseone.com/threats/2023/03/using-starlink-paints-target-ukrainian-troops/384361/ ↩
-
Izvestia / Center for Unmanned Systems and Technologies (Andrey Bezrukov), "Russia has developed the Kalinka system for calculating Starlink signals," Dec. 14, 2024. https://en.iz.ru/en/1807283/2024-12-14/russia-has-developed-kalinka-system-calculating-starlink-signals ↩
-
L. Kiennemann, "Russia faces challenges trying to jam Starlink in Ukraine," France 24 Observers, July 3, 2026. https://www.france24.com/en/europe/20260703-ukraine-russia-faces-challenge-jamming-starlink ↩↩↩↩↩
-
Ministry of Defence of Ukraine, "Starlink terminals on the whitelist remain operational, while russian terminals have already been blocked," Feb. 5, 2026. https://mod.gov.ua/en/news/starlink-terminals-on-the-whitelist-remain-operational-while-russian-terminals-have-already-been-blocked ↩
-
TAPR, "AX.25 Link Access Protocol for Amateur Packet Radio," Version 2.2, July 1998. https://www.ax25.net/AX25.2.2-Jul%2098-2.pdf ↩
-
V. Cerf et al., "Delay-Tolerant Networking Architecture," RFC 4838, April 2007. https://www.rfc-editor.org/rfc/rfc4838.html ↩↩
-
IETF, "Bundle Protocol Version 7," RFC 9171 (Standards Track; supersedes experimental RFC 5050). https://www.rfc-editor.org/rfc/rfc9171.html ↩
-
ARRL News, "APRS Developer Bob Bruninga, WB4APR, SK," Feb. 9, 2022. https://www.arrl.org/news/aprs-developer-bob-bruninga-wb4apr-sk ↩
-
B. Bruninga, WB4APR, "APRS: Automatic Packet Reporting System" (homepage). http://www.aprs.org/aprs.html ↩
-
B. Bruninga, WB4APR, "Fixing the 144.39 APRS Network: The New n-N Paradigm." http://www.aprs.org/fix14439.html ↩
-
Meshtastic, "Introduction." https://meshtastic.org/docs/introduction/ ↩
-
Meshtastic, "Channel Configuration." https://meshtastic.org/docs/configuration/radio/channels/ ↩
-
Meshtastic, "Map & Waypoints" (Android app). https://meshtastic.org/docs/software/android/user/map-and-waypoints/ ↩
-
Meshtastic, "Mesh Broadcast Algorithm" (managed flooding). https://meshtastic.org/docs/overview/mesh-algo/ ↩
-
IRLP, "IRLP Background Information." https://www.irlp.net/background.html ↩
-
Wikipedia, "Internet Radio Linking Project" (node numbering, DTMF, reflectors, inventor). https://en.wikipedia.org/wiki/Internet_Radio_Linking_Project ↩
-
EchoLink, "Introducing EchoLink." https://www.echolink.org/ ↩
-
Wikipedia, "EchoLink" (designed by Jonathan Taylor, K1RFD). https://en.wikipedia.org/wiki/EchoLink ↩
-
AllStarLink, "Welcome to AllStarLink" (Asterisk + app_rpt). https://allstarlink.org/ ↩
-
Codec 2 source repository (drowe67/codec2 on GitHub). https://github.com/drowe67/codec2 ↩↩
-
M17 Project. https://m17project.org/ ↩
-
M17 Project, "M17 Protocol Specification," v2.0.9 (Oct. 4, 2026). https://spec.m17project.org/; source at https://github.com/M17-Project/M17_spec ↩↩
-
Ahmet Inan (aicodix), Rattlegram source (app/src/main/cpp/encoder.hh), app description and 0BSD LICENSE. https://github.com/aicodix/rattlegram ↩↩↩↩↩↩↩↩
-
WB2OSZ, "Building a Better Demodulator for APRS / AX.25 Packet Radio, Part 1, 1200 Baud AFSK," Direwolf. https://github.com/wb2osz/direwolf/blob/master/doc/A-Better-APRS-Packet-Demodulator-Part-1-1200-baud.pdf ↩
-
T. M. Schmidl and D. C. Cox, "Robust Frequency and Timing Synchronization for OFDM," IEEE Transactions on Communications, vol. 45, no. 12, pp. 1613 to 1621, Dec. 1997. https://doi.org/10.1109/26.650240 ↩
-
Wikipedia, "Orthogonal frequency-division multiplexing" (guard interval, simplified equalization, PAPR). https://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing ↩↩↩↩↩
-
WB2OSZ, "2400 & 4800 bps PSK for APRS / Packet Radio," Direwolf. https://github.com/wb2osz/direwolf/blob/master/doc/2400-4800-PSK-for-APRS-Packet-Radio.pdf ↩↩↩
-
ARRL, "Narrow Band Emergency Messaging Software (NBEMS)." https://www.arrl.org/nbems ↩↩
-
JS8Call, project homepage. https://js8call.com/ ↩↩↩
-
ARRL, "National Traffic System (NTS)." https://www.arrl.org/nts ↩
-
S. Josefsson and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)," RFC 8032, January 2017 (Ed25519: 32-byte public keys, 64-byte signatures, SHA-512). https://www.rfc-editor.org/rfc/rfc8032.html ↩
-
Winlink, "Winlink Express Forms Information." https://winlink.org/WinlinkExpressForms ↩↩
-
Winlink Development Team, "Re post: Standard Forms Library and Non-Standard Forms," Apr. 14, 2021. https://winlink.org/content/re_post_standard_forms_library_and_non_standard_forms ↩
-
CISA, "Position Task Book for the Position of Auxiliary Communicator (AUXC)" (go-kit list: "Appropriate ICS forms and Radio Logs (Form 309)"). https://www.cisa.gov/sites/default/files/publications/CISA%2520AUXCOMM%2520PTB%2520-%252012162020%2520-%2520508.pdf ↩↩
-
ARRL, Public Service Communications Manual, "Chapter Six: ARRL Precedences and Handling Instructions." https://www.arrl.org/chapter-six-arrl-precedences-and-handling-instructions ↩
-
FCC, "Amateur Radio Service Rules To Permit Greater Flexibility in Data Communications," Report and Order, 88 FR 85126, Dec. 7, 2023 (effective Jan. 8, 2024). https://www.federalregister.gov/documents/2023/12/07/2023-26770/amateur-radio-service-rules-to-permit-greater-flexibility-in-data-communications ↩
-
FCC, "Implementation of the Final Acts of the World Radiocommunication Conference (Geneva, 2015) (WRC-15), Other Allocation Issues, and Related Rule Updates," 91 FR 1405, Jan. 14, 2026 (effective Feb. 13, 2026; 60 m amendments to §§97.303, 97.305, 97.307, 97.313). https://www.federalregister.gov/documents/2026/01/14/2026-00587/implementation-of-the-final-acts-of-the-world-radiocommunication-conference-geneva-2015-wrc-15-other ↩
-
P. LaRue, AI7YN, ardopcf (open-source Ardop implementation, MIT licence; development discontinued). https://github.com/pflarue/ardop ↩
-
FreeDATA, open-source HF messaging platform using codec2 data modes. https://github.com/DJ2LS/FreeDATA ↩
-
Wikipedia, "Fldigi" (supported modes include PSK, MFSK, MT63, Olivia). https://en.wikipedia.org/wiki/Fldigi ↩
-
Wikipedia, "Near vertical incidence skywave." https://en.wikipedia.org/wiki/Near_vertical_incidence_skywave ↩
-
Wikipedia, "Automatic link establishment" (amateur use and HFLink open ALE nets). https://en.wikipedia.org/wiki/Automatic_link_establishment ↩