Technical white paper · Design draft, pre-field-trial

QRVnet: Offline-First Store-and-Forward Messaging for Amateur EmComm

For ARES, RACES and EmComm groups, served-agency liaisons, SHARES participants, net managers and repeater owners.

Wayne, KC9ZRI · Rift Software · October 2026 · qrvnet.com

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:

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.

The reasons are practical.

  1. 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.
  2. 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.
  3. 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.

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:

  1. It uses more of the roughly 300 to 3000 Hz voice passband,67 about 2.4 kHz or some 384 carriers.
  2. It adapts modulation to the link: BPSK, QPSK, 8PSK or 16QAM, with a code rate chosen from the SNR measured on the preamble.
  3. It streams. Shorter guard intervals and continuous multi-frame transmissions spread one sync across many frames instead of paying for it every second.
  4. Bulk transfers use longer frames, which spread the overhead further.
  5. 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:

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:

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:

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.

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.

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.

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:

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:

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

QRVnet architecture overview simplex via repeater audio RF output Starlink/LAN internet SMTP App + HT sound-card cable Shelter node mailbox + modem Cut-off neighborhood HT / mobile + app Club FM repeater stock analog controller Repeater-site node mailbox, DTMF, bridges EOC node net control, ICS-309 QRV Cloud permanent log, email, floor control Served agency internet email Bridges AllStar · EchoLink M17 · DVSwitch APRS-IS RF (OFDM / FM audio) IP when available (LAN / internet / Starlink)
Figure 1. QRVnet as a layer over existing infrastructure

The main components:

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

Flow A app OFDM simplex also heard forwards later when backhaul Shelter operator fills ICS-213 Shelter node compress · sign Hilltop node holds if EOC absent EOC node reassemble · dedup Net control log 309 line QRV Cloud archive RF (OFDM / FM audio) IP when available (LAN / internet / Starlink)
Figure 2. Flow A: ICS-213 from a shelter on simplex to the EOC
  1. 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).
  2. 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.
  3. The node waits for a clear channel and sends data bursts on the agreed simplex frequency.
  4. 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.
  5. 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

Flow B Starlink up no backhaul: text over RF sync SMTP ≤5 MiB Field operator email + photo Field node bundle type=email QRV Cloud callsign@qrvnet.com Served agency ordinary inbox Any node with backhaul RF (OFDM / FM audio) IP when available (LAN / internet / Starlink)
Figure 3. Flow B: email from the field to a served agency
  1. A field operator writes an email to the Red Cross liaison's ordinary address, with a photo attached.
  2. 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.
  3. 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.
  4. 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

Flow C OFDM, idle-only ≤10% duty first to reach internet Neighborhood ham HT + phone app Club 2 m repeater unchanged; trustee permits data bursts EOC node interest: addressee Other repeater-site node (stores copy) QRV Cloud + mailboxes RF (OFDM / FM audio) IP when available (LAN / internet / Starlink)
Figure 4. Flow C: a cut-off neighborhood relaying through a generic FM repeater
  1. 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.
  2. 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.
  3. 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.
  4. 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:

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:

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:

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.

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:

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:

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:

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:

Sign up and get in touch through the QRVnet site: qrvnet.com.

73, and thanks for reading this far.

Wayne, KC9ZRI · Rift Software


References


  1. ARRL, "ARES: When All Else Fails." https://www.arrl.org/ares ↩

  2. Winlink Development Team, "Open B2F: Winlink Message Structure and B2 Forwarding Protocol," rev. Feb. 2018. https://winlink.org/B2F ↩↩↩↩

  3. Winlink, "Introducing the Winlink Hybrid Network." https://winlink.org/HybridNetwork ↩↩↩↩↩↩

  4. P. Sherrod, W4PHS, "Overview of the Winlink 'Hybrid' Network" (operational modes, P2P disadvantages). https://philsherrod.com/Winlink/Winlink_Operational_Modes.pdf ↩↩↩

  5. Winlink, "Radio-Only Winlink for the Traffic Handler." https://winlink.org/sites/default/files/RMSE_FORMS/radio-only-winlink-for-the-traffic-handler.pdf ↩

  6. 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 ↩

  7. 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 ↩↩

  8. Winlink, "Winlink Express" (system requirements). https://winlink.org/WinlinkExpress ↩

  9. Pat, a cross-platform Winlink client. https://getpat.io/ ↩↩

  10. VARA Modem, licensing and mode specifications. https://varamodem.com/ ↩↩

  11. 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 ↩

  12. Direwolf soundcard modem/TNC (AX.25, FX.25, KISS). https://github.com/wb2osz/direwolf ↩

  13. CISA, "SHAred RESources (SHARES) High Frequency (HF) Radio Program." https://www.cisa.gov/resources-tools/programs/shared-resources-shares-high-frequency-hf-radio-program ↩↩↩

  14. CISA, "SHARES FAQs." https://www.cisa.gov/resources-tools/programs/shared-resources-shares-high-frequency-hf-radio-program/shares-faqs ↩↩↩↩↩

  15. FEMA Emergency Management Institute, ICS Resource Center, ICS forms. https://training.fema.gov/icsresource/icsforms.aspx ↩↩

  16. 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 ↩

  17. 47 CFR § 97.113, Prohibited transmissions. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.113 ↩↩

  18. 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 ↩

  19. 47 CFR § 97.119, Station identification. https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-B/section-97.119 ↩

  20. 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 ↩

  21. 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 ↩↩

  22. 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 ↩

  23. 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 ↩↩↩↩↩↩↩

  24. 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 ↩↩

  25. 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 ↩

  26. 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 ↩↩↩

  27. ARRL, "47 CFR § 2.106: Footnote US270" (70 cm power-limited areas incl. Beale AFB and Otis AFB). https://www.arrl.org/us270 ↩

  28. ARRL, "Band Plan" (70 cm and 33 cm). https://www.arrl.org/band-plan ↩

  29. 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 ↩

  30. SpaceX, "Mini Specifications" (average power 25 to 40 W; 110° field of view). https://api.starlink.com/public-files/specification_sheet_mini.pdf ↩

  31. 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 ↩

  32. 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 ↩

  33. 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 ↩

  34. 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/ ↩

  35. 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 ↩

  36. 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/ ↩

  37. 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/ ↩

  38. 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/ ↩

  39. 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 ↩

  40. 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/ ↩

  41. 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 ↩

  42. 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 ↩↩↩↩↩

  43. 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 ↩

  44. 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 ↩

  45. V. Cerf et al., "Delay-Tolerant Networking Architecture," RFC 4838, April 2007. https://www.rfc-editor.org/rfc/rfc4838.html ↩↩

  46. IETF, "Bundle Protocol Version 7," RFC 9171 (Standards Track; supersedes experimental RFC 5050). https://www.rfc-editor.org/rfc/rfc9171.html ↩

  47. ARRL News, "APRS Developer Bob Bruninga, WB4APR, SK," Feb. 9, 2022. https://www.arrl.org/news/aprs-developer-bob-bruninga-wb4apr-sk ↩

  48. B. Bruninga, WB4APR, "APRS: Automatic Packet Reporting System" (homepage). http://www.aprs.org/aprs.html ↩

  49. B. Bruninga, WB4APR, "Fixing the 144.39 APRS Network: The New n-N Paradigm." http://www.aprs.org/fix14439.html ↩

  50. Meshtastic, "Introduction." https://meshtastic.org/docs/introduction/ ↩

  51. Meshtastic, "Channel Configuration." https://meshtastic.org/docs/configuration/radio/channels/ ↩

  52. Meshtastic, "Map & Waypoints" (Android app). https://meshtastic.org/docs/software/android/user/map-and-waypoints/ ↩

  53. Meshtastic, "Mesh Broadcast Algorithm" (managed flooding). https://meshtastic.org/docs/overview/mesh-algo/ ↩

  54. IRLP, "IRLP Background Information." https://www.irlp.net/background.html ↩

  55. Wikipedia, "Internet Radio Linking Project" (node numbering, DTMF, reflectors, inventor). https://en.wikipedia.org/wiki/Internet_Radio_Linking_Project ↩

  56. AllStarLink, "Welcome to AllStarLink" (Asterisk + app_rpt). https://allstarlink.org/ ↩

  57. Codec 2 source repository (drowe67/codec2 on GitHub). https://github.com/drowe67/codec2 ↩↩

  58. M17 Project. https://m17project.org/ ↩

  59. M17 Project, "M17 Protocol Specification," v2.0.9 (Oct. 4, 2026). https://spec.m17project.org/; source at https://github.com/M17-Project/M17_spec ↩↩

  60. Ahmet Inan (aicodix), Rattlegram source (app/src/main/cpp/encoder.hh), app description and 0BSD LICENSE. https://github.com/aicodix/rattlegram ↩↩↩↩↩↩↩↩

  61. 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 ↩

  62. 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 ↩

  63. Wikipedia, "Orthogonal frequency-division multiplexing" (guard interval, simplified equalization, PAPR). https://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing ↩↩↩↩↩

  64. 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 ↩↩↩

  65. ARRL, "Narrow Band Emergency Messaging Software (NBEMS)." https://www.arrl.org/nbems ↩↩

  66. JS8Call, project homepage. https://js8call.com/ ↩↩↩

  67. ARRL, "National Traffic System (NTS)." https://www.arrl.org/nts ↩

  68. 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 ↩

  69. Winlink, "Winlink Express Forms Information." https://winlink.org/WinlinkExpressForms ↩↩

  70. 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 ↩

  71. 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 ↩↩

  72. ARRL, Public Service Communications Manual, "Chapter Six: ARRL Precedences and Handling Instructions." https://www.arrl.org/chapter-six-arrl-precedences-and-handling-instructions ↩

  73. 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 ↩

  74. 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 ↩

  75. P. LaRue, AI7YN, ardopcf (open-source Ardop implementation, MIT licence; development discontinued). https://github.com/pflarue/ardop ↩

  76. FreeDATA, open-source HF messaging platform using codec2 data modes. https://github.com/DJ2LS/FreeDATA ↩

  77. Wikipedia, "Fldigi" (supported modes include PSK, MFSK, MT63, Olivia). https://en.wikipedia.org/wiki/Fldigi ↩

  78. Wikipedia, "Near vertical incidence skywave." https://en.wikipedia.org/wiki/Near_vertical_incidence_skywave ↩

  79. Wikipedia, "Automatic link establishment" (amateur use and HFLink open ALE nets). https://en.wikipedia.org/wiki/Automatic_link_establishment ↩