This page answers common MeshCore questions for SA:MUG users and repeater operators. It is intended as a quick local guide, not a replacement for the upstream MeshCore documentation.
Useful links:
MeshCore is a LoRa-based messaging and routing system for off-grid text communication. It can run on supported LoRa devices as companion/client nodes, repeaters, room servers, and standalone devices such as T-Deck style hardware.
MeshCore is not just Meshtastic with different settings. It has its own firmware, clients, routing behaviour, packet formats, and repeater model.
No. MeshCore and Meshtastic are separate systems and do not talk to each other over LoRa.
They may use similar LoRa hardware and similar frequency bands, but the firmware and over-the-air protocols are different.
For most users:
See Start Here for the short setup path.
It depends on the role of the device:
| Role | Firmware type | Use when |
|---|---|---|
| Normal user node | Companion | You want to send/receive messages using a phone or web app |
| Coverage node | Repeater | You want to extend the mesh from a fixed site |
| Message store | Room server | You want a BBS/mailbox-style shared message point |
| Standalone handheld | T-Deck / Ultra-style firmware | You want a self-contained device without a phone |
If unsure, start with companion firmware.
Not always.
If there are already repeaters covering your area, a companion node may be enough. A badly placed repeater can add noise, duplicate traffic, or confusion without improving coverage.
A repeater is most useful when it is:
See Getting started: Repeater, or use Repeater settings profiles for detailed settings guidance.
No, not in the same way as a MeshCore repeater. For extending network coverage, use repeater firmware on a suitable device.
A room server is a shared message store. It is useful for mailbox/BBS-style communication where users may come back later and retrieve messages.
It is different from a repeater. For best results, run repeater and room server roles on separate devices.
An advert is how a MeshCore node announces itself. It can include identity information such as name, position, and public key.
There are two broad advert styles:
Common causes:
First checks:
Likely causes include:
Try a simple line-of-sight test with another local user before changing advanced settings.
RSSI is received signal strength. SNR is signal-to-noise ratio.
For LoRa, SNR is often more useful than raw RSSI. A strong RSSI with poor SNR can still be bad if the noise floor is high.
A MeshCore repeater forwards MeshCore packets to help traffic reach further nodes. It does not simply retransmit every packet forever. MeshCore uses routing, path information, duplicate suppression, and forwarding rules.
A good repeater site is usually:
A high site is not automatically good if it creates too much duplicate traffic or hears too many marginal paths.
For SA:MUG-style naming, use:
SA-<Location>-<Role>##
Examples:
SA-MtBonython-CORE01
SA-Lobethal-DIST01
SA-Blackwood-EDGE01
SA-Example-RPT01
See Repeater settings profiles for details.
| Role | Meaning |
|---|---|
| CORE | High-value wide-area or backbone repeater |
| DIST | Distribution or coverage-shaping repeater |
| EDGE | Small local infill repeater |
| RPT | Generic repeater when the role is not clear |
Start with Repeater settings profiles.
Do not copy settings blindly between sites. A hilltop, valley-fill, and house-roof node should not necessarily use the same forwarding and delay settings.
For nRF52-based repeaters, flashing the Oltaco DFU Bootloader is a good future-proofing step before final deployment:
https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX
Do this before any format/erase step, then format/erase if needed, then flash the MeshCore repeater firmware. This can make future over-the-air updates easier, which matters if the repeater will be installed somewhere hard to reach.
Short version:
rxdelay can delay weak received flood packets so stronger copies are processed first.txdelay adds a random delay before flood retransmission to reduce collisions.direct.txdelay is similar, but for direct/routed retransmits.Important warning: do not use rxdelay values between 0 and 1. Use 0 to disable it, or values greater than 1 for the intended behaviour.
For the full explanation, see MeshCore rxdelay and txdelay calculations.
In the current repeater settings page, error flag 2 is documented as CAD busy timeout behaviour. It means the repeater had a packet queued to transmit, but the radio/channel appeared busy long enough that MeshCore forced the pending transmit.
See Repeater settings profiles for the detailed note.
These are LoRa modem settings:
They affect range, airtime, reliability, and interference behaviour. All nodes in the same local mesh need compatible radio settings to hear each other.
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. For other regions, use the settings agreed by your local MeshCore group and permitted in your region.
Usually no.
Start with known-good local settings. Change one thing at a time, record what changed, and test before treating it as a recommendation for others.
Try:
Try:
Check physical and RF basics before firmware tuning:
Write down what changed, then return to known-good local settings. If asking for help, include: