# Channel and Frequency Planning

# Meshtastic Channel Number Selection Guide

Meshtastic has two distinct concepts that are easy to confuse. The **LoRa Frequency Slot** (`lora.channel_num`) selects the single center frequency the radio transmits on. This is separate from the up-to-8 **logical Channels** (each with its own name and PSK, indexes 0–7), which **all share the same frequency**. Adding logical channels gives you separate encrypted message streams — it does **not** change your RF frequency, provide RF isolation, or avoid collisions. Only changing the frequency slot (or the modem preset) actually moves you to a different frequency.

## How the Frequency Is Chosen

Meshtastic does **not** compute the center frequency from a logical channel number using a simple base + spacing formula. Instead, the firmware divides the region's band into a fixed number of **frequency slots** (slot width = the preset's bandwidth) and picks one slot:

- If `lora.channel_num` is **0 / UNSET** (the factory default), the firmware computes a **hash of the PRIMARY channel's NAME** (a djb2 hash in `RadioInterface.cpp`) and uses it to select a slot.
- If `lora.channel_num` is set to **1–104**, that value is an **absolute slot index** and overrides the name hash.

For the **US 902–928 MHz band with the LongFast preset, the bandwidth is 250 kHz**, which yields **104 frequency slots** of 250 kHz each across the 26 MHz usable band. (125 kHz is the bandwidth of the Long Moderate / Long Slow presets, not LongFast — those presets have more slots.)

```
# US region, LongFast preset
# Bandwidth (slot width): 250 kHz
# Number of frequency slots: 104

# Default channel_num = 0/UNSET -> frequency comes from a HASH of
# the PRIMARY channel NAME, NOT from a linear base+offset formula.
# The default LongFast channel name hashes to slot 20 = 906.875 MHz.

# Slot-to-frequency formula (only when you set an explicit slot):
#   freq_MHz = freq_start + (slot * bandwidth) + (bandwidth / 2)
# US: freq_start = 902.0 MHz, bandwidth = 0.250 MHz, slot is 1-based (1..104)
#
# Example, default LongFast slot 20:
#   902.0 + (20 * 0.250) + 0.125 ... is reached via the name hash,
#   giving the documented default of 906.875 MHz.
```

Note that **906.875 MHz corresponds to frequency slot 20** (the result of hashing the default channel name), *not* "channel 0." There is no `base 902.0 + channel × 0.125` linear progression, and the slot index is not limited to 0–7 — those are the logical channels, a completely separate concept.

## Why Change the Default Slot?

Most Meshtastic nodes ship on the default LongFast channel, which hashes to slot 20 (906.875 MHz). If your area already has significant Meshtastic traffic, you may benefit from staying on the default to maximize connectivity with existing nodes. However, if:

- You're running a private community network that wants to operate on its own frequency (note: changing frequency means those nodes can no longer hear the default mesh, and vice versa)
- You've identified interference at the default frequency with an SDR
- You want to operate on a less crowded frequency in a dense metropolitan area

...then setting an explicit frequency slot (or choosing a different primary channel name that hashes to a different slot) makes sense. Changing logical channels alone will **not** do this — logical channels all share the same frequency.

## Frequency Coordination

For all nodes in your community network to hear each other, they must transmit on the **same frequency** — meaning the same modem preset *and* the same frequency slot (which means either the same primary channel name, since the name-hash sets the slot, or the same explicitly set `lora.channel_num`). They must also share the same channel name/PSK to decode each other's traffic. Keep a community coordination document:

```
# Check current frequency slot:
meshtastic --get lora.channel_num

# Set an explicit frequency slot (absolute slot index, 1-104 for US LongFast):
meshtastic --set lora.channel_num 3

# This selects frequency SLOT 3, an absolute slot - NOT an offset added
# to 906.875. For US LongFast (250 kHz):
#   902.0 + (3 * 0.250) + 0.125 = 903.375 MHz
#
# Setting channel_num to 0 reverts to the channel-name hash (default).
```

## Bandwidth and Frequency-Slot Separation

Two independent networks on the same band coexist by transmitting on **different frequency slots** (set via different slot numbers, or different primary channel names that hash to different slots). Separating two networks by ≥2 slots reduces adjacent-channel interference, but it does **not** give complete RF isolation — LoRa's spectral skirts extend beyond the nominal bandwidth and the 902–928 MHz band is shared ISM spectrum, so some interference is always possible. (Separate channel names/PSKs alone provide only *logical* separation — same frequency, same airtime, same collisions.) Practical guideline:

<table id="bkmrk-modem-presetbandwidt"><thead><tr><th>Modem Preset</th><th>Bandwidth (slot width)</th><th>Separation for substantial isolation</th></tr></thead><tbody><tr><td>LongFast</td><td>250 kHz</td><td>≥1 slot (250 kHz); ≥2 slots (500 kHz) for better margin</td></tr><tr><td>MediumFast</td><td>250 kHz</td><td>≥1 slot (250 kHz); ≥2 slots (500 kHz) for better margin</td></tr><tr><td>ShortFast</td><td>250 kHz</td><td>≥1 slot (250 kHz); ≥2 slots (500 kHz) for better margin</td></tr><tr><td>ShortTurbo</td><td>500 kHz</td><td>≥1 slot (500 kHz); ≥2 slots (1000 kHz) for better margin</td></tr></tbody></table>

If two networks operate on adjacent slots with the same bandwidth, they'll still experience some adjacent-channel interference and won't be completely isolated. Remember that putting your network on a different frequency slot from the local default mesh means the two networks can no longer relay for each other — that's the intended trade-off when you want a private frequency.

# Operating Multiple Channels on One Network

Running multiple Meshtastic channels on the same network infrastructure enables privacy separation, role-based access control, and operational flexibility. This page covers design patterns for multi-channel community networks.

## Why Multiple Channels?

- **Privacy tiers:** Public channel (open access) + private community channel (member-only key) + infrastructure/ops channel (operators only)
- **Functional separation:** General chat, emergency/tactical, telemetry/MQTT, admin coordination
- **Geographic zones:** Neighborhood channels within a metro-wide network
- **Inter-network bridging:** A bridge node can monitor a second network's channel while primarily operating on your community channel

## Channel Capacity

Meshtastic supports up to 8 channels simultaneously on a single node (slots 0-7). Channel 0 is the primary channel (all nodes have it). Channels 1-7 are secondary and only active on nodes configured to use them.

All enabled channels share the same LoRa radio and the same RF frequency - the node transmits and receives on one frequency at a time. Adding channels does not add spectrum; it adds logical (name/PSK) separation only. Multiple channels increase channel utilization proportionally with message volume on each channel, because every channel's traffic competes for the same airtime.

## Recommended Multi-Channel Configuration

The commands below use the official Meshtastic Python CLI. `--ch-add` creates a new secondary channel, and `--ch-index N --ch-set <field> <value>` sets a field on the channel at that index (see the Meshtastic CLI reference at meshtastic.org/docs/software/python/cli/).

```
# Channel 0: Public community channel
meshtastic --ch-index 0 --ch-set name "PDXMesh"
meshtastic --ch-index 0 --ch-set psk "community-key-base64=="
meshtastic --ch-index 0 --ch-set uplink_enabled true # optional: MQTT bridge
meshtastic --ch-index 0 --ch-set downlink_enabled false # prevent loops

# Channel 1: Operations/admin (limited to infrastructure operators)
meshtastic --ch-add
meshtastic --ch-index 1 --ch-set name "PDX-Ops"
meshtastic --ch-index 1 --ch-set psk "ops-key-base64=="
meshtastic --ch-index 1 --ch-set uplink_enabled false # keep off MQTT
meshtastic --ch-index 1 --ch-set downlink_enabled false

# Channel 2: Emergency (activated during events)
meshtastic --ch-add
meshtastic --ch-index 2 --ch-set name "PDX-EmComm"
meshtastic --ch-index 2 --ch-set psk "emcomm-key-base64=="
```

## Channel Key Management

With multiple channels, key management becomes important:

- Store all channel keys in a password manager (Bitwarden, 1Password) shared with authorized operators
- Document which nodes have which channels configured - a node without channel 2 will miss emergency messages
- When a key is compromised, change only the affected channel key - other channels are unaffected
- Establish a key rotation schedule: community channel annually, ops channel quarterly, emcomm channel pre-activation

## Traffic Impact

Each additional active channel increases channel utilization by the traffic that channel carries — all channels share one radio and one frequency, so their airtime adds up. Monitor total CU across all channels:

- With 3 channels, target total CU under 20% combined (channel utilization is reported over a 1-minute window; firmware self-throttles, deferring its own transmissions, as CU rises around 25%)
- Low-activity channels (ops, emcomm) add minimal overhead: mostly periodic NodeInfo broadcasts
- A busy community-chat channel can contribute a substantial share of total CU; the exact percentage depends on message rate, packet size, and modem preset, so measure it on your own network rather than assuming a fixed figure