Bridging DMR networks: link your network to XLX, HBlink and BrandMeister

Category: HotspotsDifficulty: ★★★~10 minutes

Your own network is great, but sometimes you want to reach out into the wider world: to an XLX reflector, to an HBlink server, or to the global BrandMeister. That is what bridges are for. Let's look at what they are, how a bridge rewrites talkgroups and where to keep it properly. If you are still choosing between your own network and a global one, first take a look at BrandMeister or your own network.

What a bridge is

A bridge is a separate "peer" that holds two connections at once: to your master and to the other network. It takes a voice stream from one network and carries it over to the other, swapping the addressing along the way: talkgroup, peer ID, sometimes the timeslot. To your network the bridge looks like an ordinary participant on the right talkgroup; to the other network it looks like an ordinary repeater.

Who calls whom Usually a bridge is an outbound client: it logs into the other network itself in the standard way (like a repeater), rather than opening an inbound port for outsiders. That is safer and does not require special permissions.

Bridge into an XLX reflector

XLX is built as a set of "modules" (rooms A–Z). To talk into a module, a peer first links it — with a short transmission on a service talkgroup (TG 4001 = module A, 4002 = B, and so on) — while the conversation itself goes on TG 9 ("the currently linked module"). The bridge reproduces exactly this behaviour: on connecting it links the chosen module and then carries voice on TG9. The catch: xlxd only accepts neatly formed header packets — "like a real radio" — otherwise the module will not link.

Bridge into HBlink / FreeDMR

HBlink is a "bare" Homebrew master. There is no module linking there: instead, on connecting the bridge sends RPTO options (static talkgroups) and then simply relays the required talkgroup. Access is governed by ACL: on a test bench this is often PERMIT:ALL, in production it is a whitelist of IDs. Several such connections on a single device is already a story about DMRGateway.

Connecting to BrandMeister

BrandMeister is connected differently and without a server-side bridge: in the dashboard the user enters their own BM credentials (BM DMR ID, the hotspot password from BM SelfCare and the BM master address), and during provisioning the hotspot writes them into its [DMR Network]. This is the standard, sanctioned method — an ordinary hotspot peer using a SelfCare password, no OpenBridge tickets. There is a deliberate downside: in BM mode the hotspot goes entirely over to BrandMeister, and your talkgroups are unavailable at that moment (on duplex modems you can split it: one timeslot for BM, the other for your own network).

Filters and loops

Two things that spoil life for any bridge:

Loops. If the bridge sends back into the other network what it has just received from there, the audio loops endlessly. The cure is for the bridge not to return a stream carrying its own src and to remember "its own" transmissions.
Filtering. Often you only want to let your own users out — the bridge filters by a list of known DMR IDs so a random subscriber cannot "break through" into the neighbouring network.

Frame size matters Different masters are fussy about packet format: xlxd, for example, strictly requires a frame of exactly 55 bytes (header/voice/terminator), whereas more lenient masters accept shorter ones too. The bridge must deliver the frame in the form the specific server expects, otherwise you get "connected, but no audio".

Server-side bridge or DMRGateway on the hotspot

You can link networks in two ways. DMRGateway lives on the hotspot and distributes your transmissions across several networks by talkgroup prefix — handy for a single operator, see the separate write-up. A server-side bridge lives next to the master and links networks wholesale, for all subscribers at once — that is already network infrastructure, not something for a single hotspot. The server-side approach has a bonus: your own vocoder lets you transcode audio when needed without hardware dongles.

In short A bridge is a translator-peer between networks: it links a module in XLX, sends options in HBlink, reaches BM over SelfCare. The key points are correct addressing, loop protection and the exact frame format. Next up: how the whole network is built.