XLX is one of the most common reflector systems in amateur digital voice — and one of the most misunderstood, partly because its name promises more than the words let on. This is a plain-language explanation of what an XLX reflector actually is, what "multi-protocol" really means, and what it takes to make different digital modes talk to each other.
An XLX reflector is a server that acts as a central meeting point for digital voice radio. Hotspots and repeaters connect to it over the internet, and once connected, their users can all talk to one another regardless of where they are. XLX grew out of the D-Star world — the software (xlxd) was originally written for D-Star — but it has grown well beyond that, which is exactly why its name can be a little misleading.
A single XLX reflector is divided into modules, labeled by letter from A to Z. A useful way to picture it: the reflector is a hotel, and the modules are 26 rooms. Each module is an independent talk room — everyone connected to Module C hears each other, and that conversation is completely separate from Module D. A reflector can run up to all 26 modules at once; the operator decides how many to enable and what each one is for. There's no universal standard for what each module does, so it's worth checking a reflector's dashboard to see how its modules are labeled.
This is where the name earns itself, and where the confusion starts. XLX is genuinely multi-protocol: a single module can accept connections from three different digital voice systems at the same time —
So out of the box, with no extra hardware, a D-Star user, a DMR user, and a Fusion user can all connect to the same module. That's the "gateway" doing its job. But connecting to a module and being able to talk to everyone on it are two different things — and the name doesn't tell you that.
Whether two connected users can actually hear each other comes down to the codec — the digital "language" their radios use to encode voice.
So without anything extra, a "multi-protocol" module gives you DMR ↔ Fusion audio, with D-Star connected but walled off.
To make D-Star actually talk to the other two, you add transcoding. This requires a separate piece of software (AMBEd) and hardware AMBE vocoder dongles — small USB devices containing the chips that translate AMBE ⇄ AMBE+2 in real time. With a vocoder serving a module, all three modes finally hear each other: D-Star ↔ DMR ↔ Fusion, full audio in every direction.
The channel math
Transcoding capacity is set by your vocoder channels, not by the number of modules. Each active transcoded transmission uses two channels — one to decode the incoming codec, one to re-encode it to the other side. A common dongle, the DVstick33, provides three channels each. So two of them (six channels) can transcode three transmissions at the same time.
You can also enable transcoding on more modules than you have hardware for — if too many transmit at once, the extras simply don't get transcoded.
In principle, yes — enabling transcoding on a module is just a configuration choice. But the hardware is the real limit. Guaranteeing all 26 modules could transcode at the same instant would take 52 vocoder channels — about 18 DVstick33 dongles, and at roughly $250 apiece, around $4,500 in vocoder hardware alone. In practice nobody does this, because you'll never have 26 cross-mode conversations happening simultaneously. Operators instead enable transcoding broadly but install just a few dongles, sized for the handful of simultaneous transmissions that actually occur.
Some reflectors advertise themselves as "fully transcoded." On the surface that means every module can bridge D-Star to the AMBE+2 modes — so wherever you connect and whatever mode you're on, you'll be heard by everyone else on that module.
But it's worth understanding what that claim costs. Enabling transcoding on a module is free and takes seconds. Actually delivering it requires hardware vocoders, and each simultaneous transcoded transmission consumes two channels. Because an operator can enable transcoding on more modules than the hardware can serve at the same instant, "fully transcoded" is usually a statement of intent backed by a sensible amount of hardware — enough for the conversations that realistically happen at once. When a reflector genuinely runs fully transcoded across many modules, it represents a real investment of money and upkeep by someone providing the service free of charge.
Is software transcoding an option?
Not on XLX. Software vocoders exist for AMBE+2 (the DMR / Fusion codec), but AMBE+2 was never the problem — DMR and Fusion already speak it to each other. The one codec you actually need to bridge on XLX is D-Star's, and there is no usable software substitute for it. So hardware AMBE vocoders are mandatory. (Software-based vocoding only became possible on the newer urfd platform, and even there D-Star still needs hardware.)
XLX reflectors can also link to one another. Module C on one reflector can be peered with Module C on another, extending a single talk room across multiple servers. When reflectors are interlinked, each one needs its own vocoders to stay fully multi-mode on the shared module.
XLX is multi-protocol at the connection layer right out of the box — D-Star, DMR, and Fusion can all link in. Full cross-mode audio, specifically anything involving D-Star, is what the hardware transcoder unlocks. DMR and Fusion were already speaking the same language; the vocoder is what brings D-Star into the conversation.
XLX wasn't a single static project; it's been developed and improved by several people over the years.
The original (2016). xlxd was written by Jean-Luc Deltombe (LX3JL) and Luc Engelmann (LX1IQ), published under the GPL as part of the software system for the D-Star network. Their repository is the foundation everything else is built on, and they ran it — along with the supporting network infrastructure — free of charge for the ham community.
The improved fork (2018–2020). Thomas A. Early (N7TAE) took the original and developed an improved version, new-xlxd, while preserving the original authors' copyright. It added refinements like being able to specify exactly which modules get transcoder support, optional flags to disable G3 (Icom Terminal / Access Point) support, and a built-in YSF frequency database so Wires-X-linked hotspots can reach any module.
The successor: urfd. N7TAE later took the concept further and wrote urfd, described as a Universal Reflector with M17 — a superset of XLX. Where XLX handles D-Star, DMR, and Fusion, urfd adds M17, NXDN, P25, and USRP (AllStar) support, and uses a separate hybrid transcoder, tcd, in place of AMBEd. One note: you can't interlink urfd with xlxd — they're separate generations.
A noncommercial hobby reference compiled by N6JET, gathered from public sources and shared freely for anyone interested in amateur digital voice.