MMDVM.ini explained: a breakdown of the key parameters

The MMDVM.ini file is your hotspot's passport. Everything is baked into it: the callsign, the DMR ID, which board you are running, how the modem's signals are inverted, which server to connect to and what frequency corrections to apply. When something "won't take off" — the radio doesn't reach the network, the BER creeps up, the server refuses the connection — the answer almost always lives in this text file. Let's go through the key sections and parameters one by one: what they do, which values are safe, and where a single wrong digit turns a working hotspot into a brick.

Why bother getting into MMDVM.ini at all

The classic MMDVMHost (G4KLX's daemon that links the MMDVM modem to the digital networks) reads its configuration from exactly this ini file at startup. In the world of Pi-Star and WPSD a web front end usually generates it for you, so you never have to dig in by hand. But you still need to understand the structure: for when the panel "can't do" something, when you are diagnosing someone else's hotspot from the logs, or when a non-standard board needs manual edits to its inversions and offsets.

On the DMRhub network it is even simpler: the agent on the hotspot generates MMDVM.ini automatically from your account data and keeps it up to date over OTA. The server address, port, password and your DMR ID are all filled in for you. Normally you never need to edit the file by hand at all; this breakdown is so that you understand exactly what the agent writes there and why.

The [General] section: the hotspot's identity

This is "who I am and how I behave." There are four parameters here that get touched most often.

• Callsign — your callsign. It goes out to the network and on the air, and must match your licence. Case isn't critical, but there should be no spaces or stray characters.
• Id — your DMR ID (7-digit for a subscriber). This is what the network uses to identify you and route private calls. Someone else's or a made-up ID is a guaranteed conflict and a ban. You can get a real ID by registering in the system.
• Duplex — 0 for a simplex hotspot (one frequency for both receive and transmit — that's 99% of home-built single-board MMDVMs) and 1 for a duplex repeater. Set 1 on a simplex board and receive and transmit will start to conflict, and there will be no link.
• Timeout — the maximum length of a single transmission in seconds (TOT). The default is usually 240. It protects against a "stuck PTT."

The [Modem] section: the heart of the hardware

The most dangerous section. This describes the MMDVM board itself and its RF fine-tuning. A mistake here doesn't produce an obvious error in the log — the hotspot just "seems to work," yet the radio hears nothing.

Port and board type

• Port (UARTPort in newer versions) — the modem device. For HAT boards on the GPIO this is usually /dev/ttyAMA0 or /dev/serial0; for USB dongles something like /dev/ttyACM0. The wrong port means the modem isn't found, with "opening serial port failed" in the log.
• The board type and the clock oscillator are set by parameters like TXInvert/RXInvert and the TCXO frequency block. Many boards use a 14.7456 MHz oscillator, but cheap clones can come with other crystals — hence the frequency drift.

Inversions: TXInvert / RXInvert

TXInvert and RXInvert (values 0/1) flip the polarity of the signal. Different boards and different radio chips require different inversion. The symptom of a wrong inversion is classic: the hotspot transmits, the radio hears it, but it does not receive the reply from the radio (or vice versa). If everything works in one direction but the other is dead, the first thing to do is flip the corresponding Invert to the opposite value.

Offsets: RXOffset / TXOffset

These are frequency corrections in hertz that compensate for the inaccuracy of the modem's crystal. The goal is for the actual receive and transmit frequencies to match the declared one to within a few hundred hertz. They are not picked by eye but from the results of calibration. The process is described in detail in the articles on frequency calibration and MMDVMCal step by step.

Levels: RXLevel / TXLevel

This is the modulation depth on receive and transmit (as a percentage, 0–100). Too low a TXLevel means weak deviation and the radio barely decodes. Too high means over-modulation and a rise in errors. These two parameters are directly tied to the health of the air: you tweak them to get the minimum BER. There's more in the breakdown of TXLevel and RXLevel, and on the target BER figures in the article what counts as a normal BER.

The [DMR] section: the mode you actually use

• Enable — 1, otherwise DMR is turned off on the hotspot. Obvious, but a forgotten Enable=0 after editing a neighbouring mode is a common cause of "everything's gone."
• ColorCode — the color code (0–15), the digital equivalent of a sub-tone in analogue. It must match between the hotspot and the radio's channel. If it doesn't match, the radio stays silent even though there is a signal. This is one of the most common causes of "it doesn't work" overall; see the dedicated breakdown of Color Code.
• The TS1/TS2 slots — on a simplex hotspot only one time slot is actually used; in duplex both work. Most networks route the hotspot's traffic to the second slot (TS2) by default.
• EmbeddedLCOnly and the related parameters control how the service information (Link Control) is carried inside the stream. For a single hotspot you almost never need to touch them — leave them at the default.

The [DMR Network] section: the link to the server

This is where the hotspot learns where to connect. The parameters:

• Address — the address or host of your network's master/server.
• Port — the server's UDP port (traditionally 62031 for DMR masters, though it may differ for a particular network).
• Password — the password for connecting to the master. A wrong password means the server silently refuses you, with "login retry" looping in the log.
• Jitter — the size of the jitter buffer in milliseconds (often 360). It smooths out uneven packet delivery. Raising it makes sense only on a bad, choppy internet connection; on a normal link extra jitter just adds latency.

On DMRhub the agent sets all three of the top parameters itself from your profile — this is the main reason manual editing is usually unnecessary and even harmful: on the next OTA update your changes will be overwritten with the correct ones.

Displays: [OLED] and [Nextion]

Purely cosmetic sections; they don't affect the RF side.

• [OLED]: Type sets the screen model SSD1306/SH1106 (usually 3 or 6 depending on the glass), plus Brightness and Flip (flip the image if the screen is mounted upside down).
• [Nextion]: for Nextion touch displays you specify their own Port and baud rate. If the screen isn't on the same line as the modem, the ports must not conflict.

A mistake in these sections at most blanks the screen — the link will keep working.

Common mistakes

• Wrong Duplex. Duplex=1 on a single-board simplex hotspot — no link at all.
• ColorCode mismatch between the ini and the radio's channel — the most common "silent" failure.
• Copied someone else's offsets. RXOffset/TXOffset are unique to each board; foreign values shift the frequency.
• Swapped inversions. The link works in only one direction — tweak TXInvert/RXInvert.
• Wrong modem port. The UART on the Pi isn't freed up (it's taken by the console/Bluetooth) — the modem won't open.
• A foreign or zero Id. The network won't let you in or will ban you; you need a real, registered DMR ID.

Mini cheat sheet: the dangerous parameters

• [General] Duplex — wrong → no link. Simplex = 0.
• [General] Id — someone else's → ban. Only your own DMR ID.
• [Modem] RXOffset / TXOffset — foreign → frequency drift, rising BER, silence on receive.
• [Modem] TXInvert / RXInvert — wrong → link in only one direction.
• [Modem] RXLevel / TXLevel — extremes → over-modulation or deafness, bad BER.
• [DMR] ColorCode — doesn't match the radio → the radio stays silent.
• [DMR Network] Password — wrong → endless login retry.

If you remember only one rule out of the whole file, let it be this: the RF parameters from [Modem] (offsets, levels, inversions) are arrived at by measurement on your specific unit, not by copying. The details of measuring are in the guides on MMDVMCal and levels.