Color Code Made Simple: Why Your Radio Stays Silent

The radio is configured, the hotspot glows green, your callsign is in the database — yet there's silence on the air. One of the most common reasons: the Color Code doesn't match between the channel in the radio and the hotspot's settings. Let's break down what it actually is, why it matters, and how to fix it in one minute.

What is a Color Code

The Color Code (CC) is a numeric parameter from 0 to 15 embedded in every DMR frame. Conceptually, it's the digital equivalent of the CTCSS sub-tone in analog FM: it carries no voice and doesn't affect quality — its only function is to act as an access filter. If the CC in the incoming signal doesn't match what the receiver expects, the signal is silently discarded.

An important difference from CTCSS: in analog, the sub-tone can be turned off and you can listen "bare" with a scanner. In DMR the Color Code is mandatory — it's built into the frame structure and cannot be absent. The radio always checks it, whether you want it to or not.

Where the 16 values come from and what they're for

The 0–15 range gives 16 options. That number is no accident: the four bits of the CC fit into the data field of the DMR frame (the ETSI TS 102 361 standard). The point of having several values is the ability to separate multiple systems operating on the same frequency in the same area, so that radios on one network don't open up on another network's signal.

In practice, amateur radio most often uses CC1. The value CC0 is sometimes used for test and simplex channels, but this isn't standardized anywhere — it's just an established convention.

How the CC travels through the system

There's a single chain: radio → hotspot (MMDVM) → server. At the input, the hotspot checks the CC of the RF signal. If it doesn't match, the signal is rejected right at the radio-frequency level, before any data goes to the network.

In the MMDVM/Pi-Star/WPSD logs a mismatch looks roughly like this:

DMR Slot 2, RF user 2500001 rejected

A rejected line with no further explanation is almost always either a CC mismatch or a frequency mismatch (high BER). The hotspot usually writes no additional error message about the CC — it simply refuses silently.

Where the Color Code is set

In the radio (CPS)

Open the CPS, find the channel you need and look for a field named Color Code or CC. It's usually next to the Slot/Timeslot field. Set the value that's configured on the hotspot — for DMRhub that's 1.

In the hotspot (RadioStar / Pi-Star / WPSD)

In the hotspot's web interface, in the DMR settings section, look for the Color Code field. In the RadioStar image it's in the main configuration tab, right next to the frequency. By default it's already set to CC1 — exactly what's needed for DMRhub.

Typical mismatch scenarios

• A ready-made codeplug from the internet — it often has the CC set for some specific repeater, not CC1. Change the field in the CPS for every channel of your hotspot.
• You reflashed the radio (OpenGD77) — on first launch the OpenGD77 CPS creates a channel with CC0 by default. Fix it right there in the channel editor.
• The hotspot was reconfigured — CC0 or CC2 was accidentally set in the web interface. Set it back to CC1, save, and reboot.
• Several hotspots with different CCs — if you have hotspots at home and at work on the same frequency but with different CCs, you'll have to create two separate channels in the codeplug, one for each hotspot.

Quick diagnosis: checklist

1. Check the hotspot logs — are there rejected lines? That means the signal is arriving but being filtered out.
2. No lines at all — the signal isn't physically reaching it (frequency, power, distance).
3. Compare the CC field in the radio's channel with the CC field in the hotspot's settings — they must be equal.
4. For DMRhub both values must be 1.
5. If the CCs match but rejected still appears — check the frequency and the BER level (see the calibration article).