Vexillum (VEX) Reflector Explained

---

Vexillum, usually shortened to VEX, is a new reflector program for amateur digital voice. One copy of it can host D-Star, DMR, M17, NXDN, P25 and Yaesu System Fusion reflectors at the same time, plus its own analog FM linking mode called VAFM. It first appeared in public in September 2026 and is still in beta. These are research notes on what it is, how it works, what is running today, and how it differs from XLX and URF.

• What it is
• The name
• Modes and default ports
• How close each mode is to the real thing
• DMR on Vexillum
• M17 and D-Star
• YSF, NXDN and P25
• VAFM, the analog FM mode
• Bridges and cross-mode linking
• What is running today
• VEXJET, N6JET's VEX server
• Keep a VEX server in your hotspot's lists
• Running your own
• Pros and cons
• Compared with XLX and URF
• Who built it
• Open questions
• Sources

What it is

A reflector is a server on the internet that hotspots, repeaters and software clients connect to so their users can talk to each other. Most reflector programs serve one mode, or a fixed set of modes with a transcoder in the middle. Vexillum takes a different approach. It is one program that runs many mode instances, and each instance is a complete reflector for one protocol with its own port and settings.

You can run more than one instance of the same mode. The project's own example is a public M17 reflector and a private M17 test reflector side by side, or 16 DMR instances, all from one install. A shared core handles the parts every reflector needs: configuration, logging, a web admin page, user accounts, a callsign allow and block list, metrics, and a read-only public status API.

The important thing to understand early: Vexillum does not transcode. A DMR user and a YSF user on the same server do not hear each other unless the operator runs a separate bridge program between those two instances. That is the opposite of XLX and URF, where cross-mode audio is the main feature.

The name

A vexillum was the square flag carried by a Roman military unit, the banner its soldiers rallied around, and the word is the root of "vexillology", the study of flags. The project shortens it to VEX: its directory is VexDV, its bridge programs are named vex-..., and public servers are named things like VEX000, VEX493 and N6JET's VEX-JET. The author has not said why he chose the name, but a flag that brings people together suits a reflector well.

Modes and default ports

These are the defaults from the project documentation. Every operator can change them, and the docs say the operator's published details always win.

The server also listens on three private ports that should not be opened to the internet: the admin web page on 8080, the public status API on 8081, and metrics on 9090, all bound to 127.0.0.1 by default.

How close each mode is to the real thing

The project's protocol reference is unusually frank about this, and it matters if you plan to point existing equipment at a VEX server.

• DMR, D-Star and M17 follow real external protocols. DMR uses the Homebrew repeater protocol that MMDVM hotspots and BrandMeister use. D-Star uses real DExtra and DSVT frames. M17 uses the M17 project's own reflector packets, including base-40 callsigns and Codec 2 voice frames.
• YSF, NXDN and P25 are simplified, Vexillum-specific protocols. They borrow names and some framing from the real modes but, in the project's words, are not implementations of the official specifications. YSF is the closest of the three because its packet tags follow the MMDVM YSFReflector convention. P25 does no talkgroup parsing at all and simply relays frames.

DMR on Vexillum

A hotspot or repeater logs in to a VEX DMR instance the same way it logs in to a DMR master: repeater ID, a SHA-256 password challenge, then a configuration block. You need the server address, port 62031 and the instance password from the operator.

Inside the instance, traffic is split into 26 modules named A to Z, the same layout as XLX. The default talkgroup scheme is:

Group voice is only passed on timeslot 2 and only on the configured talk group. The docs warn that other servers may change these numbers. One live server, VEX493, uses TG 9 instead of 7.

Talker alias and GPS frames from the hotspot are accepted and stored with that station's session. The docs do not say whether they are relayed to other listeners.

M17 and D-Star

M17 works like an mrefd reflector: 26 modules, no login, Codec 2 voice, one talker per module at a time. Packet-mode data frames are also relayed. A client can connect listen-only, which suits web listeners and monitors.

D-Star uses DExtra on port 30001 with 26 modules. Real D-Star hardware and other DExtra reflectors can connect with standard DSVT frames. There is also a simpler Vexillum-only control format for lightweight software clients.

YSF, NXDN and P25

These three behave like a single-room reflector. Every connected station on the instance shares one room, and only one person can talk at a time. If an operator wants more rooms, they run more instances on more ports.

• YSF: one room per instance, default room designator 12345. Hotspots log in with the usual YSFReflector poll.
• NXDN: one talkgroup per instance, default 61000. A station polling with a different talkgroup is ignored.
• P25: one room. The admin page has a talkgroup field but the docs say it has no effect.

VAFM, the analog FM mode

VAFM is Vexillum's own protocol for linking analog FM. It is what makes VEX more than a digital-only reflector, and it is the part marked beta.

• Audio: Opus, 48 kHz mono, 20 ms frames. Protocol version 1.
• Transports: UDP (best for voice), TCP (for networks that block UDP), TLS and DTLS for encrypted internet links, and WebSocket for browser listen-only clients.
• Hardware: any computer sound device, CM108-style USB radio interfaces, AIOC cables, URI-style interfaces, or custom software. A repeater or link radio needs PTT control and COR or squelch detection.
• Access: optional shared passphrase from the operator.
• Talking: one active talker per room. Press PTT, pause a moment, then speak.

The docs point out that the TLS and DTLS options encrypt the internet path only. Encryption over the air is still not allowed on amateur bands in most countries.

In practice VAFM fills the same role as AllStarLink or EchoLink for a VEX server: a way to put analog repeaters and simple computer clients in the same room. One small inconsistency: most pages give the TCP default as 43000, but the reference overview lists 43000 and 43001.

Bridges and cross-mode linking

Because Vexillum does no transcoding and has no built-in "interlink", every connection to another network or another mode is a small separate program called a bridge. The bridges log in to Vexillum like an ordinary client: as a DMR repeater, a YSF or NXDN hotspot, a DExtra link, or a VAFM client. The operator then marks that session as a bridge on the admin page so it shows correctly on dashboards.

DMR, YSF and NXDN all use the same AMBE+2 voice codec, so these bridges can move the voice bits across without decoding them. The YSF instance acts as the hub: run the DMR to YSF and NXDN to YSF bridges against one YSF instance and all three modes hear each other. Add vex-dmr-bridge to the same DMR instance and outside networks such as BrandMeister or TGIF join the conversation.

What the bridge set does not cover yet: there is no D-Star to DMR, M17 to DMR or P25 bridge, because those need real transcoding between different codecs. The VAFM to DMR bridge is the only one that decodes audio.

It can still be done from outside Vexillum. On VEXJET module A, a DVSwitch converter joins P25 and M17 to DMR: MMDVM_Bridge and Analog_Bridge with the md380-emu software vocoder, G4KLX's P25Gateway for the P25 side and USRP2M17 for M17. All three links connect (tested on VEXJET, 4 Nov 2026); voice has not been tested yet. D-Star is harder, because its older AMBE codec needs a hardware vocoder. VEXJET added it on 5 Nov 2026 with two DVstick 30s on a Beelink mini PC: Analog_Bridge runs next to the sticks, and ircDDBGateway links into VEX's DExtra instance on modules A and B. Two lessons from that build: Analog_Bridge must sit next to the vocoder (over the internet it waits for each voice frame and falls behind), and ircDDBGateway always takes DExtra port 30001 on every address, so it needs its own network if another reflector already uses that port.

What is running today

Operators can choose to publish their server to the VexDV public directory at activity.vexdv.io. Publishing is off by default. This is the directory as read on the evening of 4 Nov 2026, Pacific time:

That is 4 servers online, 23 instances and 91 connected stations. By mode: 71 stations on DMR, 8 on YSF, 3 each on M17, NXDN and VAFM, 2 on P25, and 1 on D-Star. Two days earlier, on 2 Nov, there were 3 servers and 76 stations. The first servers appeared in the directory on 25 Sep 2026. VEX-BEL appears to be run by ON6DP in Belgium, judging by its hostname. A further public dashboard, vex.w0chp.radio, belongs to W0CHP but is not listed in the directory.

Vexillum itself does not include a web dashboard. Each server has a read-only public API, and W0CHP has written a separate dashboard, vex-dashboard, which the ON6DP and W0CHP servers both use.

VEXJET, N6JET's VEX server

N6JET runs Vexillum as VEXJET, at vex.n6jet.com in San Jose, alongside its XLX, URF and M17 reflectors. It went on the air on 3 Nov 2026 and is listed on DVRef and in the VexDV directory.

Its module A is Silicon Valley Multimode via VEX, one room where bridges and a converter join DMR, TGIF talkgroup 95110, YSF, NXDN, P25, M17 and D-Star. It shows what Vexillum can do when an operator adds the missing pieces around it.

More: VEXJET Purpose · How to connect a hotspot · VEXJET live activity

Keep a VEX server in your hotspot's lists

Pi-Star and WPSD download fresh host lists every night. Anything typed straight into those lists is replaced by the next download, so a VEX server that is not in the official lists yet disappears overnight. Both systems have a separate place for your own entries that the nightly update leaves alone. The examples use N6JET's VEXJET; for another VEX server, use its own address, numbers and ports.

Pi-Star

Pi-Star keeps your entries in files in the /root folder. Every night it downloads the new lists, then adds these files back in. There is no web page for them, so they are edited over SSH (Pi-Star's dashboard has an SSH Access page under Expert).

1. Log in to the hotspot over SSH and make the file system writable: rpi-rw
2. Create or open the file for the mode, for example: sudo nano /root/DMR_Hosts.txt
3. Add one line per server, in the format below, and save.
4. Apply it now instead of waiting for the night: sudo /usr/local/sbin/HostFilesUpdate.sh
5. In the dashboard, go to Configuration and pick the new entry for that mode.

The VEXJET lines, one in each file (the gaps are Tab characters). Copy only the part after the mode name:

On DMR, talk on TG 7 and pick a module with TG 64001 to 64026.

D-Star works differently. Pi-Star's nightly update does not handle it at all. Instead, ircDDBGateway, the D-Star gateway program, reads a second DExtra_Hosts.txt from its own home folder, /root, every time it starts, alongside the downloaded list. So put the D-Star line in /root/DExtra_Hosts.txt, then restart the gateway or reboot, and link to XRFVEX A (module A) or any module A to Z. N6JET's own D-Star gateway loads VEXJET exactly this way; it has not yet been tried on a Pi-Star hotspot.

WPSD

WPSD has this built in: Admin, then Advanced, then Hosts File Editors. There is an editor for each kind of list: DMR, XLX, D-Star (CCS, DCS, DExtra and DPlus), YSF, P25, NXDN and APRS. Entries made there are stored apart from the downloaded lists and are not touched by the automatic refresh. Typing into the downloaded lists over SSH does not last; use the editors. WPSD has no M17 editor, as WPSD dropped M17. For D-Star, add VEXJET as a DExtra host: vex.n6jet.com, port 30001.

Pi-Star details are from its own update script and the format notes at the top of its host lists. WPSD details are from the WPSD manual. N6JET is setting up a test hotspot with these entries.

Running your own

From the operator guide, in short:

1. Download the binary for your system from the project's releases page and check its SHA-256 checksum.
2. Copy the example vexillum.toml and edit it. The file only holds the runtime name, logging, database, and the admin, public API and metrics listeners. Mode instances are set up afterwards in the web admin page and stored in a SQLite database.
3. Set a first-start admin password in the environment variable VEX_ADMIN_BOOTSTRAP_PASSWORD, start the program, log in as admin and change the password straight away.
4. Run it as a systemd service under its own user, from /opt/vexillum.
5. Open only the UDP ports for the modes you enable. Keep 8080, 8081 and 9090 private, or put them behind a reverse proxy such as Caddy or Nginx.

Features worth knowing about:

• Accounts and roles: named admin users, roles with a policy editor, and an audit log of every change.
• Callsign allow and block list: works like the XLX and urfd whitelist and blacklist files, with wildcard prefixes such as W0CHP*. It applies to every mode at once and takes effect immediately without a restart, where XLX rereads its files about every 30 seconds.
• Public API: JSON and live Server-Sent Events under /api/public/v1, with built-in Swagger docs, rate limiting and a liveness endpoint for uptime monitors.
• Activity publishing: optional live feed to the VexDV directory and to your own MQTT 5 broker. Joining the directory takes an enrollment: Vexillum files a request with a contact email, you enter the emailed code with vexillum publisher verify, a VexDV administrator approves it, and Vexillum then installs a certificate (valid about 90 days and renewed automatically) and starts publishing. Each instance can be published or kept private (tested on VEXJET, 3 to 4 Nov 2026). The docs say client IP addresses, passwords and file paths are never published.
• Metrics: a Prometheus-style metrics listener for monitoring.

The project advises treating early deployments as experimental.

Pros and cons

Pros

1. One program runs seven modes: D-STAR, DMR, M17, NXDN, P25, YSF and analog FM (VAFM).
2. Several reflectors per mode from one install, for example a public and a private DMR reflector, or three YSF rooms.
3. A web admin page instead of editing text files over SSH.
4. Named user accounts, roles and an audit log, useful when a club shares one server.
5. One callsign allow and block list covers every mode, and changes take effect immediately.
6. Analog FM linking built in through VAFM.
7. A public status API, live activity feed and metrics for dashboards and monitoring.
8. DVRef can list a VEX server and check each mode automatically.
9. Simple install: one program file for Linux, macOS or Windows.
10. Bridges reach BrandMeister, TGIF, FreeDMR, XLX and urfd.

Cons

1. No transcoding. Modes are separate rooms unless the operator runs bridges.
2. With the project's own bridges, cross-mode audio covers only DMR, YSF and NXDN, plus analog FM to DMR. P25 and M17 need an outside converter such as DVSwitch, and D-STAR also needs a hardware vocoder.
3. The YSF, NXDN and P25 modes are simplified, not full implementations of those standards.
4. YSF, NXDN and P25 have one room per instance, with no modules.
5. D-STAR supports DExtra only, not D-Plus or DCS.
6. Beta software: version 0.2, public since September 2026, and behavior may change.
7. The bridges have no releases yet and must be built from source.
8. No built-in dashboard. Operators use W0CHP's vex-dashboard or build their own.
9. A small user base so far: 4 servers online in the public directory and 91 connected stations on 4 Nov 2026.
10. One download source, repo.kc1awv.net, which was down on 2 Nov 2026.
11. Little outside documentation yet: no reviews or forum threads found.
12. The software license was not confirmed.

Compared with XLX and URF

In short, XLX and URF are built around one room that every mode shares, with a transcoder making that work. Vexillum is built around many separate single-mode reflectors under one roof, easy to manage from a web page, with bridges added where the operator wants modes or networks joined.

Who built it

Vexillum is written by Steve Miller, KC1AWV, credited on every page as "KC1AWV, Vexillum Developers, et al." KC1AWV has a long record of open amateur radio software on GitHub: gomrefdash (a dashboard for the mrefd M17 reflector), tools for the M17 reflector registry, MMDVM forks, and several projects for the Reticulum mesh network. The code, the bridges and the dashboard are hosted on his own code server at repo.kc1awv.net. The separate vex-dashboard is by W0CHP, who also writes the WPSD hotspot software.

Open questions

• License: the documentation site says "All rights reserved". Whether the code itself is under an open source license could not be checked because the repository server was down.
• Hotspot support: DMR, D-Star and M17 should work with standard hotspot software since they use the standard protocols. Tested on VEXJET, 4 Nov 2026: a standard MMDVM_Bridge logs in to DMR, G4KLX's P25Gateway links to the P25 instance and its polls are answered, USRP2M17 links to M17, and YSF and NXDN answer a hotspot login. Voice through stock Pi-Star or WPSD hotspots has not been tested yet.
• Host files: VEXJET's YSF 95114 and NXDN 9512 are registered with DVRef, but on 4 Nov 2026 the Pi-Star YSF list did not include 95114 yet. P25 9512 is already in the lists, because VEXJET took over the address of a retired P25 reflector. For DMR and M17 you add the server by hand.
• Long-term direction: version numbers are still 0.2, and the docs say flags and behavior will change.

Sources

• vexdv.io: overview, user guide, supported modes, connecting, VAFM guide, operator guide, configuration, admin interface, downloads, protocol reference for each mode, public API, bridges
• activity.vexdv.io: live directory, read 2 Nov and 4 Nov 2026
• Hands-on: N6JET's VEXJET server (vex.n6jet.com), 3 to 4 Nov 2026
• vex.on6dp.be and vex.w0chp.radio: operator dashboards
• github.com/kc1awv: author's public projects
• Pi-Star HostFilesUpdate.sh and the pistar.uk host lists: keeping your own hosts on Pi-Star, read 6 Nov 2026
• WPSD manual, How WPSD Manages Hostfiles: the Hosts File Editors, read 6 Nov 2026

Researched 2 Nov 2026. Origins: one project (documentation and directory) plus two independent operator dashboards.

---

A noncommercial hobby reference compiled by N6JET, gathered from public sources and shared freely for anyone interested in amateur digital voice.