Open Winlink for IARU Region 1: Coordinate, Then Build Open

I published the Winlink/DWS RFC for IARU Region 1 because the people doing cross-border message exercises deserve a predictable RF framework. DARES, B-EARS and the DWS community have already put serious work into procedures, software and operating practice. My proposal is meant to support that work—not replace it. In parallel, we started MercuryFM to work toward an open modem the community can understand, improve and maintain.

Winlink and the Dutch Winlink System, DWS, are practical tools for passing structured messages. Their value is not another digital badge on the shack computer: it is being able to move useful information when the normal route is unavailable, and knowing how to do that before an incident starts. A coordinated channel and an open modem address different parts of that problem. We should pursue both without pretending either one already solves everything.

Why This Proposal Exists

Belgium and the Netherlands do not meet at an RF wall. A useful station near the border may serve operators on either side, while two uncoordinated stations can interfere across exactly the same border. If everyone builds a slightly different local answer, the operators who are supposed to cooperate inherit the confusion.

That is why I want a Region 1 discussion rather than another isolated national arrangement. The RFC is an invitation to national societies, emergency-communication groups, VHF/UHF managers, station coordinators, developers and users. Its current draft focuses on permanent, registered and coordinated fixed Winlink gateways and digipeaters; it is not a blanket authorisation for temporary field transmitters or incident deployments. Field operators benefit from a gateway they can find, but their own operating conditions still apply.

Credit Where It Belongs: DARES, B-EARS and DWS

This proposal did not appear out of nowhere. DWS is an independent software and operating community, not an RF.Guru project. DARES credits participating radio amateurs with developing the DWS software. The wider work includes message handling, training, station preparation and people who practise together—not just a modem selection.

DARES brings the Dutch emergency-communication context. B-EARS brings that work to the Belgian amateur-radio community through UBA. Their own international outlook recognises the value of learning and exercising with neighbouring countries. DARES Limburg's exercise reports provide concrete examples of Winlink practice and contact with B-EARS across the border.

I am giving those people credit for their work, not claiming that any of these organisations has endorsed this RFC or MercuryFM. The point is to build on their practical experience. If we value that experience, the next step is to make the RF arrangements easier to understand and coordinate as well.

A Meeting Place for Winlink, Without Crowding APRS

The RFC proposes 144.850 MHz as a coordination point. There is nothing magical about that frequency. The useful idea is that a Winlink/DWS operator should know where to find a gateway, and that connected radio-email sessions should not be pushed onto the established APRS channel at 144.800 MHz.

APRS carries position reports, telemetry and messages, often in short packets. A Winlink connection can keep the channel busy while it transfers a message and exchanges acknowledgements. Those traffic patterns are different. Keeping the services on separate, coordinated channels is sensible neighbour behaviour; it gives both a clearer operating environment.

Law, Band Planning and Network Rules Have Different Jobs

A frequency proposal crosses four different layers. Treating them as one source of permission is where otherwise sensible projects get into trouble.

The IARU handbook itself says that no right to a reserved frequency follows from a usage-table entry. Conversely, national permission to use the 144–146 MHz amateur allocation does not make every frequency choice compatible with the voluntary band plan.

What the Current Region 1 Plan Actually Says

The current IARU Region 1 VHF Handbook, version 10.03, places 144.794–144.9625 MHz in a digital-communications segment with a stated 12 kHz maximum bandwidth. Within that table it identifies:

• 144.800 MHz for APRS;
• 144.8125, 144.8250, 144.8375, 144.8500 and 144.8625 MHz for digital-voice internet gateways; and
• the wider segment for MGM digital communications, subject to the plan’s notes and national usage.

The frequency therefore sits in a digital segment with an existing planned use. I am asking Region 1 societies and the VHF/UHF/Microwaves Committee to consider a coordinated solution: compatible sharing where justified, an agreed change, or another channel. This is precisely why an RFC is useful. It puts the proposed need and the existing neighbours in the same discussion.

Belgium and the Netherlands Are Not the Same Case

Belgium’s current BIPT amateur frequency table permits the 144–146 MHz band and all emission classes within the limits of the operator class. That does not settle the gateway question. BIPT’s current station-authorisation FAQ excludes operator-less fixed retransmitting or continuously transmitting stations from the application it describes, except APRS. It should not be read as an automatic authorisation for an RMS gateway.

An RMS gateway, store-and-forward node or digipeater must therefore be classified with BIPT before deployment. Its exact trigger, supervision and traffic path matter, but calling it “emergency communication” does not create an exception. BIPT also limits ordinary amateur traffic to technical research and related subjects in plain language; exercises organised by Belgian emergency services require prior approval, while crisis assistance and coded traffic are allowed only in the stated authorised circumstances. See BIPT’s current communication guidance.

In the Netherlands, a normal amateur registration is not automatically a relay permit. The Rijksinspectie Digitale Infrastructuur says a permit is required for relay and beacon stations, and it publishes the issued stations. The applicable Dutch amateur operating conditions and any station-specific permit must also be checked for control, identification and message handling. A cross-border network therefore needs a country-by-country station matrix, not one Region 1 slogan.

VARA FM Is Data Through an FM Radio—Not Simply “Normal Voice FM”

VARA FM uses a software modem and an FM transceiver, so no exotic RF hardware is implied. The transmitted emission is nevertheless frequency-modulated digital data, and its occupied bandwidth depends on the modem mode, audio interface, deviation, filtering and radio alignment. A channel label alone cannot prove compliance.

The official Winlink VARA FM setup guide distinguishes narrow and wide operation: the radio interface commonly labelled “1200 baud” is limited to the narrow mode, while the wider “9600 baud” interface can support either. Those port labels describe the radio audio-path options; they are not a promise of the Winlink payload rate. For a Region 1 channel with a 12 kHz maximum-bandwidth entry, the RFC should specify the permitted VARA mode, deviation, measured occupied bandwidth, adjacent-channel mask and radio setup—not merely the word “Narrow.”

The 50 kHz separation from APRS at 144.800 MHz is helpful, but it is not a compatibility certificate. High-site gateways, imperfect receiver selectivity, over-deviation and local co-location can still matter. A responsible proposal needs on-air or laboratory coexistence measurements against APRS and the digital-voice gateway channels already named in the plan.

RMS Operation Adds Network Rules

Winlink’s own RMS sysop guidance requires network authorisation, an actively responsible licensee, proper gateway reporting, current software and mandatory busy-channel blocking/transmit inhibit. It also makes the sysop responsible for lawful operation.

Those controls belong in the RFC’s minimum station profile:

• listen-before-transmit and reliable busy-channel inhibit;
• an identified, reachable responsible operator;
• documented power, antenna, occupied bandwidth and deviation;
• remote shutdown that is legal and fails safe;
• session-time and congestion limits;
• logs sufficient to investigate interference without creating unjustified privacy claims; and
• separate approval for any national emergency-service exercise that requires it.

Why Pat Matters—and Why the Modem Still Matters

Pat is an open-source, cross-platform Winlink client. Its official repository describes command-line and web interfaces and says it is mainly developed for Linux, while also known to run on macOS, Windows and Android. That is useful for field computers and small systems: a Winlink client need not mean a Windows laptop. An open client also lets people inspect, adapt and maintain that part of the station.

Client openness and modem openness are separate, however. A Pat installation that uses a proprietary modem retains that dependency. For a small Linux or Raspberry Pi station, the complete combination still needs a supported modem, working audio and PTT, reliable recovery after power loss and the necessary control arrangements. Pat is an important part of the open-station argument, not a claim that every possible stack is already portable.

VARA FM Is the Benchmark, Not the Enemy

The DWS operators using VARA FM have a practical reason for doing so: it is part of their working message-transfer setup. I am not asking them to abandon that work for a modem that exists only on a development roadmap. A usable network today matters more than winning an argument about software purity.

My concern is the long-term dependency on a closed modem implementation. The community cannot inspect and maintain all of its internals; deployment must follow its licence terms, and integration on a chosen embedded platform depends on what that implementation supports. Those are maintainability and autonomy questions, not evidence that a closed modem performs badly. Open-source modem projects already exist; the particular goal here is an open implementation suited to the FM-channel role we want to fill.

Why We Started MercuryFM

That is why we started MercuryFM at RF.Guru. The project builds on Rhizomatica Mercury, reusing its ARQ data-link framework, TCP modem interface, audio handling, PTT/radio control and framing. ARQ is the acknowledgement-and-retry machinery that lets a data link recover missing information. Starting with that infrastructure lets the work concentrate on an FM-oriented physical layer.

The design question is how to use an FM radio's audio channel efficiently while coping with the real radio's filtering, levels and weak-signal behaviour. An HF waveform designed around fading and multipath need not be the best use of that different channel. That is a reason to investigate an FM-tuned waveform—not a claim that every FM link is flat, high-SNR or immune to distortion.

We are not trying to clone VARA FM. We want an open alternative that can eventually serve the same practical need, without making the community dependent on one closed implementation. Rhizomatica's work deserves credit for the foundation; MercuryFM is an independent derivative, not an endorsement by the upstream project.

The public repository documents successful builds and a first FM waveform, with on-air calibration still pending. That supports describing a real development project. It does not establish field reliability, delivered throughput or parity with VARA FM. Matching or surpassing the practical benchmark remains the ambition, not a result I can announce here.

An Open Modem Must Earn Its Place

Openness is valuable because it gives us a way to inspect, repair and continue the work. It does not, by itself, make a waveform faster or a station more reliable. MercuryFM should earn its place with reproducible comparisons of:

Coordinate the Channel and Develop the Modem in Parallel

1. State the conflict clearly. 144.850 MHz currently has an IARU digital-voice gateway usage designation.
2. Ask before assigning. Circulate the RFC to national societies, VHF/UHF managers, digital-voice coordinators and the IARU Region 1 committee.
3. Build a national legal matrix. Establish the route for each proposed permanent fixed gateway or digipeater, including supervision and station authorisation. Keep that RFC scope distinct from the rules for visiting or field users.
4. Define the emission. Specify modem mode, maximum occupied bandwidth, deviation, power, identification and busy-channel behaviour.
5. Measure coexistence. Test APRS and adjacent gateway-channel receivers with realistic wanted and unwanted signal levels.
6. Agree a lawful pilot. Obtain the required regulator and coordination approvals, then publish operator contacts, shutdown arrangements and test results before claiming regional suitability.
7. Keep the open-modem track separate. MercuryFM can mature without making the channel proposal depend on unverified performance.

Support the Network That Exists, Build the Tools It Needs Next

DARES, B-EARS and the DWS community supply the operating experience this proposal is meant to support. VARA FM gives operators a working option; Pat opens the client side; MercuryFM is our contribution toward an open FM modem. These are complementary roles. None should have to disappear so that another project can claim the whole story.

My conclusion is affirmative: a predictable, lawfully coordinated radio-email framework is worth building, and so is an open modem the community can maintain. The present 144.850 MHz conflict has to be resolved, not ignored. But it is a coordination problem to work through with the existing users, not a reason to abandon cross-border cooperation.

We can support suitable, authorised stations using available tools while developing the open alternative. A network left on the whiteboard carries no messages. If you operate a gateway, coordinate frequencies, develop modems or train message handlers, bring that experience to the RFC. That is how this becomes more than another channel suggestion.

Questions, antenna-factor records or height trials to share? Contact RF.Guru.