Open Winlink for IARU Region 1
A coordinated channel today, an open modem tomorrow.
Winlink and DWS are not toys when used in the right context. They are practical tools for passing structured messages when normal infrastructure is unavailable, overloaded, damaged or simply not trusted enough for the task at hand.
The proposal published at https://github.com/Guru-RF/winlink-rfc-iaru-r1 is an attempt to bring more structure to that reality in IARU Region 1.
It proposes a coordinated 2 metre data channel for Winlink and DWS traffic, with a special focus on unmanned RMS gateways, digipeaters, field stations and emergency-communication use.
This is not about creating yet another digital island. It is about recognising what is already happening in the field, giving it a clean coordination framework, and preparing the ground for a more open technical future.
Use a predictable and coordinated VHF channel for DWS and Winlink traffic today, while working toward an open-source modem stack that can eventually stand beside VARA FM, or even supersede it.
Why this proposal exists
The immediate background is simple. DWS, the Dutch Winlink System, is already used by operators and emergency-communication groups in the Netherlands and Belgium. It provides a practical Winlink-based message-handling environment, often using VARA FM on ordinary VHF and UHF FM transceivers.
DARES in the Netherlands, B-EARS in Belgium, and the wider DWS community have already shown that cross-border radio email exercises are not theoretical. They happen. Stations train together. Messages are passed. RMS gateways and digipeaters are used.
The operational reality is therefore already wider than a single national band plan.
That is why a purely Belgian or purely Dutch approach is not enough. Emergency communication does not stop at a border, and a usable radio email network should not depend on local guessing, informal channel use, or incompatible national assumptions.
The RFC at https://github.com/Guru-RF/winlink-rfc-iaru-r1 is therefore not a final decree. It is a request for comments. It invites national societies, emergency-communication groups, VHF/UHF managers, unmanned-station coordinators, developers and users to discuss a practical Region 1 approach.
- Channel: 144.850 MHz
- Use: Winlink / DWS radio email traffic
- Stations: RMS gateways, digipeaters and field stations
- Initial modem: VARA FM Narrow
- Scope: IARU Region 1 coordination discussion
- Repository: https://github.com/Guru-RF/winlink-rfc-iaru-r1
Credit where it belongs: DARES, B-EARS and DWS
This proposal did not appear out of nowhere.
The Dutch DWS community has done a lot of the practical work needed to make Winlink usable for emergency communication. DWS is not just a modem choice. It is a practical operating environment, with procedures, software, exercises, station concepts and real operators behind it.
DARES deserves clear credit for the operational emergency-communication context in the Netherlands. B-EARS deserves the same credit in Belgium. Both groups understand that resilient communication is not improvised during the incident. It needs practice, procedures, stations, discipline and people who know what they are doing before the emergency starts.
The RFC is therefore not an attempt to replace that work. It is an attempt to support it with a clearer frequency-coordination proposal and a long-term technical roadmap.
If DWS, DARES and B-EARS have already created a practical cross-border operating culture, then the next logical step is to make the RF layer more predictable as well.
Why 144.850 MHz?
The proposed channel is 144.850 MHz.
The reason is not that this frequency is magic. The reason is that a DWS and Winlink network needs a predictable meeting place that is not the APRS channel and not randomly mixed with unrelated local digital use.
In many parts of Europe, APRS already has its established channel on 144.800 MHz. It is used for position reporting, telemetry, messages, weather data, objects and other short packet-style transmissions. It works because most transmissions are short and because everybody knows where to listen.
Winlink and DWS traffic behave differently. A radio email transfer can occupy the channel for the duration of the connection. With VARA FM this can be efficient, but it is still a connected data session, not a short APRS beacon.
APRS should remain APRS. DWS and Winlink traffic should use a separate coordinated data channel, so both systems can work without stepping on each other.
Putting longer Winlink sessions on the APRS channel is bad engineering and bad neighbour behaviour. A separate DWS/Winlink channel is cleaner, easier to coordinate and easier to explain.
This is still normal FM
A common misunderstanding is that VARA FM creates some completely new type of RF emission. In practice, VARA FM produces audio tones that are fed into a normal FM transceiver.
The RF signal remains a narrow-band FM signal, using familiar VHF and UHF radio hardware.
That matters for coordination. The proposal is not asking for a new exotic band segment. It is asking for a predictable channel inside the existing digital and MGM use of the 2 metre band, where radio email stations can find each other without disturbing APRS.
| Wrong assumption | Better interpretation |
|---|---|
| “VARA FM is a completely different RF mode.” | No. VARA FM generates audio that is transmitted through a normal FM transceiver. |
| “DWS can just use APRS frequency space.” | No. DWS/Winlink traffic has a different traffic profile and should not overload APRS. |
| “Each country can solve this alone.” | Not really. VHF coverage crosses borders, especially in Belgium and the Netherlands. |
| “A gateway frequency is just a local detail.” | No. For emergency communication, predictability is part of the system. |
Unmanned stations need visible coordination
RMS gateways and digipeaters are not casual personal stations. They are unmanned transmitters and must be treated as such.
That means national rules still matter. Registration, authorisation, responsible operators, power levels, antenna data, transmitter quality, identification, logging and interference handling all remain important.
The RFC does not try to bypass national coordination. It asks national societies and coordinators to recognise this use case and create a simple, visible and consistent way to support it.
A practical DWS/Winlink channel only works if station keepers, emergency groups and coordinators all understand what is being built and why.
Why Pat matters
Winlink has historically been strongly associated with Windows-based tooling. That works, but it is not always ideal in the field.
For portable, embedded and low-power deployments, Linux and Raspberry Pi class systems are often more attractive. They are small, cheap, easy to power, easy to automate and easier to deploy in unattended or semi-attended setups.
This is where Pat becomes important.
Pat is an open-source Winlink client. It runs on Linux, macOS and Windows, and it can be used through a web interface or command-line workflow. In practical terms, it allows a Winlink station to move away from the assumption that every field station must be a Windows laptop.
That is a big step toward openness.
But it is not the whole story.
But if the modem underneath is still closed, the complete stack is not yet open.
The modem problem
Even when using Pat, the modem layer is often still proprietary. Today, VARA FM is the practical choice because it works very well. It is fast, robust and already used by many DWS operators.
That should be acknowledged honestly. VARA FM is not the enemy. It is the current benchmark.
But from an emergency-communication point of view, there is a strategic weakness: the modem is closed source.
That creates several problems:
- the community cannot fully audit how the modem works;
- development depends on one closed implementation;
- licensing can become a practical deployment issue;
- native integration on embedded and non-Windows platforms remains harder than it should be;
- the long-term resilience of the network depends on software the community does not control.
This does not mean that VARA FM is bad. Quite the opposite. It sets a high practical benchmark. But for a resilient amateur-radio emergency network, the long-term goal should be an open modem stack.
Why we started with MercuryFM
This is why we started working with MercuryFM.
The project is published here:
https://github.com/Guru-RF/MercuryFM
MercuryFM is an open-source modem project for VHF and UHF FM voice channels. It builds on the existing Rhizomatica Mercury modem framework, but focuses on an FM-optimised physical layer suitable for amateur VHF and UHF use.
The reason for starting there is pragmatic. Mercury already contains useful modem infrastructure: ARQ concepts, audio handling, radio and PTT control, framing ideas and a TCP TNC-style interface model.
What was missing for our use case was a waveform designed for the flatter, higher-SNR path of a normal FM transceiver channel.
MercuryFM is therefore not an attempt to clone VARA. It is an attempt to build an open modem that can serve the same operational need.
The goal is to create an open modem that can eventually be good enough to replace the dependency on closed modem software.
The real goal: on par with VARA, or better
The long-term goal is ambitious but necessary: an open-source FM data modem that is on par with VARA FM, and eventually good enough to supersede it.
That does not happen overnight. VARA FM is mature, widely used and technically strong. An open replacement must earn its place by being reliable, efficient, easy to deploy and compatible with real emergency-communication workflows.
But the direction is clear.
| Layer | Today | Long-term goal |
|---|---|---|
| Client | Winlink Express, Pat | Keep supporting practical clients, with strong open-source options. |
| Modem | VARA FM Narrow | Open-source modem on par with VARA FM, or better. |
| Channel | Locally coordinated or informally used | Regionally coordinated DWS / Winlink channel. |
| Network | National and cross-border exercises | Predictable IARU Region 1 emergency-data capability. |
The important point is that the frequency proposal and the modem roadmap are separate but compatible.
We can coordinate 144.850 MHz now, using VARA FM Narrow because it works today. At the same time, we can develop MercuryFM and other open modem work so the community has a path away from closed dependencies later.
Deploy what works now, build what we need next
There is no contradiction in using VARA FM today while working toward an open modem tomorrow.
Emergency communication systems must work with available tools. A network that only exists on a whiteboard is useless. VARA FM gives DWS operators a practical working modem now, and Pat gives operators a more open and portable client option.
But if amateur radio wants a truly resilient digital emergency-communication stack, the modem layer must also become open.
That is the reason for MercuryFM.
- use a coordinated 144.850 MHz channel for DWS and Winlink traffic;
- keep APRS protected on 144.800 MHz;
- use VARA FM Narrow where it is the practical working solution today;
- support Pat and other open client tooling;
- develop MercuryFM into a serious open-source FM data modem;
- move toward an open modem stack that can eventually match or exceed VARA FM.
Why IARU Region 1 coordination matters
A DWS or Winlink station in Belgium can hear the Netherlands. A Dutch station can support Belgian exercises. Border regions do not care about administrative lines on a map.
That is why IARU Region 1 coordination matters.
Without it, every country risks making a slightly different choice. The result would be fragmented channels, confused field operators and unnecessary interference between systems that should have been cooperating.
A single proposed channel does not solve every problem, but it creates a predictable starting point.
The RFC at https://github.com/Guru-RF/winlink-rfc-iaru-r1 should therefore be read as an invitation: comment, improve, adapt, challenge and help turn the current practice into a more robust Region 1 framework.
The real conclusion
The amateur-radio emergency-communication community already has many of the pieces.
DARES and B-EARS bring operational experience. DWS brings practical Winlink deployment. VARA FM brings a modem that works today. Pat brings an open and portable client. MercuryFM points toward an open modem future.
The missing part is coordination.
A harmonised DWS and Winlink channel at 144.850 MHz would give field stations, RMS gateways and digipeaters a predictable meeting point, while keeping APRS clean on 144.800 MHz.
At the same time, continued work on MercuryFM can help remove the long-term dependency on closed modem software.
That is the bigger goal: not just another channel, not just another modem, but a resilient and open radio email ecosystem for IARU Region 1.
Coordinate what already works today, and build the open tools we need for tomorrow.
Mini-FAQ
- Is this a proposal to replace APRS? No. The opposite. APRS should remain on 144.800 MHz. DWS and Winlink traffic should use a separate coordinated channel so both systems can work properly.
- Why 144.850 MHz? It provides a predictable coordination point for DWS and Winlink traffic without loading the APRS channel.
- Is VARA FM being rejected? No. VARA FM works well and is the practical modem choice today. The concern is long-term dependency on a closed-source modem for emergency communication.
- Why mention Pat? Pat is an open-source Winlink client that helps make portable, embedded and Linux-based Winlink stations practical.
- Is MercuryFM already a VARA FM replacement? No. MercuryFM is a development path toward an open-source FM data modem. The goal is to become good enough to match or eventually supersede VARA FM.
- Why involve IARU Region 1? Because VHF coverage and emergency communication cross national borders. A coordinated Region 1 approach avoids fragmented national solutions.
Interested in more technical content? Subscribe to our updates for deep-dive RF articles and lab notes.
Questions or experiences to share? Feel free to contact RF.Guru for practical RF and antenna support.