# Advanced Configuration

# Path Hash Modes (MeshCore)

## 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

<table id="bkmrk-modebytes-per-hopmax"> <thead><tr><th>Mode</th><th>Bytes per Hop</th><th>Max Hops</th><th>Unique IDs</th><th>CLI Setting</th></tr></thead> <tbody> <tr><td>**1-byte**</td><td>1</td><td>64</td><td>254</td><td>`set path.hash.mode 0`</td></tr> <tr><td>**2-byte**</td><td>2</td><td>32</td><td>65,536</td><td>`set path.hash.mode 1`</td></tr> <tr><td>**3-byte**</td><td>3</td><td>21</td><td>16,777,216</td><td>`set path.hash.mode 2`</td></tr> </tbody></table>

### Recommendation

Use **2-byte mode** (`set path.hash.mode 1`) for most North American community meshes.

- **1-byte mode** supports up to 254 unique IDs. With more than ~30 repeaters in range, hash collisions become likely, causing routing errors and ambiguous path attribution.
- **2-byte mode** supports 65,536 unique IDs, eliminating collision risk 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.

### Configuration Steps

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

### App Access

Path hash mode can also be adjusted in the companion app (v1.41.0+) 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.

# Regional Scoping with ISO Codes (MeshCore)

## Regional Scoping with ISO Codes (MeshCore)

Regional scoping is part of the **[RegionMesh](https://wiki.meshamerica.com/books/north-american-networks/page/regionmesh)** system for applying ISO 3166-2 geographic identifiers to MeshCore repeaters. It allows repeaters to filter message routing by region, reducing cross-country network congestion.

### How It Works

- Messages *without* an explicit scope use a wildcard `*` region and reach all repeaters regardless of region configuration.
- When a message carries a scope: *"Repeaters only forward messages when the scope precisely matches a configured region."*
- This allows a regional community (e.g., Colorado) to create channels that stay within their region without polluting the national mesh.

### Configuration Limits

- The number of regions configurable per repeater depends on firmware version. Refer to MeshCore release notes for current limits.
- Region identifiers: lowercase, maximum 29 bytes
- Minimum scope: country code (`us`) plus state code (`us-co`)

### CLI Configuration Example (Colorado)

```
region put us
region put us-co us
region save
```

This configures the repeater to serve both the national US scope and the Colorado state scope.

### Standard ISO 3166-2 Region Codes

<table id="bkmrk-coderegion-usunited-"> <thead><tr><th>Code</th><th>Region</th></tr></thead> <tbody> <tr><td>`us`</td><td>United States (national)</td></tr> <tr><td>`us-co`</td><td>Colorado</td></tr> <tr><td>`us-nd`</td><td>North Dakota</td></tr> <tr><td>`us-or`</td><td>Oregon</td></tr> <tr><td>`us-wa`</td><td>Washington</td></tr> <tr><td>`ca`</td><td>Canada (national)</td></tr> </tbody></table>

### Community-Defined Local Region Codes

Beyond ISO 3166-2 state/province codes, communities can define metro-area codes. These are registered by community consensus in the RegionMesh Discord:

<table id="bkmrk-codearea-us-dfwdalla"> <thead><tr><th>Code</th><th>Area</th></tr></thead> <tbody> <tr><td>`us-dfw`</td><td>Dallas/Fort Worth</td></tr> <tr><td>`us-bay`</td><td>[San Francisco Bay Area](https://wiki.meshamerica.com/books/north-american-networks/page/san-francisco-bay-area)</td></tr> <tr><td>`us-atl`</td><td>Greater Atlanta</td></tr> </tbody></table>

New local codes are established by community consensus and registered in the RegionMesh Discord at [meshcore.gg](https://meshcore.gg).

### After Changing Region Configuration

Always run `advert` after saving region changes 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.

## The 902-928 MHz Band Structure

In the United States, the 902-928 MHz ISM band is 26 MHz wide. LoRa transmissions are narrow (125-500 kHz bandwidth), so many channels can coexist. However, dense networks in the same area can cause packet collisions if they use identical frequencies.

### Meshtastic Channel Numbers

Meshtastic calculates its center frequency from a channel number (0-7 by default) and the modem preset bandwidth. With 125 kHz BW, channels are spaced 125 kHz apart.

```
# Default US center frequency (channel 0, 125 kHz BW):
# 906.875 MHz

# Set channel number via CLI:
meshtastic --set lora.channel_num 3
```

### MeshCore Frequency Selection

MeshCore uses fixed frequency presets. The USA/Canada preset is 910.525 MHz. 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:

1. **Different channel keys with same frequency** - Networks stay logically separate even if they occupy the same frequency. Acceptable for low-traffic networks.
2. **Different frequencies + different keys** - True RF isolation. No collision possible. Recommended for medium/high-traffic networks within range of each other.
3. **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:

<table id="bkmrk-networkfrequencypres"><thead><tr><th>Network</th><th>Frequency</th><th>Preset</th><th>Coverage Area</th><th>Contact</th></tr></thead><tbody><tr><td>Portland Mesh</td><td>906.875 MHz</td><td>LongFast</td><td>Metro PDX</td><td>ops@pdxmesh.net</td></tr><tr><td>Columbia Gorge Mesh</td><td>907.125 MHz</td><td>LongFast</td><td>Hood River/The Dalles</td><td>k7xyz@arrl.net</td></tr></tbody></table>