This page is for setting up a MeshCore repeater: a fixed LoRa node that helps forward MeshCore traffic and improve coverage.
A repeater should be deployed to solve a real coverage problem. If this is your first MeshCore device, start with a companion node first: Getting started with a MeshCore companion node.
Useful links:
A MeshCore repeater forwards MeshCore packets to help traffic reach nodes that cannot hear each other directly.
It is not a normal user node, and it is not just a companion node left on a hill. It runs repeater firmware and should be configured for the role it plays in the network.
A repeater can improve a mesh when it is well placed and well configured. A poor repeater can make the mesh noisier without improving useful coverage.
Deploy a repeater when most of these are true:
If you are unsure, ask in the local group first. In many cases, a companion node or a better antenna position is a better first step.
Use the role that best describes the site:
| Role | Use for | Typical name part |
|---|---|---|
| Core | High, wide-area, backbone-style sites | CORE |
| Distribution | Coverage shaping, valley fill, secondary ridge, reflector-style sites | DIST |
| Edge / infill | House roof, small local fill, suburb edge, local shadow pocket | EDGE |
| Generic repeater | When the role is not clear yet | RPT |
For detailed settings profiles, see Repeater settings profiles.
Current South Australian MeshCore radio settings are:
| Setting | Value |
|---|---|
| Frequency | 923.125 MHz |
| Bandwidth | 62.5 kHz |
| Spreading factor | 8 |
| Coding rate | 8 |
Western Australia and Queensland use the same settings.
Before putting a repeater on air, consider:
EIRP depends on transmitter power, feedline loss, and antenna gain. Do not assume that a higher gain antenna is always legal or helpful.
Before flashing or installing:
For first testing, keep the setup simple and accessible. Do not install it somewhere difficult to reach until firmware, settings, and RF behaviour have been checked.
For repeaters using nRF52-based devices, it is a good idea to flash the Oltaco DFU Bootloader before final deployment:
https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX
This is useful future-proofing for over-the-air firmware updates. A repeater may be easy to reach while it is on the bench, but much harder to access once it is installed on a roof, mast, hill, or remote site.
Recommended order:
Do this before formatting/flashing the repeater firmware and before installing the repeater somewhere difficult to access.
Recommended SA:MUG-style repeater name format:
SA-<Location>-<Role>##
Examples:
SA-MtBonython-CORE01
SA-Lobethal-DIST01
SA-Blackwood-EDGE01
SA-Example-RPT01
Keep names short, stable, ASCII, and easy to recognise.
The detailed profile page has full copy-paste blocks. For a first setup, the important idea is:
get commandsUse the full command block from Repeater settings profiles, not a half-remembered snippet.
At minimum, verify these afterwards:
get freq
get bw
get sf
get cr
get repeat
get advert.interval
get flood.advert.interval
get flood.max
get flood.max.unscoped
get flood.max.advert
get path.hash.mode
get loop.detect
get txdelay
get direct.txdelay
get rxdelay
get multi.acks
| Site type | Suggested starting profile |
|---|---|
| High wide-area site | Core |
| Valley-facing or coverage-shaping site | Distribution |
| House roof or local fill | Edge / infill |
| Unsure | Generic or conservative distribution/edge settings |
Start conservative. It is easier to increase forwarding later than to debug a noisy repeater that was too aggressive from day one.
Do not tune rxdelay, txdelay, or direct.txdelay blindly.
Short version:
txdelay spreads retransmit timing to reduce collisions.direct.txdelay does the same for direct/routed retransmits and is usually lower.rxdelay delays weak received flood packets so stronger copies can be processed first.rxdelay 0 to disable it.rxdelay values greater than 1 for the intended behaviour.rxdelay values between 0 and 1; they invert the behaviour.For the detailed explanation, see rxdelay and txdelay calculations.
If a site is noisy or high enough to hear a lot of RF activity, be careful with interference threshold settings.
stats-radio can report values such as:
noise_floorlast_rssilast_snrIf int.thresh is non-zero, the radio treats the channel as active/interfered when current RSSI is greater than the measured noise floor plus int.thresh.
For example, int.thresh 10 means the channel may be treated as active if current RSSI is more than about 10 dB above the measured noise floor.
Do not set int.thresh too low on a noisy/high site. The repeater may keep seeing the channel as active and delay or fail transmissions.
Bench test first:
Then short-range RF test:
After the repeater is installed:
Useful checks:
stats-core
stats-radio
If available, compare before/after reports from nearby users rather than relying on a single test packet.
Avoid these early mistakes:
rxdelay values between 0 and 1.For each repeater, record:
This makes future tuning and troubleshooting much easier.
If the repeater is working and field-tested, share what role it serves and what coverage changed so the community can tune the wider mesh around real behaviour.