The most common LoRa selection mistake is choosing the radio first. A module can have excellent sensitivity and still be the wrong part when the project needs frequent downlinks, a different regional channel plan, an existing host MCU, or a real multi-channel LoRaWAN gateway.
A practical selection order
Use this order for your new LoRa project:
1. Define payload, interval, downlink and latency.
2. Choose point to point, LoRaWAN, mesh or another physical layer.
3. Lock the regional plan and deployment countries.
4. Calculate airtime, link budget and battery duty cycle.
5. Decide whether the application MCU is external, integrated or multi-radio.
6. Confirm the firmware stack on the chosen host and radio.
7. Select the antenna and gateway architecture.
8. Test the complete link in the final enclosure.
9. Review certification and production supply before layout release.
Following this sequence turns module selection into an engineering decision. Sensitivity, transmit power and price still matter, but they are evaluated against the actual traffic, software and deployment rather than treated as isolated headline specifications.
Define the traffic before comparing radios
Write down these five values before you open a module datasheet:
1. Application payload in bytes
2. Normal and worst-case message interval
3. Required downlink frequency and latency
4. Expected operating region
5. Battery, supply and enclosure constraints
These values quickly remove unsuitable architectures. A soil sensor sending 12 bytes every 15 minutes has a very different radio workload from a handheld mesh device that relays messages, maintains a Bluetooth connection and updates a display. Both may use LoRa modulation, but they should not be designed around the same MCU, power budget or firmware.
The network model should also be explicit.
| Network model | Use it when | Main design consequence |
|---|---|---|
| Raw LoRa point to point | You control both ends and need a small private link | You must define addressing, acknowledgements, retries, security and channel access |
| LoRaWAN | Many end devices must report through gateways to a network server | The device, gateway and server must use the same regional parameters and channel plan |
| Meshtastic or another mesh stack | Nodes must relay messages without fixed gateway coverage | Every relay spends airtime and energy receiving and forwarding traffic |
| Higher rate proprietary link | The payload cannot fit a low-duty-cycle telemetry model | Consider FLRC, FSK or another radio before forcing large transfers through slow LoRa settings |
Calculate airtime before range
Before comparing radio sensitivity or estimated range, calculate how long each packet occupies the channel. LoRa airtime is determined by payload length, spreading factor, bandwidth, coding rate, preamble length, header mode, CRC and low-data-rate optimization.
For a 20-byte LoRa PHY payload using 125 kHz bandwidth, coding rate 4/5, an eight-symbol preamble, explicit header and payload CRC, the calculated airtime is:
| Setting | Symbol time | Payload symbols | Total airtime |
|---|---|---|---|
| SF7 | 1.024 ms | 43 | 56.576 ms |
| SF12 with LDRO | 32.768 ms | 28 | 1,318.912 ms |
Although the SF12 packet uses fewer payload symbols in this example, each SF12 symbol lasts 32 times longer than an SF7 symbol. The complete SF12 packet therefore occupies the channel for approximately 23.3 times longer.
At 125 mA transmit current, sending one packet every 600 seconds contributes approximately:
This calculation covers only the transmit phase. It does not include MCU operation, sensing, startup time, receive windows or regulator losses.
Set a link budget with losses included
The basic link-budget expression is:
For a complete understanding of the loss calculation formula, please refer to https://www.mathworks.com/discovery/link-budget.html
In a rough sense, a +14 dBm transmitter, two 0 dBi antennas, 2 dB of total feed and implementation loss, and a receiver sensitivity of -126 dBm provide 138 dB of theoretical link budget. This is not a distance guarantee. Enclosure absorption, antenna orientation, ground clearance, vegetation, buildings, interference and installation height consume that budget.
Use sensitivity at the planned spreading factor and bandwidth. Quoting the best sensitivity number from SF12 while planning to operate at SF7 produces an invalid range estimate. Reserve margin for the actual environment, then verify it with packet-error-rate tests at the final antenna position.
Decide where the application processor lives
LoRa modules fall into three practical hardware arrangements.
External host with a radio transceiver
A radio-only module gives an existing MCU direct control over the LoRa transceiver through SPI. This is useful when the product already has a qualified processor, when the application needs a particular RTOS or security architecture, or when Bluetooth, Wi-Fi, a display or substantial local processing already exists elsewhere on the board.
The Wio-SX1262 is one example. It covers 862 to 930 MHz, uses an SX1262 with SPI and DIO control, accepts 1.8 to 3.6 V, draws 7.6 mA in receive mode and up to 125 mA at +22 dBm transmit power, and lists -136.73 dBm sensitivity. The IPEX version includes a TCXO and external antenna connector. DigiKey lists manufacturer part number 114993390 as:
- 1597-114993390CT-ND for cut tape
- 1597-114993390DKR-ND for Digi-Reel
- 1597-114993390TR-ND for tape and reel
This arrangement preserves host flexibility, but the PCB must provide the required SPI, reset, BUSY and interrupt connections. Firmware must also control the radio state machine and the selected protocol.
MCU and radio in one module
An integrated wireless MCU reduces the number of major ICs and can remove the SPI boundary between the application and radio. It suits compact LoRaWAN sensors whose processing and peripheral needs fit the onboard MCU.
Wio-E5 integrates an STM32WLE5JC, an Arm Cortex-M4 running at up to 48 MHz with 256 KB of flash and 64 KB of SRAM. The 12 x 12 x 2.5 mm module draws 2.1 microamps in its documented sleep mode, about 6.7 mA in receive mode and about 111 mA when transmitting at +22 dBm at 868 MHz. Its typical sensitivity at 868 MHz, SF12 and 125 kHz bandwidth is -135 dBm. The factory firmware exposes LoRaWAN through AT commands, while a custom STM32CubeWL application can use the MCU directly.
DigiKey lists manufacturer part number 317990829 as:
- 1597-317990829CT-ND for cut tape
- 1597-317990829DKR-ND for Digi-Reel
- 1597-317990829TR-ND for tape and reel
There is an important firmware decision here. The factory image uses readout protection. Removing that protection to load custom firmware performs a mass erase, and the factory AT firmware cannot simply be recovered from the device. A team should choose the AT-command path or the custom STM32 path before building its manufacturing and service process.
Application MCU with several radios
Products that need LoRa plus local commissioning, a phone connection or Wi-Fi backhaul may benefit from a module that integrates the application MCU and several wireless interfaces. Wio-S3 combines an ESP32-S3R8 and SX1262 with 16 MB flash, 8 MB PSRAM, 2.4 GHz Wi-Fi and Bluetooth LE 5.0. It is a reasonable fit for a powered controller, handheld device or gateway-adjacent node where memory and local connectivity matter. A long-life sensor should still be evaluated from its complete sleep and wake behavior rather than from the SX1262 radio figures alone.
Wio-S3 was not listed on DigiKey when this article was prepared, so no DigiKey part number is included.
Use specialized radios only when the requirement is real
Multi-band and high-rate radios solve specific problems. They also expand the RF, antenna and firmware work.
Wio-LR1121 is relevant when one design must cover sub-GHz, 2.4 GHz ISM and S-band operation, or when LR-FHSS and LoRa Edge positioning functions are part of the product plan. Its 17 x 12 x 2.6 mm package still requires a host MCU. A regional sensor that only needs EU868 or US915 usually gains little from adding these bands.
Wio-LR2021 covers 863 to 928 MHz and 2.4 GHz and supports LoRa, LR-FHSS, FSK-family modes and FLRC. The documented FLRC rate reaches 2.6 Mbps. The module measures 17.07 x 10.42 x 2.8 mm, draws 583 nA in deep sleep, 8.19 mA in sub-GHz LoRa receive mode at SF12 and 125 kHz, and about 116 to 119.4 mA when transmitting at +22 dBm in the 868 and 915 MHz bands. It is useful when a product needs occasional higher-rate transfers or one radio architecture across several physical layers. Ordinary low-rate telemetry does not need this additional capability.
Neither Wio-LR1121 nor Wio-LR2021 had a DigiKey listing when this article was prepared.
Choose the firmware stack with the hardware
A radio is only useful when the required driver and protocol stack fit the selected MCU and development environment. Check this before laying out the PCB.
| Project path | Practical software starting point |
|---|---|
| Arduino or PlatformIO raw LoRa | RadioLib with an SX1262, LR11x0, LR2021 or another supported radio |
| Arduino or PlatformIO LoRaWAN prototype | RadioLib LoRaWAN examples and regional configuration |
| STM32WL production node | STM32CubeWL and its LoRaWAN end-node examples |
| New Semtech LoRaWAN design on a supported transceiver | LoRa Basics Modem |
| Meshtastic device | Upstream Meshtastic firmware and a supported board definition |
| SX1302 gateway | Semtech gateway HAL plus Basic Station or the packet-forwarder path required by the network server |
RadioLib is particularly useful during module evaluation because one API supports the SX126x family, STM32WL, LR11x0 and LR2021, among other radios. Its SX126x settings example exposes the parameters engineers actually need to confirm: chip-select and interrupt pins, BUSY, carrier frequency, bandwidth, spreading factor, coding rate, sync word, output power, preamble length, TCXO voltage and RF-switch behavior.
For new LoRaWAN products, note that Semtech has moved LoRaMac-node into maintenance mode and recommends LoRa Basics Modem for new designs. LoRa Basics Modem implements LoRaWAN L2 1.0.4 and includes supported transceivers such as SX1261, SX1262, SX1268 and the LR11xx family. Its porting guide also states the MCU resources it expects, including nonvolatile storage, a timer and at least 40 KB of flash for a Class A single-region build.
Do not assume that a library supporting the silicon automatically supports every module wiring arrangement. TCXO voltage, RF-switch control, BUSY handling and interrupt routing still have to match the module schematic.
Treat the regional plan as part of the product definition
EU868, US915, AU915 and AS923 are more than frequency labels. They define channel sets, data rates, receive-window behavior and regional limits. The following items must agree:
- Radio front end and antenna band
- End-device regional plan
- Gateway channel configuration
- Network-server regional plan and sub-band selection
- Conducted power, antenna gain and permitted EIRP
- Duty-cycle, dwell-time and channel-use requirements
In the next article, we will explain how the duty cycle and channel usage requirements in LoRa affect the design.
A US915 device can transmit within the broad frequency capability of many 868 to 915 MHz modules and still fail to join because its sub-band or receive-window configuration does not match the gateway and network server. Use the current LoRa Alliance Regional Parameters document as the source of truth, then confirm the regulations for the countries where the product will ship.
Module certification can reduce RF approval work, but it does not make every finished device compliant. The final antenna, power level, layout, enclosure, labeling and host product remain part of the compliance assessment.
Design the antenna and enclosure together
An antenna should be selected as part of the mechanical design, not added after the PCB is finished.
For an IPEX module, we check the antenna’s operating band, impedance, cable loss, connector orientation and mechanical strain relief. For an SMT antenna, preserve its required keep-out area and ground-plane dimensions. In both cases, measure the antenna in the final enclosure with the battery, display, cables and mounting hardware installed.
Calculate effective isotropic radiated power using conducted power, antenna gain and feed losses. Setting the radio to +22 dBm does not mean the finished product is allowed to radiate +22 dBm in every region or with every antenna.
For prototypes, use the same antenna type intended for the product. A development board on a desk with a large external antenna can hide the loss introduced later by a compact enclosure.
Size the power path for transmit peaks
The regulator and local decoupling must support peak transmit current without pulling the module below its supply limit. Average battery current does not answer this question.
Test the supply at maximum configured transmit power while recording voltage at the module pins. Repeat at the lowest battery voltage and at temperature limits. A node that resets only during a long packet or a cold battery test often has a power-path problem rather than a radio problem.
For battery-life estimates, separate the operating cycle into sensing, MCU processing, transmit, receive windows and sleep. Calculate each phase from measured current and duration. This also shows whether reducing spreading factor, shortening payloads or avoiding confirmed uplinks will save more energy than changing the nominal sleep current by one microamp.
Use a concentrator for a LoRaWAN gateway
An SX1262-class transceiver can receive one configured channel and data-rate combination at a time. It is suitable for an end node or a controlled point-to-point receiver. It is not a replacement for a production LoRaWAN gateway concentrator.
An SX1302-based gateway can receive eight 125 kHz LoRa channels across multiple spreading factors, with dedicated LoRa demodulation paths plus 125, 250 and 500 kHz and FSK reception. A module such as WM1302 belongs on the gateway side of the design, paired with a Linux host, packet forwarder or LoRa Basics Station, backhaul and a network server.
This distinction prevents a common prototype trap: a single-channel receiver may appear to work with one manually configured node, then miss devices that use other channels or data rates.
Validate the complete link before freezing the PCB
A useful validation plan produces measurements that map directly to the deployment.
1. Verify frequency error, output power and occupied bandwidth on the bench.
2. Measure supply droop and current at maximum transmit power.
3. Run packet-error-rate tests at every planned data rate, not only the longest-range setting.
4. Measure the antenna in the final enclosure.
5. Confirm join, uplink, receive windows and downlink on the exact regional channel plan.
6. Test the gateway at the intended height, location and backhaul connection.
7. Repeat the field route with the finished enclosure and antenna orientation.
8. Run pre-compliance checks before ordering production quantities.
Log firmware version, region, frequency, bandwidth, spreading factor, coding rate, transmit power, payload length, antenna and gateway configuration with every test. Without that record, range results are difficult to reproduce or compare.
I hope this article can be of help to those in need. If you are interested in such topics and would like to know more about related directions, please let us know.