LoRa is useful when a small amount of information needs to travel farther than an ordinary short-range radio link. It does not turn a small board into broadband, and buying a LoRa radio does not by itself give you a working network. The radio, network protocol, application and installation all have separate jobs. Understanding those layers is the most useful first step before buying equipment.
Four names that describe different things
LoRa is a radio modulation technology. LoRaWAN adds a network architecture commonly used for sensors communicating through gateways and network servers. Meshtastic combines compatible firmware, LoRa radios and client applications for messages, positions and selected telemetry. Reticulum is a networking stack that can use LoRa through an RNode interface, but can also use other communication media.
Two devices with LoRa chips are not necessarily compatible. They need compatible radio settings and an agreed packet protocol. A Meshtastic board does not become a LoRaWAN gateway, and an RNode does not automatically participate in a Meshtastic mesh. Some boards can run different firmware at different times; that is a firmware change, not simultaneous interoperability. See the LoRa Alliance introduction for the LoRaWAN architecture.
| Your task | A useful starting point | What still needs planning |
|---|---|---|
| Send a few sensor readings to a backend | LoRaWAN | Gateway coverage, server, device provisioning and downlink needs |
| Exchange short messages between people | Meshtastic | Compatible nodes, shared settings, coverage and power |
| Build messaging or services across different kinds of links | Reticulum | Application, host, interfaces and transport topology |
| Experiment with a custom radio protocol | Direct LoRa development | Framing, security, retries and all network behaviour |
What the radio trades for reach
LoRa uses chirp spread-spectrum modulation. Its settings affect how much information fits into a given amount of airtime and how weak a signal a receiver can recover. Spreading factor, bandwidth and coding rate interact; “longest range” is not a free upgrade.
For a useful calculation, symbol time is 2^SF / bandwidth. At 125 kHz, SF7 gives 1.024 ms per symbol; SF12 gives 32.768 ms. That is a 32-fold difference in symbol duration. It is not a prediction that your complete message takes exactly 32 times longer: packet length, headers, coding and other settings also matter. The example explains why slow settings can occupy the channel for much longer. Semtech’s technical FAQ discusses these radio parameters.
Start with a supported, common preset for the protocol you use. Changing one node to a supposedly better setting can simply make it unable to hear its neighbours. Test a setting change on both ends and record delivery success as well as signal strength.
Airtime is the shared resource
A message costs more than its visible text. There are headers, potentially acknowledgements, retries and relay transmissions. If several nodes retransmit a message, the network spends airtime more than once. A position update every few seconds may be harmless on Wi-Fi but a poor choice on a busy low-bandwidth radio channel.
Consider an illustrative network of 20 sensors, each sending a packet once per minute. If each packet occupies 0.2 seconds, the original transmissions alone total four seconds per minute. That is before collisions, retries or relays. This is a planning example, not a measured LoRa preset or an allowed transmission schedule. It shows why reducing unnecessary reports can help more than increasing transmit power.
Choose reporting intervals from the purpose of the information. A slowly changing water level might need periodic updates plus an event when a threshold is crossed. A rapidly moving vehicle is a different problem. Batch values where the application permits it, and avoid sending unchanged information merely because a timer can.
Why advertised range is not your range
Radio paths depend on terrain, buildings, antenna placement, interference and the receiving installation. A line-of-sight demonstration between high points does not predict coverage from a board behind a concrete wall. Even a visually clear path can have obstructions in the wider region around the direct ray, often discussed as the Fresnel zone.
The useful installation questions are practical: can the antenna see out of the building, is it shielded by metal, is the cable unnecessarily long, and are both antennas mounted with compatible polarisation? Putting a modest antenna in a better location can be more useful than buying a higher-gain antenna and leaving it in the same poor position.
Antenna gain redistributes the radiation pattern; it does not create energy. Check frequency range, connector type and cable loss together. A connector that fits is not evidence that the antenna matches the band. Attach the appropriate antenna before transmitting, and follow the board manufacturer’s instructions.
Read link measurements together
RSSI describes received signal power. SNR describes the signal relative to noise. Neither number alone proves that messages arrive reliably. Different radio configurations have different limits, and a single successful packet says little about an installation through a full day.
Use a small test log: location, antenna position, preset, battery state, number of messages attempted, number received and observed delay. Repeat the route in both directions. A link that works only when you stand still facing one direction has little reserve for real use. Keep a known-good nearby test so you can distinguish a broken configuration from a difficult radio path.
Power budgeting means the whole device
A low-power radio chip does not guarantee a low-power finished node. The processor, voltage regulator, display, GPS, Bluetooth, USB interface and host computer may dominate consumption. Sleeping sensors and always-listening message nodes have very different power budgets.
As an idealised estimate, a 2,000 mAh battery divided by 20 mA average current gives 100 hours. Real runtime is lower or different because of usable capacity, conversion losses, temperature and varying loads. Measure at the actual operating voltage and workload. For solar installations, size for the least favourable period you need to survive, not a sunny afternoon.
A sensible first experiment
- Define one success criterion: for example, short messages between two specific locations with an acceptable delay.
- Select the application and protocol before choosing boards. Check exact board revision and firmware support.
- Verify the radio band, antennas, power supply and USB data cables. A charging-only cable can make a working board appear broken.
- Establish a short-distance baseline with matching settings, then increase distance gradually.
- Change one variable at a time. Move an antenna before changing several firmware settings.
- Test loss of power and reconnection. Record what another person needs to restore the setup.
Frequency permissions, power limits and transmission restrictions depend on the country, band and application. Use the current national rules and protocol region guidance; an online demonstration from another country is not a configuration prescription. These systems should not be your only means of obtaining emergency assistance.
Next steps and help choosing parts
Continue with designing a Meshtastic network or Reticulum, RNode and LXMF. We can help you identify boards, power and connections for a specific project. Tell us the endpoints, terrain, desired message frequency and whether mains power is available. Start with the board selection or contact eBits; LoRa capability alone is not a promise of support for every firmware.
Sources and editorial scope
Technical references: Semtech LoRa FAQ, Semtech LoRa/LoRaWAN overview, Meshtastic radio configuration, and Reticulum interfaces. The numerical examples and test procedure above are explanatory planning exercises, not eBits field-test results. Reviewed 28 September 2026; follow the documentation for the firmware version you install.
