MeshCore Learning

Tuning Repeater Settings

Once a repeater is online and you have confirmed it is useful, a few settings can improve reliability and reduce unnecessary collisions or airtime. Most of these are adjusted through the repeater command line (serial or remote) and take effect after they are set. Always make one change at a time and retest with path traces.

What Is a Backbone Site?

A backbone site (sometimes called a high-profile or main repeater) is a well-placed, higher-elevation repeater whose primary job is to link larger areas together. It typically sits on a ridge, hilltop, tall building, or tower where it can hear and be heard across multiple valleys, towns, or districts.

Backbone sites differ from local (low-profile) repeaters in role and configuration:

  • They carry broader regions so useful traffic can cross between separated areas.
  • They are often given higher TX/RX delay values so they defer slightly and let more local repeaters handle nearby traffic first.
  • Their value comes from connecting groups of users or lower sites that cannot reach each other directly, not from serving only a small neighborhood.

Any MeshCore repeater can serve as a backbone site if it is located and configured for wide-area linking. The valley illustration on the Understanding Repeaters page shows a classic example: one ridge-top repeater covering two valleys that cannot communicate directly.

TX and RX Timing Settings

When several repeaters hear the same packet, they need a way to avoid transmitting at exactly the same moment. MeshCore uses short, randomized delays for this purpose. The three most useful commands are:

  • set txdelay <factor> — Controls the random wait before retransmitting a flood packet. Higher values make the repeater more likely to defer to others. Typical range is 0.0–2.0 (default is usually 0.5).
  • set direct.txdelay <factor> — Same idea, but for direct (path-routed) packets. Usually set lower than txdelay because fewer stations compete for these.
  • set rxdelay <base> — Experimental delay applied to received flood packets based on signal quality. Stronger signals are processed sooner; weaker ones wait. A value of 3 is a common starting point; 0 disables it.

Example: backbone / high-profile site

set txdelay 1.8
set direct.txdelay 1.2
set rxdelay 3

Example: local / low-profile site

set txdelay 0.6
set direct.txdelay 0.3
set rxdelay 3

Example: confirm the settings

get txdelay
get direct.txdelay
get rxdelay

Community experience suggests different values depending on the role of the site:

  • Backbone / high-profile sites (wide coverage, many neighbors): higher delays so they defer more often and reduce collisions.
  • Local / low-profile sites (small coverage area): lower delays so they can serve nearby users promptly.

After changing any of these, retest with path traces. Too high a delay can add noticeable latency; too low can increase collisions in a busy area.

Region Configuration

Regions remain one of the most effective ways to control how much traffic a repeater forwards. Review the Regions and Region Scopes lesson for the full explanation. In short:

  • Add only the region names the site should actually carry (region put <name> [parent]).
  • On current firmware, region put usually enables flood forwarding automatically; older firmware may still need region allowf.
  • Finish with region save.

A backbone site typically carries broader regions (for example us or us-pa) so it can link separated areas. A low-profile repeater that carries only a tight local region will forward far less unnecessary flood traffic. This reduces airtime contention for nearby backbone sites.

Other Practical Settings

  • TX power — set tx <dBm>. Higher power does not compensate for a poor antenna location. Use the lowest power that still provides reliable links, especially on boards with external amplifiers.
  • Duty cycle / airtime factor — set dutycycle or set af (depending on firmware). Keeps the station within regulatory limits and prevents it from dominating the channel.
  • Path hash mode — set path.hash.mode. Larger values reduce ID collisions on bigger networks but require all stations to support the same mode.
  • Advertisement interval — set advert.interval <minutes>. Controls how often the repeater sends its advertisement. A longer interval (for example 120–240) reduces unnecessary traffic on stable sites; a shorter interval helps a new or relocated site become known more quickly.
  • Maximum flood hops — set flood.max <number>. Limits how far flood packets may travel. A modest value (often 8–16) keeps traffic from propagating farther than needed while still allowing useful multi-hop paths.
  • Repeat enable/disable — set repeat on or set repeat off. Useful for temporarily silencing a repeater during testing without removing power or changing other settings. Remember to turn it back on when finished.

Board-Specific Notes

  • ESP32-based boards (Heltec V3, T-Beam, etc.) — These can benefit from powersaving on on solar or battery sites. The board sleeps between transmissions, lowering average current. Note that it typically begins sleeping a couple of minutes after boot.
  • nRF52 / RAK WisBlock boards — These are already efficient sleepers. The powersaving command is usually unnecessary and may not apply. Focus on antenna, power supply, and the timing settings above.
  • Boards with external power amplifiers — Do not raise TX power beyond the board’s designed level; the amplifier multiplies the set value and can exceed legal limits or damage the radio. Start with the manufacturer’s recommended setting.
  • Battery voltage calibration — Some boards support set adc.multiplier to fine-tune battery readings. This is board-specific and not available on every model.

A Simple Tuning Sequence

  1. Confirm the repeater is useful with path traces (see the Monitoring lesson).
  2. Decide whether the site is acting as a backbone (wide linking) or local repeater and set TX/RX delays accordingly.
  3. Review and tighten region settings so the repeater only forwards traffic that benefits from it.
  4. Retest with path traces and, if possible, ask nearby users whether reliability has improved.
  5. If problems remain, revisit antenna placement or consider whether the site is still needed.

Tuning is iterative. Small, tested changes almost always outperform large untested ones.

← Previous: Troubleshooting Common Problems

Continue to: Managing Traffic and Congestion →

Was this material helpful? Leave feedback or suggest a correction.