Performance optimisation

MeshCore performance tuning

Default settings work for most deployments, but understanding the trade-offs lets you optimise for your specific British terrain and use case.

Why performance tuning matters

The default MeshCore configuration represents a reasonable compromise for typical scenarios. However, a repeater atop Snowdon has different requirements than a pocket device in central Birmingham.

Performance tuning involves understanding trade-offs. Longer range comes at the cost of slower transmission. Extended battery life means less frequent position updates. There exists no universal optimum.

This guide explains how to tune MeshCore for various British deployment scenarios: maximum range across the Scottish Highlands, fast messaging at festivals, or week-long battery life for mountain rescue equipment.

Performance dimensions

📡

Range

Maximum distance between nodes with reliable communication

âš¡

Speed

Time from sending to message arrival

🔋

Battery life

Duration between charges under typical usage

✅

Reliability

Percentage of messages successfully delivered

📊

Throughput

Volume of traffic the network can sustain

👥

Scalability

Maximum node count before performance degrades

Performance optimisation tips

1. Adjust spreading factor for terrain

Higher spreading factors (SF10-SF12) penetrate buildings and terrain better. Lower values (SF7-SF9) transmit faster but require clearer paths.

Impact: SF12 reaches four times further than SF7, but transmits sixteen times slower. For Pennine hilltop repeaters: SF11-12. For London neighbourhood chat: SF7-8.

2. Balance transmit power

Maximum power is not always optimal. Excessive power can cause receiver overload at close range and drains batteries faster.

Impact: Doubling power (10dBm to 20dBm) extends range modestly whilst tripling battery consumption. Start at 15dBm, increase only if coverage gaps remain.

3. Select appropriate bandwidth

Narrower bandwidth (125 kHz) offers better sensitivity and building penetration. Wider bandwidth (250-500 kHz) enables faster data rates.

Impact: 125 kHz suits most British deployments where range matters more than speed. Use 250 kHz only for high-traffic nodes with assured line-of-sight.

4. Configure hop limits thoughtfully

Each hop adds latency and consumes airtime. Too few hops limit coverage; too many waste resources on already-delivered messages.

Impact: Three hops covers most urban networks and village clusters. Extend to 5-6 only for sparse rural deployments across the Scottish Highlands or Welsh mountains.

5. Tune broadcast intervals

Position and telemetry broadcasts consume airtime proportionally to their frequency. Balance network awareness against channel congestion.

Impact: Battery nodes: 15-30 minute intervals. Solar-powered repeaters: 5 minutes. Moving assets requiring tracking: 1-2 minutes during activity.

6. Monitor channel utilisation

Air utilisation above 10% causes collisions and message loss. The LocalMesh map shows local airtime usage.

Impact: At >15% utilisation: lengthen broadcast intervals, disable non-essential telemetry, or coordinate channel separation with nearby network operators.

Configuration examples

Ready-to-use configurations for common British deployment scenarios:

Maximum range (rural/emergency)

Optimised for links across valleys and moorland where speed matters less than reach:

spreading_factor: SF12
bandwidth: 125 kHz
tx_power: 20 dBm
broadcast_interval: 30 min
hop_limit: 5

Balanced (urban community)

Suitable for town and city deployments where moderate range and reasonable speed both matter:

spreading_factor: SF10
bandwidth: 125 kHz
tx_power: 15 dBm
broadcast_interval: 15 min
hop_limit: 3

Fast messaging (events)

Optimised for festivals, conferences, and gatherings where nodes cluster closely:

spreading_factor: SF7
bandwidth: 250 kHz
tx_power: 10 dBm
broadcast_interval: 5 min
hop_limit: 2

Best practices for optimisation

  • ✓

    Measure before tuning: Record baseline metrics (range, battery life, delivery rate) before making changes.

  • ✓

    Change one parameter at a time: Simultaneous changes obscure which adjustment produced which effect.

  • ✓

    Test in realistic conditions: Laboratory performance rarely matches field reality with buildings, terrain, and interference.

  • ✓

    Monitor after changes: Verify improvements actually materialised in practice, not just theory.

  • ✓

    Document your configuration: Future troubleshooting requires knowing what settings are actually deployed.

  • ✓

    Start conservative: Begin with balanced defaults, optimise only after identifying specific deficiencies.

Frequently asked questions

What matters more: range or speed?

Depends entirely on use case. Emergency networks prioritise range, even if messages take seconds longer. Festival coverage benefits from speed since everyone is within metres. Community networks need balance.

How do I measure optimisation effectiveness?

Track key metrics: SNR (Signal quality), delivery rate (messages successfully received), air utilisation (percentage of time channel is busy), battery runtime (days between charges).

Can different nodes use different configurations?

Partially. Spreading factor and bandwidth must match for communication. Power levels, broadcast intervals, and hop limits can vary. Hilltop repeaters often use higher power than valley devices.

What are the fundamental physical limits?

Theoretical maximum range: ~50km across water or flat terrain. Practical British limits: ~10km rural line-of-sight, ~1-3km urban with buildings. Maximum data rate: ~5.5 kbps. LoRa trades bandwidth for range.

How do I maximise battery life?

Lower transmit power (10dBm), extend broadcast intervals (30-60 minutes), disable Bluetooth when unused, configure aggressive sleep modes. These settings can extend runtime from days to 2-4 weeks.

Optimise your MeshCore network

Performance tuning transforms good coverage into excellent coverage. Whether spanning Welsh valleys or connecting London neighbourhoods, these techniques help you extract maximum value from your mesh deployment.

Start with balanced configuration, then refine based on measured performance