New South Wales Meshcore Network & Repeater Configuration Guide

📚 Getting Started with MeshCore

📺 Video Guide: How to get started with MeshCore off grid text messaging — A helpful walkthrough explaining MeshCore, how it works, and how to set it up.

Overview

Follow these steps to get your node running on the Sydney mesh:

1. Set Up Your Companion — Flash the device, connect it, and configure its name and radio settings.
2. Choose Radio Settings — Pick the frequency preset that matches your area so you can communicate with nearby nodes.
3. Set Region Scoping — Assign a default region (IATA code) so your messages route to the right part of the network.
4. Join & Test the Mesh — Advertise your node, discover nearby repeaters, and send a test message to confirm connectivity.

Setting Up Your Companion

Step 1: Flash Your Device

Flash your device using the Meshcore firmware flasher.

⚠️ Before flashing: Choose your connection method now — the firmware only supports one connection type at a time:

• BLE (Bluetooth Low Energy)
• USB (wired connection)
• WiFi (wireless)

💡 First time flashing? Make sure to select "Erase" before flashing MeshCore.

Step 2: Connect and Configure

Connect to your companion using your chosen method, then configure:

Set Name and Radio Settings:

1. Tap the ⚙️ icon (top right of the app)
2. Configure your name and radio settings:
   • Preset Australia: Mid (915.075 MHz, BW 125, SF9, CR5) — Greater Sydney and surrounds
   • Preset Australia: Narrow (916.575 MHz, BW 62.5, SF7, CR8) — EastMesh default; used for links south
   • Set default region: if within the Sydney area use au-nsw-syd, otherwise use your local region as per the Region Map
   • Set the path hash mode to 2 byte
3. Tap ✔️ (top right) to save
4. Wait for the green success notification

💡 Most users in Greater Sydney and surrounds are on Mid. Mid is the main preset for the region. Narrow is also used and remains important as the EastMesh default — it's the primary link south to beyond Canberra. The two presets are not interoperable with each other — devices must be on the same preset to communicate. Bridge repeaters connect the networks. See Radio Settings for full details.

Add Channels:

1. Tap ⋮ (top right) → + Add Channel → Join a Hashtag Channel
2. Enter the channel name (e.g., test)
3. Press Join Channel
4. If adding the Public channel, set its scope to unscoped

Step 3: Join the Mesh

Advertise Your Node:

1. Tap Advert (button next to ⚙️) → Send Flood Advert
2. This broadcasts your node name to the mesh

Discover Nearby Repeaters:

1. Tap 🔧 → Discover Nearby Nodes → Discover Repeaters
2. Wait for repeaters within range to respond
3. Tap + to add them to your contacts

Step 4: Test Your Connection

Send a Test Message:

• Send a greeting to the Public channel (general chat), or
• Send test, ping, or path to the #test channel (bots will auto-reply)

Check Your Results:

After sending, look for heard X repeats next to your message:

⏳ Give the Mesh Time to Respond: Messages and commands travel hop-by-hop across the mesh, so they can take a while to go through — especially over longer distances or with more hops. After sending, wait and give the mesh time to relay your message before assuming it failed; the heard X repeats confirmation may take a few seconds. Commands (e.g. Test, Path, Ping) can take up to 30 seconds to propogate through the mesh, get replied to and propogate back. If something doesn't seem to happen immediately, be patient and try again after 30 Seconds.

Result	Meaning
heard 1+ repeats	✅ Success! Your message reached repeater(s)
heard 0 repeats	❌ No repeater heard your message

If you see 0 repeats:

1. Double-check your radio settings
2. Check the NSW Meshcore Map for nearby repeaters
3. Long-press your location on the map to check expected coverage
4. Try standing outside with antenna pointing upward
5. Find higher ground to clear buildings (line-of-sight to repeaters is required)

Understanding Repeater Guest Logins

When connecting to repeaters, you'll often find they have a guest login with no password. This allows community members to view important repeater information without needing owner authentication.

What you can access with a guest login:

• Owner Information: Contact details and repeater specs to understand the installation and reach out with questions
• Neighbor Nodes: List of nearby repeaters and nodes the repeater can directly hear
• Repeater Status: Signal strength, uptime, and connection statistics
• Network Health: Real-time mesh network performance metrics

Why use a blank guest password? A blank password encourages community participation by making repeater information accessible to all mesh users. This helps troubleshoot connectivity issues, optimize antenna placement, and understand network topology. It's a best practice for community-driven mesh networks like MeshSydney.

Understanding Adverts

Advertisements are how nodes announce their presence on the mesh. Each advert packet contains:

• Public Key — Your node's unique cryptographic identity (32 bytes)
• Timestamp — When the advert was generated (used for routing and deduplication)
• Digital Signature — Cryptographic proof the advert is authentic (64 bytes)
• Node Type — Whether you're a companion, repeater, room server, or sensor
• Name — Your node's display name
• Location — Latitude/longitude (if sharing is enabled)

Advert Type	Frequency	Scope	Effect
Local advert	Every 240 minutes	Directly connected repeaters only	Zero-hop broadcast — announces to immediate neighbors without flooding the network
Flood advert	Every 29 hours	Entire mesh	Network-wide broadcast — every repeater that receives it will rebroadcast
Companion advert	Manual only	When you trigger it	User-initiated flood advert from your companion node

⚠️ Why 29 hours for flood adverts? Each flood advert is rebroadcast by every repeater on the mesh. With many nodes, frequent flood adverts create substantial traffic that can congest the network and delay actual messages.

⚙️ Radio Settings

⚠️ IMPORTANT: Radio Compatibility

NSW has two main mesh networks with different radio presets:

❌ Not interoperable: Narrow and Mid presets cannot communicate with each other directly. Bridge repeaters connect the networks.

📡 The EastMesh Region Map shows the radio preset in use for each region — useful for checking what's in use near you before configuring a new node.

🔶 Australia: Narrow

Uses the Australia (Narrow) MeshCore preset. This is the EastMesh default and remains an important part of the network — it provides the primary link south to Canberra and beyond. It is slightly faster of the two presets for on-air time and its 62.5 kHz bandwidth gives it better interference rejection than Mid's 125 kHz channel, but carries a lower link budget than Mid; CR 4/8 is already at maximum FEC so there is no headroom to trade throughput for better error recovery on a marginal path.

Setting	Value	Explanation
Frequency	916.575 MHz	Australian ISM band (915-928 MHz). The LoRaWAN AU915 channel centred on 916.6 MHz extends down to 916.5375 MHz, placing 916.575 MHz inside that active channel rather than between channels
Bandwidth	62.5 kHz	Noise floor ≈ −120 dBm — 3 dB lower than 125 kHz, 6 dB lower than 250 kHz. A lower noise floor is often seen as an advantage, but link budget is determined by transmit power, noise floor, and processing gain combined, not noise floor alone. The 62.5 kHz channel also reduces multipath tolerance and tightens oscillator accuracy requirements
Spreading Factor (SF)	7	128 chirps/symbol, 2.048 ms symbol time. Minimum decodable SNR: −7.5 dB; receiver sensitivity ~−127 dBm. Roughly 10 dB less processing gain than SF11 — the difference between their SNR thresholds (−7.5 dB vs −17.5 dB)
Coding Rate (CR)	8 (4/8)	Maximum FEC with 100% redundancy. Recovers bit errors, but halves effective data rate

Net result: Receiver sensitivity ~−127 dBm; link budget 154 dB — 5 dB less than Mid. On-air time ~533 ms per 100-byte packet, about 4% faster than Mid. Sub-noise decoding reaches approximately −10 dB SNR in the field. CR 4/8 is the highest coding rate available — there is no room to add more error correction. The frequency sits within the active LoRaWAN 916.6 MHz channel.

🔶 Australia: Mid

The main preset used across Greater Sydney and surrounds. Available in the app under Australia (Mid). Mid runs SF9 at 125 kHz on a frequency that sits entirely below the LoRaWAN AU915 uplink plan — the only gap in the AU ISM band with no active LoRaWAN traffic. The result is 5 dB more link budget than Narrow at almost identical on-air time, with CR 4/5 leaving room to step up error correction on a difficult path if needed.

Setting	Value	Explanation
Frequency	915.075 MHz	Australian ISM band (915-928 MHz). Distinct from Narrow (916.575 MHz). The LoRaWAN AU915 uplink plan begins at 915.2 MHz; Mid's 125 kHz channel occupies 915.0125–915.1375 MHz, entirely below it
Bandwidth	125 kHz	Noise floor ≈ −117 dBm — 3 dB above Narrow. Wider than Narrow's 62.5 kHz so it is more tolerant of multipath and oscillator drift. The LoRaWAN AU915 plan starts above 915.1375 MHz, so Mid's channel fits entirely below it
Spreading Factor (SF)	9	512 chirps/symbol, 4.096 ms symbol time at 125 kHz. Minimum decodable SNR: −12.5 dB; receiver sensitivity ~−129 dBm, 2 dB better than Narrow's −127 dBm. Field observations show decoding down to approximately −16 dB SNR — well below Narrow's ~−10 dB threshold
Coding Rate (CR)	5 (4/5)	25% FEC overhead — one parity bit per four data bits. The lower overhead relative to Narrow's CR 4/8 largely cancels out SF9's longer symbol time, keeping total airtime close to Narrow's. CR can be raised to 4/6, 4/7, or 4/8 on a marginal link; Narrow's CR 4/8 has no equivalent headroom

Net result: Receiver sensitivity ~−129 dBm; link budget 159 dB — 5 dB more than Narrow. On-air time ~554 ms per 100-byte packet — only about 4% more than Narrow's ~533 ms. Sub-noise decoding reaches ~−16 dB SNR in the field versus ~−10 dB for Narrow. Mid's frequency is the furthest from any active LoRaWAN traffic in the AU ISM band.

� Practical note — Mid vs Narrow: The sensitivity and link budget figures are calculated from thermal noise. How they translate in practice depends on what is happening in the local spectrum:

• Mid advantages: Link budget 5 dB better than Narrow at nearly the same on-air time. Frequency sits below the LoRaWAN channel plan — the least contested position in the AU ISM band. SF9 decodes ~6 dB deeper into noise than Narrow's SF7. CR 4/5 has headroom to increase FEC. Better multipath tolerance than Narrow. Main preset used across Greater Sydney and surrounds
• Narrow advantages: Marginally faster airtime than Mid. Better interference rejection — 62.5 kHz bandwidth captures less interference than Mid's 125 kHz channel. CR 4/8 corrects more bit errors per transmission. EastMesh default — large established mesh connecting NSW, VIC, TAS, and south to Canberra and beyond. Essential for bridge repeaters linking south
• Shared spectrum: The AU 915–928 MHz ISM band is shared with smart meters, IoT sensors, and other LoRa devices. Interference density varies significantly by location and can shift the balance between presets

Mid performs better in most Greater Sydney deployments. Narrow remains an important part of the network as the EastMesh default and the primary link connecting south.

🗺️ Region Scoping & IATA Codes

Region scoping gives each repeater control over which flood traffic it forwards, based on the region tag attached to a packet. Without scoping, a repeater rebroadcasts every flood packet it receives, including traffic from distant communities that has nothing to do with your local area. With scoping configured, only packets tagged to an allowed region get forwarded; everything else is silently dropped.

This has a direct impact on mesh health. Every packet a repeater retransmits consumes shared airtime. A Sydney repeater forwarding Melbourne-tagged traffic burns channel time that local messages could have used. Across a busy network with dozens of repeaters, multiple active channels and users spread across hundreds of kilometres, unfiltered rebroadcasting adds congestion, higher latency and dropped messages. Scoping keeps each part of the mesh carrying only the traffic that belongs there.

Region naming format

Regions use a hierarchical, lower-case hyphen-separated format. Pick the tightest scope that covers your intended audience.

<country>-<state>-<iata>

Example: au-nsw-syd

Component	Example	Description
Country	au	Australia
State	nsw	New South Wales
IATA	syd	The 3-letter IATA airport code nearest to the area. Where no airport code fits, the community picks a 3-letter shorthand.

💡 What is an IATA code? IATA codes are the 3-letter airport identifiers assigned to airports worldwide: SYD for Sydney, MEL for Melbourne, and so on. In MeshCore region names they are written lower-case (syd, mel). Use the nearest major airport as a guide, or check the EastMesh Region Map below. Where no suitable airport code exists the community agrees on a 3-letter shorthand instead.

EastMesh Region Map

Use the interactive map to find the correct region code for any location. Click a region on the map or search by name in the sidebar.

🗺️ Open EastMesh Region Map

Note: EastMesh does not allow this map to be embedded on other sites, so it opens in a new tab. Map provided by EastMesh, eastmesh.au. Map data © OpenStreetMap contributors.

NSW region hierarchy

Set every NSW repeater to forward au and au-nsw at minimum, then add whichever city-level scope matches the repeater's physical location.

💡 Cross-border areas: Some areas sit across state borders (e.g. Albury/Wodonga) and use a geography-based 2nd-tier scope like au-hume rather than a single state code.

How transport codes work

When a client or room server sends a flood packet (e.g. a channel message), it attaches a 16-bit transport code to the packet. This code is an HMAC-SHA256 of the packet's payload, keyed with the 16-byte transport key for that channel. The packet is sent as ROUTE_TYPE_TRANSPORT_FLOOD (route type 0x00) which signals to receivers that transport codes are present.

Plain flood packets with no transport code use ROUTE_TYPE_FLOOD (0x01) and are matched by the repeater's wildcard (*) region.

How a repeater matches a region

When a TRANSPORT_FLOOD packet arrives, the repeater loops through its configured regions and computes an expected transport code for each one using that region's key. If the computed code matches the packet's transport code, the packet belongs to that region. If no region matches and the wildcard denies flood, the packet is dropped.

Region hierarchy

The indented tree shown in the region CLI output is organisational only. Each region name produces a completely independent transport key — au-nsw-syd and au-nsw have different SHA-256 hashes with no overlap. There is no parent-chain walk during packet matching.

When a TRANSPORT_FLOOD packet arrives, the repeater checks only its explicitly configured regions and requires an exact transport code match. Allowing au-nsw does not forward packets from au-nsw-syd, au-nsw-gos, or any other child region. Every region you want to forward must be added individually.

For example, a Sydney repeater would typically allow au, au-nsw, and au-nsw-syd as three separate explicit entries. These are additive: au carries national-scoped traffic, au-nsw carries state-scoped traffic, and au-nsw-syd carries Sydney-local traffic. A Central Coast repeater would add au-nsw-gos instead of (or in addition to) au-nsw-syd. New regions are denied by default and must be explicitly allowed before they will forward matching packets.

📻 Channels

Core Channels

Channel	Key	Suggested region scope	Purpose
Public	Public Channel	None (Unscoped)	General chat for all mesh users.
Test	#test	Local region	Connection testing. Bots may auto-reply to test, ping, or path.
Emergency	#emergency	None	Emergency communications only.
Alert	#alert	None	Automatic situation alerts such as fires.

Regional Channels

Scoped to a particular region. These are also listed in each region's popup on the interactive map above.

Note: Check with the NSW Mesh community before creating a new long-lived regional or operational channel.

Channel	Key	Suggested region scope	Purpose
NSW	#nsw	au-nsw	State-wide coordination.
Mid-North Coast	#midnorthcoast		Mid-North Coast conversation and coordination.
Newcastle	#newcastle	au-nsw-ntl	Newcastle & Hunter conversation and coordination.
Sydney	#sydney	au-nsw-syd	Sydney metro conversation and coordination.
Central Coast	#centralcoast	au-nsw-syd	Central Coast conversation and coordination.
Macarthur	#macarthur	au-nsw-syd	Macarthur conversation and coordination.
Nepean	#nepean	au-nsw-syd	Nepean conversation and coordination.
Bathurst	#bathurst	au-nsw-bhs	Bathurst & Central West conversation and coordination.
Illawarra	#illawarra	au-nsw-wol	Illawarra & Wollongong conversation and coordination.
Nowra	#nowra	au-nsw-noa	Nowra and Shoalhaven conversation and coordination.
Wagga Wagga & Riverina	#riverina		Wagga Wagga & Riverina conversation and coordination.
Far South Coast	#farsouthcoast		Far South Coast conversation and coordination.

Misc Channels

Channel	Key	Purpose
Sports	#sports	Sports
Atlas	#atlas	Atlas
NRL	#nrl	Rugby
Ham Radio	#ham	Amateur radio community chat
Recommendations	#recs	Recommendations

Channel Bots

Channel	Key	Suggested region scope	Description / Commands
⚡️₂ RoloJnr	#rolojnr	au-nsw-syd	📚 help ping t test ack path mt wx time signal 🤖 AI: hey rolo query or .query
🌦️ Weather	#weather	Local region	wx location — specific location, or wx to use your node's advert location
🐄 Beef Mesh	#beefmesh	au-nsw-syd	!nodes !narrow !wide !new !bridge !observer !beef !node !emoji
MshBot	#mshbot		MshBot bot
Wolbot	#wolbot	au-nsw-wol	Wollongong bot
Alert	#alert		Alert bot
🔥 FNSW	#FNSW		Fire‑NeWS; fire‑related channel

💡 Tip: All # channel keys are auto-generated from the channel name.

🔒 Privacy Considerations

⚠️ Important: Anything sent via adverts or on public channels (including publicly known # channels) is subject to whatever the receiver chooses to do with the data.

What You Should Know

Messages, locations, and other data sent to the mesh should be considered public information.

Concern	Details
🌐 Internet-accessible tools	Maps and services display packet and location data publicly online
🔓 No guaranteed privacy	Messages are only as private as every person who receives them
💾 Data persistence	Once transmitted, you have no control over storage, sharing, or use
📍 Location precision	Locations are transmitted with high precision

Location Privacy Tip

You can set an approximate location instead of your exact address:

• Close enough for planning and coverage assessment
• Offset enough to provide a privacy buffer
• Consider using a nearby intersection, park, or general area

Best Practices

✅ Do:

• Use Direct Messages for private conversations (with trusted keys)
• Use Private Channels for group privacy (with trusted participants)
• Set approximate locations for your devices

❌ Don't:

• Share sensitive personal information on public channels
• Broadcast your exact home address
• Assume any public message is private

Encryption

Feature	Encryption	Privacy Level
Public channels	AES-256-CTR	🔓 Public (key is shared)
# hashtag channels	AES-256-CTR	🔓 Semi-public (key derived from name)
Private channels	AES-256-CTR	🔒 Private (if key is secret)
Direct messages	AES-256-CTR	🔒 Private (unique per conversation)

💡 MeshCore uses AES-256-CTR encryption. With secured keys and trustworthy recipients, your data is cryptographically protected.

🔧 Repeater Naming & Setup

Naming Convention

Repeater names follow the format [owner identifier] - [location]. The owner identifier is either an emoji or a short name/callsign that represents you as the owner — it appears on all your repeaters so the community knows who runs them.

Emojis make great owner identifiers because they're compact and visually distinctive. Each emoji can be reserved to a single owner on the NSW Repeater Owner Emoji List — check there first to make sure your chosen emoji isn't already taken, and register it to claim it as yours.

Type	Naming	Example
Fixed repeaters	[owner] - [location]	⚡️- Mount Colah, 🌱 - Camperdown, Davo - Centrepoint Tower
Mobile repeaters	Include "mobile" in name	Johns Mobile
Not yet installed	Suffix with "TBA"	⚡️ - TBA, Johns - TBA

Setting Up Your Repeater

Step 1: Flash the Firmware

Flash the repeater using Meshcore firmware flasher.

Step 2: Configure Radio Settings, Name, Location, and Owner Info

Go to Meshcore USB Config and configure:

• Radio Settings: Set the correct frequency, bandwidth, spreading factor, and coding rate (see Radio Settings)
• Name: Give your repeater a meaningful name
• Location: Set your repeater's location for mesh planning purposes
• Owner Information: Include your name/callsign, repeater specs, location type, and off-mesh contact details
• Guest Password: Leave blank to allow other mesh users to query your repeater's status
• Send Advert: After configuring, click the Send Advert button to broadcast your repeater to the mesh

Step 3: ⏰ Sync the Clock — REQUIRED STEP

⚠️ CRITICAL: Your repeater will not work properly without syncing the clock first!

Repeaters default to a clock time of 15 May 2024 on every reboot unless connected to a computer.

Why this matters:

• ❌ Your repeater will be invisible — Other nodes won't hear your adverts correctly
• ❌ Messages may not route properly — Time synchronization is critical for mesh routing
• ❌ Your node appears offline — Shows at bottom of contact lists

How to sync the clock:

1. Log into your repeater via your companion node
2. Go to Settings tab → Scroll to Sync Clock → Tap it
3. Wait for green success notification
4. Tap Advert to tell the repeater to send an advert
5. ✅ Verify: Check that the "Last Heard" time for your repeater is current (not showing May 2024)

💡 Note: You must re-sync the clock after every power cycle or reboot unless your repeater has GPS or remains connected to a computer.

Step 4: Configure Repeater CLI Settings

Once logged in and the clock is synced, configure your repeater via the command line.

How to enter commands:

1. Go to the >_ — Command Line tab
2. Copy each command from your chosen profile
3. Paste and send one command at a time
4. Wait up to 30 seconds for an OK response
5. If no response, resend the command

📺 Video Guide: More about repeaters (11:18)

Step 5: Set Owner Information

Once your repeater is working, update the owner information to help other mesh users plan around your node, understand its type and any limitations it may have, and know who to contact if needed. This information is viewable via guest login.

How to update owner info:

1. Log into your repeater via your companion node
2. Go to the Settings tab (⚙️)
3. Scroll down and tap Owner Info
4. Type your owner information in the dialog box, using Enter to create newlines between each section
5. Tap the ✔️ (tick) button to save
6. Wait for a green success notification confirming the update

What to include in owner info:

Provide essential details that help other users plan their mesh strategy. Include:

• Owner identifier: How to identify you (e.g., "VK2FBAE" or "John Smith")
• Repeater specifications: Antenna type (dBi rating), node model, power source (solar/wired/battery)
• Installation location type: General category like "rooftop", "window", "pole", "street sign", etc. — enough to help with mesh planning but not exact GPS coordinates

Example owner info:

⚡₂ - Overkill (VK2FBAE)
3dbi Alfa antenna, Xiao NRF, solar powered
House rooftop

⚙️ Repeater Configuration Profiles (Sydney Mesh Only)

Choose the profile that matches your repeater's role and position in the Sydney/NSW mesh network.

⚠️ Sydney Specific: These profiles are optimized specifically for the Sydney/NSW 🔷 Narrow mesh. Other regions may use different configurations.

How to Choose Your Profile

Profile	Elevation	Neighbors	Typical Location
⚫ BACKBONE	Variable	1-2	Point-to-point link, dedicated backbone
🔴 CRITICAL	Highest	20+	Hilltop, tower, tall building
🟠 LINK	Mid	15-20	Ridge, elevated position
🟡 STANDARD	Average	5-10	Suburban roof, elevated home
🟢 LOCAL	Low	1-3	Indoor, ground-level, low roof
🔵 MOBILE	Variable	Variable (1-10+)	Vehicle, portable/hiking, bike
🟣 BRIDGE	Variable	Variable	ESP32 node bridging two LoRa segments via ESP-NOW

📝 MeshCore Defaults: txdelay=0.5

All profiles below modify these defaults specifically for the Sydney/NSW mesh network.

⚫ BACKBONE — Ultra-Fast Point-to-Point Link

Role: Dedicated backbone link between two specific high-value nodes

When to use: Your repeater is part of a dedicated point-to-point backbone link connecting two critical infrastructure nodes. Minimal delay, maximum throughput.

Why these values:

• Lowest txdelay (0.25): Fastest possible retransmission for dedicated point-to-point backbone links — below the MeshCore default of 0.5. Mean delay ~219ms at AUS Narrow airtimes

🔴 CRITICAL — Hilltop/Tower Infrastructure

Role: Highest elevation, most neighbors, backbone of the mesh

When to use: Your repeater is on a tall hilltop, tower, or tall building with clear line-of-sight to many other nodes. You can see 20+ neighbors and are a key link in the network backbone.

Why these values:

• Low txdelay (0.3): Highest-reach nodes fire first, covering the most area in a single transmission before the channel fills with retransmissions from lower nodes. Since MeshCore does not cancel pending retransmits, letting the widest-coverage node go early front-loads useful propagation. Mean delay ~263ms at AUS Narrow airtimes

🟠 LINK — Mid-elevation Bridge

Role: Connects critical nodes to local coverage, moderate neighbor count

When to use: Your repeater bridges between tall infrastructure and suburban coverage. You can see some critical nodes and some local nodes (15-20 neighbors typical).

Why these values:

• Moderate-low txdelay (0.6): Fires shortly after CRITICAL nodes have blanketed the area, bridging any remaining gaps between hilltop infrastructure and suburban coverage; mean delay ~525ms at AUS Narrow airtimes

🟡 STANDARD — Suburban Coverage

Role: Average positioning, serves local area, moderate neighbors

When to use: Typical deployment. Your repeater is in an elevated position, serving a localized area. You see 5-10 neighbors.

Why these values:

• Moderate txdelay (1.0): Waits for CRITICAL and LINK nodes to propagate first, then fills in suburban coverage; mean delay ~875ms at AUS Narrow airtimes

🟢 LOCAL — Ground-level/Indoor

Role: Low elevation, few neighbors, serves immediate area

When to use: Indoor repeater, low rooftop, or ground-level installation. You only see 1-3 neighbors and primarily serve your immediate area.

Why these values:

• High txdelay (1.4): Low-elevation nodes with few neighbors defer to higher infrastructure that can cover more area per transmission; mean delay ~1225ms at AUS Narrow airtimes

🔵 MOBILE — Vehicle/Portable Repeater

Role: Moving repeater that extends coverage dynamically as it travels

When to use: Your repeater is mounted in a vehicle, carried while hiking, or otherwise moving through the mesh. Neighbors change constantly as you travel, so the profile balances responsiveness with deference to fixed infrastructure.

Why these values:

• Maximum txdelay (2.0): Defers to fixed repeaters where possible — the mobile node waits the maximum allowed time before retransmitting

🟣 BRIDGE — ESP-NOW Bridge Node

Role: Links two physically separated LoRa mesh segments over ESP-NOW WiFi

When to use: Your ESP32-based node is configured as an ESP-NOW bridge, connecting two LoRa segments that cannot hear each other directly. The node operates as a normal LoRa repeater on its local segment. After it finishes transmitting a packet over LoRa (logTx, the default bridge.pkt.src), it also forwards that packet over ESP-NOW to the peer bridge node. The peer bridge injects the packet into its segment's mesh processing queue with a configurable delay.

Why these values:

• Lowest txdelay (0.25): A bridge is dedicated infrastructure — like BACKBONE, it serves a specific point-to-point link role. Fast LoRa retransmission keeps latency low on the bridged path.
• bridge.delay 1000ms: Packets received over ESP-NOW are held for 1000ms before being injected into the mesh's inbound processing queue. This is a general buffer to prevent immediate processing conflicts. The bridge also maintains its own seen-packet table: a packet marked as seen when it arrived over ESP-NOW will not be re-forwarded back over ESP-NOW when the node later transmits it over LoRa — preventing feedback loops between the two bridge nodes. Range is 0–10000ms.

⚙️ Common Settings (Sydney Mesh Repeaters)

Apply these settings to all Sydney/NSW mesh repeaters regardless of role.

Commands to Apply

Quick Reference

Setting	Value	MeshCore Default	What it does
agc.reset.interval	500	0 (disabled)	AGC reset every 500 seconds (~8 min) to prevent sensitivity drift
multi.acks	1	0 (disabled)	Send redundant ACKs for better delivery reliability
advert.interval	240	0	Local advert every 240 minutes (neighbors only)
flood.advert.interval	29	0 (disabled)	Network-wide advert every 29 hours
guest.password	(blank)	(none)	Blank password allows community members to query repeater status
path.hash.mode	1	0	Sets the size of each repeater's identity stamp in forwarded packets: mode 0 = 1 byte/hop (256 combinations), mode 1 = 2 bytes/hop (65,536 combinations). Mode 1 reduces hash collisions between nodes, improving path-based reply routing accuracy
loop.detect	minimal	off	Rejects flood packets that appear to be looping. At "minimal" with 1-byte path hashes, a packet is rejected if the repeater's own hash already appears 4 times in the path; with 2-byte hashes, 2 times
powersaving	on	off	Power saving mode (light sleep between activity)

📖 Understanding the Settings

This section explains what each setting does and why it matters for mesh performance.

AGC Reset Interval

The Automatic Gain Control (AGC) in LoRa radios adjusts receiver sensitivity automatically. However, AGC can drift in busy environments, reducing sensitivity over time.

⚠️ Known Issue: Loud RF signals can lock up the AGC, preventing the repeater from receiving packets until it's reset.

How it works: The radio periodically re-initializes the receiver to reset AGC to optimal sensitivity. Value is in seconds (internally stored in 4-second increments, so values are rounded to the nearest multiple of 4). AGC is also automatically reset after every transmission.

Multiple Acknowledgments

Controls whether redundant ACKs are sent for direct (point-to-point) messages.

• 1 (enabled): Sends two ACK packets: a "multi-ack" first, then the standard ACK
• 0 (disabled): Sends only a single ACK packet

Redundant ACKs significantly improve delivery confirmation reliability.

Advertisement Intervals

Repeaters periodically announce themselves so other nodes can discover them.

• Local advert (240 min): Zero-hop broadcast to immediate neighbors only
• Flood advert (29 hrs): Network-wide broadcast, rebroadcast by all repeaters

The flood advert interval is intentionally set to a prime number (29 hours). Because a prime interval never divides evenly into 24 hours, the advert naturally rotates through different times of day, ensuring more even coverage and avoiding patterns where adverts always occur at the same time.

Path Hash Mode

When a repeater forwards a flood packet, it stamps a short identity hash (a prefix of its public key) into the packet's path record. This path record is the key feature that makes MeshCore efficient: the destination node can read the exact sequence of repeaters a packet travelled through, and use that record to send replies directly back along the same route without re-flooding the whole network. path.hash.mode controls the byte size of each stamp:

• Mode 0 (default): 1 byte/hop — 256 possible values, up to 64 hops. Prone to hash collisions in larger networks.
• Mode 1 (recommended): 2 bytes/hop — 65,536 possible values, up to 32 hops. Effectively eliminates collisions at Sydney network scale.
• Mode 2: 3 bytes/hop — ~16.7 million possible values, up to 21 hops.

The hash size is encoded in each packet's path flags, so v1.11+ forwarding repeaters read the size from the packet and adapt automatically. The mode only affects packets your node originates — a v1.11+ repeater set to any mode will still forward flood packets regardless of what mode the sender used.

⚠️ Firmware version requirement: Multibyte path hash support was introduced in v1.14.0. Repeaters running pre-v1.14 firmware only ever use 1-byte hashes and cannot correctly interpret path records built with 2-byte hashes. If legacy repeaters are in the network, the path trace will show garbled or ambiguous entries at those hops, defeating the purpose of upgrading to mode 1.

Why collisions corrupt path records:

With only 256 possible 1-byte hash values, two different repeaters in the same network can easily share the same hash. When that happens, the path record becomes ambiguous — a hash in the path could refer to either repeater. The receiving node can no longer reliably reconstruct which specific repeaters the packet passed through, so the path it sees is inaccurate. This means the path command output and any path-based diagnostics will show misleading results, and replies routed along that path may be handed off to the wrong repeater at the collision point.

Mode 1's 2-byte stamps give 65,536 possible values. With the Sydney/NSW network's current repeater count, the probability of any two repeaters sharing a hash is negligible, so path records remain unambiguous and accurately reflect the actual route taken.

Mode	Bytes per hop	Unique identities	Max hops	Practical effect
0 (default)	1	256	64	High collision risk in larger networks. Path records become ambiguous — you can't reliably tell which repeaters a message actually passed through, and path-based replies may be misrouted.
1 (recommended)	2	65,536	32	Collisions negligible at Sydney/NSW scale. Path records accurately identify each hop, so message paths are trustworthy and path-based routing works correctly. 32-hop ceiling is well above practical network depth.
2	3	~16.7 million	21	Virtually zero collision risk. Useful only for very large or dense deployments. Reduced max hop count may limit coverage on wide-area networks.

⚠️ Important: All Sydney/NSW repeaters should run mode 1 so that path records accurately reflect the real route. With mode 0, hash collisions make paths unreliable — you cannot trust what the path command shows, and path-based routing breaks silently.

Loop Detection

Loop detection (loop.detect) protects the mesh from packet storms caused by looping flood packets. This can happen when a misbehaving repeater (e.g. running forked or custom firmware) corrupts a packet's payload and re-forwards it, causing the same packet to circulate repeatedly up to the maximum 64 hops.

How it works: When a flood packet arrives, the repeater inspects the path record for its own identity hash. If the hash appears too many times, the packet is rejected as a likely loop. The threshold depends on both the loop.detect level and the packet's path hash size:

• off: No loop checking (default)
• minimal: Tolerant — allows up to 4 duplicates with 1-byte hashes, 2 with 2-byte, 1 with 3-byte
• moderate: Stricter thresholds than minimal
• strict: Most aggressive rejection — lowest duplicate thresholds

Because minimal already catches clear loop scenarios while being conservative enough to avoid false positives, it is the recommended starting point. This feature can be used independently of the multibyte path hash support — even with legacy 1-byte paths, minimal will reject obvious loops.

💡 Recommended: Set loop.detect minimal on all Sydney/NSW repeaters to mitigate packet storms from misbehaving nodes.

Power Saving Mode

Power saving mode puts the repeater into light sleep between periods of activity to reduce power consumption. The radio wakes on incoming packets or a scheduled timer.

💡 Note: Power saving is handled at the firmware/board level. Use powersaving on to enable it where supported.

🎯 Role-Specific Settings Explained

These settings work together to optimize mesh performance based on your repeater's position and traffic load.

Quick Reference

Setting	Default	Range	What It Controls	Rule of Thumb
txdelay	0.5	0–2.0	Wait before retransmitting floods	Higher = let other nodes go first

Transmission Delay (txdelay)

Controls how long a repeater waits before retransmitting a flood packet it needs to forward.

The Formula:

unit = estimated_airtime × txdelay
delay = random integer drawn uniformly from [0, 5 × unit] ms

For example, with txdelay 1.0 and a 350ms airtime packet (typical for AUS Narrow): unit = 350ms, so the actual delay is any integer from 0 to 1750ms with equal probability — mean ~875ms. This is a continuous uniform distribution, not discrete steps.

AUS Narrow reference (SF7, BW62.5, CR=8): Symbol time = 2.048ms; typical packet airtimes are 250–450ms. Mean delays at that midpoint (~350ms) per profile: BACKBONE 219ms · CRITICAL 263ms · LINK 525ms · STANDARD 875ms · LOCAL 1225ms · MOBILE 1750ms — highest-reach nodes fire first, lowest defer.

Important: MeshCore does not cancel a pending retransmit if it hears another node retransmit the same packet while waiting. Every node that receives a flood packet will transmit it once. The delay only staggers when each node transmits, reducing simultaneous collisions and establishing which path arrives at downstream nodes first.

txdelay	Delay Window	Collision Risk	Propagation Speed
High (2.0)	Wide	✅ Lower	Slower
Low (0.3)	Narrow	⚠️ Higher	Faster