DMR Cross-modes: DMR2YSF and DMR2NXDN

Two small programs let a DMR radio talk to Fusion and to NXDN with no vocoder hardware, no transcoding and no audio conversion at all. They work because those three modes already speak the same vocoder. Here is what they do, how the chain fits together, and what surprises people.

Scope: this page is written from the DMR radio's seat, and covers traffic leaving a DMR radio for another mode. The opposite direction, a Fusion radio reaching out to other modes, has its own page.

Why these two are the easy ones

Cross mode work is usually expensive because two modes use different vocoders, so the audio has to be decoded all the way back to plain sound and re-encoded on the far side. That needs either a hardware vocoder chip or a software one, and it costs a little quality every time.

DMR, Fusion in DN mode, and NXDN at 6.25 kHz do not have that problem. All three carry AMBE+2 at 2450 bits per second of speech plus 1150 bits of error correction, which is the same 3600 bit per second frame in all three modes. A bridge between them only has to lift the frame out of one container and put it in another.

You can see this in the software's own structure: the routine that repairs a DMR speech frame is the same routine used for Fusion and NXDN, compiled once and shared by all three.

The D-STAR row is the one that catches people out. The channel rate matches DMR exactly, and the frames still cannot be swapped, because the bits are divided differently between speech and protection.

Where the software actually lives

This trips up anyone searching for it. DMR2YSF and DMR2NXDN are not projects of their own. They are folders inside one repository of cross mode utilities, alongside their opposite numbers and the transcoding ones.

Folders present in that collection: DMR2YSF, YSF2DMR, DMR2NXDN, NXDN2DMR, YSF2NXDN, YSF2P25, DMR2P25, P252DMR, DMR2M17, M172DMR.

Worth noticing what is not there: no DMR to D-STAR converter in either direction. D-STAR is reached through a transcoding reflector instead, which is a different piece of work entirely.

How the chain fits together

Each converter sits in the middle of a chain, pretending to be a DMR network on one side and a Fusion or NXDN client on the other.

DMRGateway does no converting. Its job is routing: it takes the talkgroup you transmitted, applies a rewrite rule, and hands the traffic to one of several DMR network connections. One of those connections happens to be the converter. That is why cross mode talkgroups on a Pi-Star or WPSD hotspot usually carry a prefix, and it is also why people wrongly credit DMRGateway with the conversion itself.

The converter's own DMR side is configured exactly like a small DMR network:

[DMR Network]
Id=1234567
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
DefaultDstTG=9
TGUnlink=4000
TGListFile=TG-YSFList.txt

DMR2YSF, reaching Fusion from a DMR radio

• Talkgroups pick the reflector. A plain text file maps each DMR talkgroup to a Fusion reflector by its ID number, or to an FCS room by name. Transmit on the talkgroup, land on the room.
• 4000 unlinks, exactly as it does on DMR.
• Talkgroup 9 is the fallback destination when nothing else is set.
• Your callsign comes from the DMR ID database, looked up from your ID and refreshed daily.
• Fusion carries a callsign field of ten characters, so anything longer is trimmed to fit.

DMR2NXDN, reaching NXDN from a DMR radio

• You program NXDN talkgroup numbers into your DMR radio. That is the whole user interface: the converter treats the DMR talkgroup you called as the NXDN one it should join.
• Two lookup files are used, one for DMR IDs and one for NXDN IDs, so both ends can show a callsign.
• A default NXDN ID is configured for anything that cannot be matched.

The two things that surprise people

2. Talker Alias does not cross

Your radio may send Talker Alias, and DMR software handles it properly at both ends, but the cross mode converters make no mention of it anywhere in their code. It is dropped at the bridge. What the far side sees is whatever the converter looked up from the ID databases, which is why keeping those files current matters more on a cross mode path than on a plain DMR one.

What these two are not

Both transcoding pairs rely on a software vocoder built from radio firmware, and that library states plainly that it runs only on an ARM platform such as a Raspberry Pi 2, 3 or 4, and not on a Pi Zero or an original Pi. That constraint does not apply to DMR2YSF or DMR2NXDN, which never vocode anything.

Practical notes before you build one

1. One conversation at a time. These are point to point bridges, not conference systems. Whatever is on the far reflector arrives on your talkgroup and the reverse.
2. Hang times stack. Each program in the chain holds the path open for its own configured period, and the end to end result is the sum rather than the longest one. A long tail on a cross mode link is normally this rather than a fault.
3. Keep the ID files fresh. On a cross mode path they are the only source of a name at the far end.
4. Announce yourself in words. Given the above, a spoken callsign is worth more on a bridged path than on a normal one.
5. Be careful joining a pair of systems that are already joined. Two bridges between the same two networks is the classic way to build a loop. Note that this is widely repeated in the hobby and is not documented as a warning in these projects' own files, so treat it as prudence rather than as a published rule.

How the claims here were checked

Prepared for n6jet.com. The reverse direction, Fusion out to other modes, is covered on its own page. Software changes: the ports, file names and defaults above come from the configuration files as shipped, and a distribution may set them differently.