Advanced Configuration

Path Hash Modes (MeshCore)
Regional Scoping with ISO Codes (MeshCore)
Frequency Coordination and Channel Planning

Path Hash Modes (MeshCore)

Path hash modes control how repeaters identify themselves in routing path headers within MeshCore packets. This feature is available in recent MeshCore firmware versions. Check your firmware release notes for version-specific availability.

Mode Comparison

Mode	Bytes per Hop	Max Hops	Unique IDs	CLI Setting
1-byte	1	64	256	`set path.hash.mode 0`
2-byte	2	32	65,536	`set path.hash.mode 1`
3-byte	3	21	16,777,216	`set path.hash.mode 2`

Mode 0 (1-byte) is the default.

Recommendation

Use 2-byte mode (set path.hash.mode 1) for most North American community meshes (a common community recommendation, e.g. NodakMesh).

1-byte mode provides 256 possible hash IDs. By the birthday paradox the chance of a collision reaches ~50% at only about 19 repeaters in range (well below 256), so with more than ~30 repeaters in range hash collisions become likely, causing routing errors and ambiguous path attribution.
2-byte mode provides 65,536 possible hash IDs, making collisions vanishingly unlikely for any realistic community mesh while keeping per-hop overhead to 2 bytes.
3-byte mode is future-proof but reduces maximum hop count to 21, which may be limiting in networks with long routing chains.

Mixing path hash modes within a single mesh requires all in-path repeaters to be running firmware ≥ 1.14. On networks where some repeaters run older firmware, keep every device on the same (default) mode.

Configuration Steps

Connect to the repeater via USB serial (115200 baud) or Bluetooth
Set the desired mode:
```
set path.hash.mode 1
```
Broadcast updated hash to the network:
```
advert
```

App Access

In recent companion-app versions (around v1.41.0+; check current release notes, as the menu location may change between versions), path hash mode can also be adjusted under:

Settings → Experimental Settings

Note that "Experimental Settings" must be enabled in the app before this option appears.

Network-Wide Consistency

All repeaters and nodes on the same network segment do not need to use the same path hash mode - mode is a per-device setting affecting how that device encodes its own ID in path headers. However, for consistent diagnostics and network analysis, aligning all devices to the same mode simplifies troubleshooting, and mixing modes requires all in-path repeaters to be on firmware ≥ 1.14 (see above).

Regional Scoping with ISO Codes (MeshCore)

Regional Scoping (MeshCore Region Filtering)

MeshCore region scoping (region filtering) lets repeater operators tag flood traffic with a region so that repeaters only forward scoped packets within their configured region, reducing cross-country network congestion. A region is not an ISO 3166-2 code and there is no built-in standard, code table, or official registry inside the firmware. A region is simply an arbitrary, operator-chosen plain name that the firmware SHA-256 hashes into a 2-byte transport code carried in the packet header; repeaters match on that hash.

Communities often adopt ISO-3166-2-style strings such as us or us-co purely as a naming convention. These work only because they are valid arbitrary names - the firmware never interprets them as ISO codes, validates them against any standard, or enforces a country/state hierarchy. Any agreed string works equally well.

How It Works

A region name is a string of lowercase alphanumeric characters and hyphens (a-z, 0-9, -), maximum ~29 bytes (UTF-8). Within a given mesh, region names must be unique, and they must match exactly - any misspelling is treated as a completely different region.
The firmware hashes the name (SHA-256) down to a 2-byte identifier. Because the identifier is only 2 bytes, hash collisions between different names are possible (though unlikely for a small set of regions).
Legacy flood packets that carry no scope are still forwarded everywhere by default - region filtering only applies to packets that carry a scope.
Since v1.10.0 a basic rule applies: a repeater will not forward a flood packet that has a scope set when the repeater has no matching region. Repeaters running firmware older than v1.10.0 do not honor scopes, so scoped traffic can still leak across them.

This lets a local community (for example, a Colorado group) agree on a region name and keep its scoped traffic within that region instead of flooding the wider mesh.

Configuration Notes

The number of regions configurable per repeater depends on firmware version. Refer to MeshCore release notes for current limits.
Region names: lowercase alphanumeric plus hyphen, maximum ~29 bytes (UTF-8), unique within a mesh, matched exactly.
There is no firmware-enforced minimum scope (no required country + state). Any hierarchy - such as a broad us region plus a narrower us-co region - is purely a convention agreed among operators, not a rule the firmware enforces.

CLI Configuration Example (Colorado)

The names below (us, us-co) are arbitrary example strings, not standardized codes. Defining a region is not enough on its own - you also issue region allowf (allow flood) for each region to actually permit scoped flood forwarding, then region save:

region put us
region put us-co us
region allowf us
region allowf us-co
region save

This configures the repeater with two arbitrary regions (us and us-co) and enables flood forwarding for both. The names carry no inherent geographic meaning to the firmware - they match only because every participating operator uses the exact same strings.

Example Region Names (Convention Only)

The strings below are examples of arbitrary names a community might agree to adopt. They are not ISO 3166-2 codes recognized by MeshCore and are not validated by the firmware - they work only among networks that all agree to use them. Pick any short, agreed name for your local mesh; everyone in scope must use the identical string.

Example Name	Could Represent
`us`	United States (broad)
`us-co`	Colorado
`us-nd`	North Dakota
`us-or`	Oregon
`us-wa`	Washington
`ca`	Canada (broad)
`us-dfw`	Dallas/Fort Worth metro
`us-bay`	San Francisco Bay Area metro
`us-atl`	Greater Atlanta metro

Agreeing on Region Names

There is no central registry built into MeshCore. Choosing region names is a coordination exercise: operators discuss in whatever forums they use (or even over the mesh itself) and come to a consensus on how to divide up their geography. Whatever string you settle on, every repeater that should share that region must be configured with the exact same name.

Third-party community sites such as regionmesh.com publish suggested naming conventions to help operators coordinate, but these are independent community resources, not official MeshCore registries - the firmware neither knows about nor enforces them.

After Changing Region Configuration

After saving region changes, run advert to broadcast the updated configuration to the network immediately rather than waiting for the next scheduled advertisement.

Frequency Coordination and Channel Planning

When multiple independent mesh networks coexist in the same geographic area, frequency and channel coordination prevents interference and allows for intentional interconnection where desired. Note: this is voluntary self-coordination among unlicensed Part 15 operators, not formal frequency coordination. You cannot reserve a frequency, and channel choices are limited to the fixed slots your preset bandwidth defines within 902-928 MHz.

The 902-928 MHz Band Structure

In the United States, the 902-928 MHz ISM band is 26 MHz wide. LoRa channel bandwidth in Meshtastic ranges from 125 kHz (SF12 Long-Slow) to 500 kHz (ShortTurbo); the common LongFast/MediumFast presets use 250 kHz. Because each transmission occupies only part of the band, many slots can coexist. Note: FCC 15.247(a)(2) digital modulation requires a minimum 6 dB bandwidth of 500 kHz, so compliance for the narrower LoRa bandwidths depends on the device's specific FCC type acceptance. Dense networks in the same area can still cause packet collisions if they share the same frequency slot.

Meshtastic Channel Numbers

Meshtastic derives its center frequency from a frequency-slot number and the preset bandwidth. Slot spacing equals the preset bandwidth — 250 kHz for LongFast (104 US slots), and 125 kHz only for the 125 kHz presets — so 250 kHz is the default spacing, not 125 kHz. Slots span the whole regional band (0-103 for US LongFast); when the slot is left at default it is chosen by hashing the channel name, not by a simple channel index. Note that these frequency slots are distinct from the up-to-8 logical channels (name/PSK), which all share the same frequency.

# US LongFast (250 kHz BW) default frequency:
# 906.875 MHz, which is slot 20 — selected by hashing
# the default channel name "LongFast" (not "channel 0").
#
# Raw formula for an explicit slot n (1-indexed):
# freq = 902.0 + 0.125 + (n-1)*0.25 MHz

# Set the frequency slot explicitly via CLI:
meshtastic --set lora.channel_num 3

MeshCore Frequency Selection

MeshCore uses fixed frequency presets. One commonly used US/Canada preset is 910.525 MHz (as of 2026-06-08; verify against current MeshCore release/docs, as there are multiple US presets at different SF/BW and frequencies — there is no single fixed USA/Canada frequency). Networks in the same area using MeshCore should coordinate to avoid using the same frequency if they don't want to interoperate.

Avoiding Interference with Other Users

The 902-928 MHz band is shared with ISM devices, FHSS systems, baby monitors, cordless phones, and other LoRa networks. If you observe high packet error rates that don't correspond to weak signal strength, interference from another source may be the cause. Use an SDR (Software Defined Radio) to scan the band and identify active signals.

Multi-Network Coordination

When two community networks exist in overlapping geographic areas, coordinate:

Different channel keys with same frequency - Networks stay logically separate even if they occupy the same frequency. Because they share the same frequency slot, they share airtime and can still collide; acceptable for low-traffic networks.
Different frequencies + different keys - Minimizes collisions between your two networks. Note: 902-928 MHz is unlicensed shared ISM spectrum (FCC Part 15); no operator owns a frequency and you have no legal protection from interference by other ISM/FHSS devices. Different center frequencies reduce, but do not guarantee elimination of, collisions. Also note that nodes on different frequency slots cannot hear each other.
Intentional bridging - A dual-radio or dual-channel node that bridges the two networks. Both networks benefit from the other's coverage.

Documentation for Multi-Network Areas

Maintain a local frequency coordination document shared between network operators:

Network	Frequency	Preset	Coverage Area	Contact
Portland Mesh	906.875 MHz	LongFast	Metro PDX	ops@pdxmesh.net
Columbia Gorge Mesh	907.125 MHz	LongFast	Hood River/The Dalles	k7xyz@arrl.net