hfmodem

Implementation evidence

Results for hfmodem's data, linking and text modes. PACTOR-1/2/3 and VARA are beta. ARDOP, Lanner’s RTTY/SITOR-B/NAVTEX modes, voice and CW are alpha. PACTOR-4 and all other modes are experimental. RF reception, gateway transfers, independent bench decodes and simulations are identified separately.

PACTOR

Winlink mail sent and received through WS8EOC over hfmodem’s PACTOR-3. Four messages also received through KB5LZK over PACTOR-1, with a normal session close.

ResultEvidence and conditionsRecord
PACTOR-3 outbound body acceptedW9SSJ via WS8EOC; gateway returned FS Y and FF; local FQ queuedStation log
PACTOR-3 message receivedW9SSJ via WS8EOC; complete message savedStation log
PACTOR-3 outbound mail deliveredW9SSJ via WS8EOC; receipt confirmed by the operatorMessage 9WQNVWBDLVOY
Four messages fetched; session closed normallyKB5LZK; PACTOR-1 throughout the exchange. Message IDs: JWKY65C2OZES, FP8L9JM4Q2L3, YQKB3UDBH1KG, J7VQ9ZYDX9L5Station log
PACTOR-1 payload delivered byte-exact to the peer's hostVirtual audio with Sailer's (HB9JNX) hf-pactor software; frozen-counter and altered-payload negative controlsBench record
PACTOR-1 rate reduction in both directionsBench tests cover local fallback and requests for the peer to halve its rateTest suite
PACTOR-2 SL1 entry frame decodedIndependent monitor on the benchStation bench record
PACTOR-3 payload prefixes decoded at all six speed levelsReference decoder over virtual audio; idle/CR normalization, wider lock search at SL1/2Bench record
PACTOR-3 grants and entry packets receivedStation summary of 68 attempts: four reached a grant and two reached a grant plus a decoded entry packet. Separate 40 m and 80 m records contain banner and packet payload fragmentsStation logs

PACTOR-3 mail transfer is demonstrated in both directions through WS8EOC. The outbound body acceptance and inbound saved message establish mail transfer; a confirmed PACTOR link shutdown is a separate result. Reliability across gateways remains open. PACTOR-2 evidence is at the bench level. The association between status-byte bits 4–5 and a PACTOR-3 grant is an inference from two gateways; see capability negotiation.

Recorded PACTOR-3 sessions with VE1YZ and WS8EOC are in the evidence index.

PACTOR-4

Experimental, partial support. No successful on-air PACTOR-4 mail transfer has been demonstrated. The PACTOR-1 and PACTOR-3 mail results above do not establish PACTOR-4 interoperability. Recorded gateway greetings from VE3KPG and K4SPB show the current reach: PACTOR-4 receive through the Winlink prompt, then no completed data turn.

AreaPresent supportLimit
ReceptionChirp, changeover and selected normal-frame decoding; CRC-valid packets from recordingsCoverage depends on frame type and speed. Normal-long SL6–10 decoders are standalone offline diagnostics, outside live receiver dispatch
TransmissionRobust-short entry and control waveforms, chirp, changeover and selected normal-frame renderersIncomplete waveform and rate coverage; robust-long transmission is unimplemented
Link and host streamExperimental entry, acknowledgments, retries, turn changes and transparent host dataRecorded replay and simulated-peer tests do not establish reliable gateway operation
WinlinkRecorded offline replay reaches a CMS prompt and queues B2F login/proposal trafficNo demonstrated complete on-air message transfer or destination delivery

--p4-link and --p4-mail select development experiments. They are not part of the guided Winlink quickstart. See packet framing and coverage for the supported frame families and remaining gaps. The PACTOR-4 protocol guide also covers coding, interleavers and the C2 PRNG.

Mode guide · ARQ implementation

VARA

Version 0.4.0 includes Kestrel chat with VarAC peers at BW500, BW2300 and BW2750, including CQ, beacons, QSY and VMail. Passive reception includes QSO transcripts and slot following. BBS support includes directory requests, validated downloads and serving a selected directory. The automatic receiver and sender have recorded-replay and software round-trip tests; live RF interoperability remains unverified. Raw transfer capture does not validate a download. See BBS evidence and limits (not included in this release). See the chat guide.

Mail reception through K0SI and confirmed outbound delivery through KB8AY. Multiple deliveries confirmed by the operator. VARA supports high speed capable and speed limited links. The transmit and receive codecs cover the level tables for BW500, BW2300 and BW2750; the named RF sessions below do not establish RF performance at every level.

ResultEvidence and conditionsRecord
Three complete message files and one partial file savedK0SI; four mail offers, BW2300, 40 m, 7101.8 kHz center, 10 W; acknowledged closeStation log
Secure login accepted and outbound body acceptedKB8AY; BW2750, 40 m. CMS challenge answered, proposal V15F3FF1BAF4 accepted with FS Y, body followed by FF, session closed with FQStation log
Outbound message delivered to its internet addressKB8AY; BW2300, 40 m, 7101.5 kHz center; gateway acceptance and destination receipt confirmedMessage NL03TXWQ8SGL
Multiple outbound deliveries confirmedReceipt in Gmail confirmed by the operator; gateway and session details unspecifiedOperator report
CRC-valid VarAC receive at L5, L6 and L724 October; passive BW500, slot 1, 20 m; forwarded VMail fragments; RF endpoints unknown125-second recording
All 41 connect tones recoveredMichigan KiwiSDR recording of a KC9GHZ call on 7103.5 kHzRemote recording

Inbox confirmation establishes delivery of the named message through KB8AY.

Mode guide · Session implementation

ARDOP

The besra implementation has transferred mail in both directions, in separate gateway sessions.

ResultEvidence and conditionsRecord
Message fetchedWW2MI gateway sessionStation log
Outbound message deliveredWW2MI gateway session with delivery confirmationMessage 2KX2HWM919HR
Three messages fetched in one sessionW6IDS gateway sessionStation log
Bidirectional cross-decode across all 59 frame typesardopcf reference codecBench record

Reference-codec and recording-dependent tests report skips when those inputs are absent. pytest -rs lists them.

Mode guide

sabir

Sabir is experimental and unfinished. Its protocol and wire format are subject to change. Beacons have been decoded from two remote receivers; session traffic and host integration are exercised through simulated channels.

ComponentDemonstrated behaviorEvidence
Beacon reception40 m transmissions decoded from public receivers 103 and 302 miles awayRemote recordings, decoded with hfmodem
ARQ and retransmissionSelective codeword acknowledgement, timeout retry and payload resegmentation without duplicate deliveryState-machine tests and channel simulations
Turn-takingSender handover, receiver turn requests and turn recoveryState-machine tests; bidirectional Watterson channel simulation
DisconnectHost-requested close, remote close and abort; stale-session controls rejectedState-machine and host-interface tests
Host interfaceSingle framed-CBOR connection per station; bidirectional payload transferPaired servers over simulated channels
Data profiles and object transferOFDM and narrow FSK profiles; connectionless object framing and integrity checksError-free and Watterson channel simulations

The station provides a sabir audio lane and host interface for two-way sessions. The named RF result remains beacon reception; two-way on-air delivery is not established here. Carrier groups masked during a session remain masked; re-probing is unfinished.

Mode guide · ARQ implementation · Host interface

Robust Packet (brubru)

Brubru provides Robust Packet transmit/receive, AX.25 framing and a station KISS host on a local TCP port. Tracker and AGWPE hosts add connected AX.25 sessions, acknowledgements and retries. Pat mail exchange is exercised over virtual audio; Windows Express component checks cover binary RPR contacts. These are software checks, not an on-air Robust Packet mail result.

The tests decode four published corpus frames from three stations with valid FCS. These are corpus results, not observed results from this station. Regeneration agrees on 1327/1328 differentials for RPR_Frame with limiting enabled, and 1328/1328 for Robust-packet.mp3 and the first radioscanner frame without it. The second radioscanner frame is pinned for its payload, FCS and 1808 differentials; no regeneration agreement is claimed for it. Containers and level 1 are covered by synthetic tests, without an independent station result.

Waveform and evidence · Framing · Station attachment

bateleur

MIL-STD-188-110 serial, 39-tone and 16-tone, 110C appendix D (3 kHz), STANAG 4285, 4529 and 4539, the STANAG 5066 link layer, 2G ALE and HF selcall run through station lanes and host ports. The console adds automatic ALE scanning/sounding, manual calls and native AMD/DTM/DBM text, plus held-channel selcall calls and pages. These console workflows have software and station integration tests; their two-way external radio interoperability remains to be tested. The evidence column distinguishes local simulations from published recordings and earlier external decodes.

ComponentDemonstrated behaviorEvidence
188-110 serial, 75–4800 bit/sShort, long and zero interleave; rate and interleave read from the preamble; message recovered to its EOMLoopback and Watterson channel simulations
188-110 Table XXShort simulations: eleven rows, zero errors in 128–4,800 bits per row; conditional independent-bit 95% upper bounds 0.0231–0.000624One trial and one second of requested payload per condition, seed 0; conditions and counts
STANAG 4285, 75–3600 bit/sCoded and uncoded streams, including SOM-less reception; Annex E framing remains foreign-unverified. Short simulations: 21 rows, zero errors in 600–2,400 bits per row; conditional independent-bit 95% upper bounds 0.00498–0.00125Recorded short annex-b run; conditions and counts
STANAG 4539, 3200–12800 bit/sLocal round trips at every rate and interleaver. Short simulations: fifteen rows, zero errors in 3,200–12,800 bits per row; conditional independent-bit 95% upper bounds 0.000936–0.000234Recorded short c-xvii, c6-3, c6-4 runs; conditions and counts
188-110 39-tone, 75–2400 bit/sShort simulation at 1200L, 15 dB, two equal paths 2 ms apart with 2 Hz spread, +23 Hz offset: 2/1,200 bit errors; conditional independent-bit 95% upper bound 0.00524. Six other short rows have zero errorsRecorded short b-xii run; conditions, counts and clock-test limitation
188-110 16-tone DPSK mode (appendix A), 75–2400 bit/sLocal round trips, offset and clock tests, and station lane integration. No performance table is recorded for this waveformLoopback and channel tests; limits
188-110C appendix D, 3 kHz (waveforms 0-13), 75–16000 bit/sEvery waveform and interleaver recovered, the waveform read off the preamble; table D-LII met at 23 of 26 points (8 transmissions, 15 kbit–3.2 Mbit a point), the three misses each about 1 dB (600 bit/s poor, 4800 poor, 12000 white noise); D.6.2's static channels, D.6.4's ±75 Hz and D.6.5's sweep decoded; on the station and its host port (MODE WBHF)Loopback, channel simulations, station tests on replayed audio
188-110A "mod" (receive only)Worked out from seven off-air recordings, with no description to go on: tone header, parallel section, and a 188-110A data phase with a 640-symbol sync phase; every burst in them found, its data phase followed to the channel bits, both formats (bits once, or twice with an end marker) told apart; the bits' coding not found (not 110's, not an uninterleaved K<=7 rate-1/2 code), so they are output rawOff-air recordings, synthesized bursts in the test suite
STANAG 4529, 75–1800 bit/sEvery coded rate and both interleavers, uncoded 600–1800, any sub-carrier 800–2400 Hz; the conformance test procedures' sync pattern, flush counts and 99% power in 1240 Hz met; 75 bit/s at 3 dB 30 Hz off and 150 bit/s on CCIR poor at 12 dB decoded whole; on the station and its host port (MODE 4529 <mode>)Loopback, channel simulations, station tests on replayed audio; written from the JITC conformance test procedures, not the STANAG's text
Binary FSK (STANAG 4481 annex C, 110B 5.1), 50–1200 Bd850 and 170 Hz shifts and the 16 multi-channel sub-carriers, with diversity; no character errors on white noise to 6 dB with 25 Hz off; 2–11% character errors uncoded on CCIR poor at 10 dB, under 1% with diversity at 6 dB; on the station and its host port (MODE FSK <mode>), keyed only inside the declared spanLoopback, channel simulations, station tests on replayed audio; no broadcast recording
STANAG 5066 ed. 1.2, annexes A-CD_PDUs against the annex's worked CRC example; selective-repeat ARQ through bit errors to 2e-3; expedited and non-ARQ delivery, groups, errored delivery; soft and hard links, crossing requests, full reset, data rate change; nodes on the modem through rendered audio and a channel, and on the station with clients on TCP 5066Nodes against each other in simulated channels (bytes and audio), station tests on replayed audio with a fake rig; no other implementation
2G ALECalls, scanning, AMD, directory lookup, DTM/DBM and linking-protected reception and transmission; the operator enables scanning and supplies its channelsLocal coding and channel tests. Earlier LinuxALE decode reported without retained WAV, command or output; DTM CRC and protected wire details remain open. Evidence
HF selcall (CCIR 493-4 4-digit, UN open 6-digit)Local coding and channel tests; three published recordings decode; a station lane and host dialect; no call-success table is recordedTests and published recordings; limits
Occupied bandwidthDeclared rows 350–2995 Hz trimmed and 350–3140 Hz untrimmed, including parallel modes; 39-tone short bursts filteredWelch PSD at 30 Hz equivalent noise bandwidth, −26 dB, short and 30-second payloads in tests/bateleur/test_phy.py
Station modemReplayed 188-110 audio reaches an attached application through the station; a message sent from the host port keys through the arbiter and decodes back; messages longer than max_key_s split into whole transmissionsStation tests on replayed audio with a fake rig

Waveform description · Receiver · Host interface · STANAG 5066 · FSK · STANAG 4529 · Appendix D · 188-110A mod

Lanner: RTTY, SITOR-B and NAVTEX

Lanner supplies ITA2 RTTY and collective SITOR-B waveform encoding and receive decoding, plus NAVTEX bulletin extraction. The console provides separate passive rtty, sitor-b and navtex monitors. They support automatic tone-pair acquisition through a receive audio passband up to 4 kHz.

The tests cover code tables, local audio round trips, offset/noise and time-diversity behavior, chunked reception and bulletin parsing. Those tests establish software behavior; no named independent on-air Lanner decode is claimed here. SITOR-A ARQ and a two-way Lanner console terminal are not provided by these monitor commands.

Implementation and limits · Passive monitoring

Voice and CW

Macagua provides speech recognition and synthesized voice. Merlin provides CW encoding and decoding. Both use a supervised contact terminal with reply drafts, caller confirmation and operator approval of each transmitted over. Computer-only tests and recording playback are available through hfmodem console voice. Both modes remain experimental.

Operator guide

Source records

RF transfer results come from station logs and operator receipt confirmations. The delivery references are message 9WQNVWBDLVOY for PACTOR-3 through WS8EOC and message NL03TXWQ8SGL for VARA through KB8AY, plus message 2KX2HWM919HR for ARDOP through WW2MI. Named reference decoders and remote receivers provide the independent observations identified above. Simulation results use two instances of hfmodem.

Release qualification

Python 3.13 is the supported minimum. Qualification requires macOS and Linux software passes for the same candidate. Physical station validation is optional and is recorded separately; no radio, serial adapter or oscilloscope is needed for software release qualification. A software pass establishes no physical PTT, pulse, termination or on-air result. Use publish/qualify.py from macOS; it runs Linux in hfmodem-ci. Optional attended evidence supplied with --hardware-receipt must pass its validation; omitting it records station validation as not_requested. Verify the successful receipt with --verify before preparing a release tag. Changed release files require fresh qualification. See publish/README.md for commands and evidence requirements.

GitHub Actions runs the filtered package regression suite on Ubuntu 24.04 with Python 3.13, then checks the built distributions. It excludes slow, realtime, wall_clock, corpus, hardware and ardopcf cases. Ordinary package tests run with xdist; coexist tests run separately and serially at nice 19 so their process and file observations do not race other test workers. The 26 wall_clock cases still run serially at nice 0 during local release qualification. GitHub installs strace and lsof for Linux observer tests and caps all six numerical thread pools at one.

GitHub does not provision the tty0tty kernel module or claim modem-line validation. By default, coexist line-fixture cases are marked not requested without probing for the pair, even if it is installed. Linux release qualification in hfmodem-ci uses the validated software pair for strict line proof when invoked with publish/qualify.py --line-proof; in that mode a missing or invalid pair fails validation. Neither CI nor software qualification is physical station validation.