Why RF-Link?
EchoLink and similar systems have linked radio sites over the internet for years. In most cases, though, the traffic passes through someone else's servers. It is hard to see and manage centrally who hears what, which site transmits when, and which device to silence when something goes wrong.
RF-Link is our answer. Audio and management stay entirely on your own servers. Each site (gateway) is paired, configured and monitored from a web panel. The work started with linking two isolated simplex cells; repeaters and digital networks come next.
How it works
Each site has a Raspberry Pi, a USB sound card, an audio/PTT interface and a radio. The gateway software on the Pi detects audio from the radio and sends it to the media relay on the server. The relay forwards it to the other sites in the same talk group, which transmit it on their own radios.
Flow: radio at site A → Pi gateway → media relay (server) → Pi gateway at site B → radio at site B. The control panel manages and monitors this flow but never carries the audio.
The architecture has three planes:
- Control plane: a Laravel web panel and its database. Users, organizations, devices, groups, versioned configuration, commands, telemetry and alarms live here.
- Media plane: a long-running relay written in Go. It checks group authorization, lets only one person talk in a group at a time and forwards the audio. Audio never passes through the panel, a queue or the database.
- Field plane: the Go gateway agent on the Pi. It handles the sound card, sample rate conversion, receive detection (VOX or COS), PTT and the gateway's state machine.
Safety first
Software that keys a transmitter carries real responsibility. In RF-Link every error path states how the transmitter is turned off:
- PTT is always off at boot; a transmission cut by a restart is never resumed.
- If no valid audio arrives for 500 ms during a transmission, PTT is released. A single transmission has an upper limit (60 s in the lab).
- Only one gateway may transmit in an RF area at a time; a gateway is active in one group at a time.
- Every command with a hardware side effect has an ID, an expiry and acknowledgement states. An expired command is never executed.
- "Saved" is not "applied": configuration is versioned. A device rejects an unknown version and keeps its last working configuration.
- A gateway cannot transmit until its installation checks pass. "Send audio to the group" and "key the radio" are separate permissions, so a site can run as a pure listening post.
What the panel offers
- Inventory and pairing: sites, RF areas and endpoints. A new gateway pairs with a single-use code. The device API is protected by Ed25519 signatures.
- Talk groups: whether a site hears a group, sends to it and transmits on its own radio are set separately.
- Live view: who is talking, which site is on the air, and how old every value is. Groups can be listened to live in the browser.
- Recordings and statistics: optional recordings per group (off by default, kept 7 days). Speech detection separates kerchunks and squelch tails. Talk statistics per node.
- Telemetry and alarms: audio level, PTT time, duty cycle, connection state. Alarm rules with hysteresis, maintenance windows, e-mail on critical alarms.
- Organizations and roles: multiple organizations, Admin / Operator / Technician / Observer roles, assigned scope and two-factor authentication.
The panel also includes a Hardware Guide (in Turkish): wiring, level setup, checklists per radio model, and a "what does this do" explanation next to every setting.
Hardware: two ways
The first lab kit is a Baofeng-class handheld, a Raspberry Pi 4 and a ready-made audio/PTT interface (AIOC). Because that interface is hard to get locally, there is a second method built entirely from local parts: any USB sound card plus PTT driven from the Pi's GPIO through an optocoupler. A one-command installer sets up the gateway software, udev rules and services.
In software, the audio path has a DC blocker, a 300–3000 Hz voice filter and a peak limiter. The filter removes CTCSS tones, hum and squelch pops and prevents clipping. Optional PTT beeps tell listeners that a transmission comes from the node, not a local station. VOX thresholds, hang and transmit tail times are set from the panel.
New horizons
DMR bridge (experimental)
A talk group can be bridged to a DMR talkgroup on the BrandMeister network. The bridge runs in its own container with DVSwitch components, connects to the network like a hotspot and converts between analog and digital audio. The hotspot password is never stored in the panel, only on the bridge host. The bridge reports its city, website, frequency and position, taken from the panel, to the network. The first real connection is up. For now DMR conversations are brought into the group, while transmitting from the group to DMR is kept off.
AI assistant (prototype)
A voice assistant that joins a talk group like a radio operator. It is called with a wake word, speaks Turkish and follows amateur radio procedure:
- It addresses the other station by callsign, using the phonetic alphabet. At the end of a contact it identifies with the licensed callsign ("… this is Tango Alfa Three Zulu Golf Romeo, automatic assistant, 73"); in long contacts it identifies again at intervals.
- It takes follow-up questions without the wake word and remembers the context for the whole contact.
- It uses tools for the time and date, the weather and HF propagation (solar flux, K index, band conditions). It does not make up current information it does not have; it says so.
- In long answers it leaves break-in pauses, as radio practice asks. If someone breaks in with "QSK" during a pause, it answers "QSK go ahead, the microphone is yours" and stops; if nobody does, it continues where it left off.
The assistant is tested only in our own internal group, on one simplex frequency. Because the question audio goes to a cloud AI provider, it is not used in groups with outside users.
Regulatory note: Recordings, listening from the browser and the AI assistant can mean storing radio communications and passing them to third parties. These features are off by default and need to be assessed against the applicable regulations (in Turkey: KEGM) before wider use.
Where are we today?
- Control panel, device API, groups, telemetry, alarms: working.
- Media relay and gateway agent: working; verified with simulation and end-to-end tests.
- Field: the first real two-site link worked (October 2026).
- DMR bridge: experimental; connected to BrandMeister.
- AI assistant: prototype; in the internal test group.
Next up:
- Measurements and VOX calibration on real radios.
- An independent hardware watchdog, required before any field deployment.
- The Opus codec for audio; 16 kHz PCM is used today.
- A WireGuard network profile, signed remote updates and a relay admin API.
We do not publish capacity figures we have not measured. There is no "unlimited nodes" claim here.
RF-Link is a self-hosted project built for the amateur radio community. Questions and field experience are welcome.