LoRaWAN Device Development: A Practical Guide
LoRaWAN devices are often specified before anyone checks whether LoRaWAN is the right protocol. It frequently is. Sometimes plain point to point LoRa is a better fit and saves considerable complexity.
This guide covers the decisions that determine which, and what each implies for your hardware.
LoRa and LoRaWAN are not the same thing
LoRa is the physical layer, a chirp spread spectrum modulation that trades data rate for range and sensitivity.
LoRaWAN is a network protocol built on top of it, covering addressing, security, adaptive data rate and gateway infrastructure.
You can use LoRa without LoRaWAN. A pair of devices talking directly to each other over LoRa is simpler, has no network server, no join procedure and no duty cycle coordination beyond regional rules.
Choose LoRaWAN when you need many devices, existing gateway coverage, or standard security and key management. Choose point to point when you control both ends and the deployment is closed.
Device classes
Class A. The device transmits, then opens two short receive windows. Lowest power by a wide margin. Downlink only happens after an uplink, so commands may wait hours.
Class B. Adds scheduled receive slots synchronized to gateway beacons. More predictable downlink latency, meaningfully more power.
Class C. Receives continuously except while transmitting. Immediate downlink, but power consumption rules out most battery devices.
Most battery powered products are Class A. If someone asks for immediate remote control on a battery device, that requirement and the battery target are usually in conflict, and it is better to surface that early.
Data rate and airtime
Spreading factor sets the trade. A higher spreading factor gives more range and sensitivity but much longer airtime for the same payload.
The consequences of long airtime:
- More transmit energy per message, which shortens battery life
- More of your allowed duty cycle consumed per message
- Higher chance of collision with other devices
Design your payload to be small. A well packed 12 byte message is a completely different proposition from a 200 byte JSON string, and the difference shows up in both battery life and network capacity.
Duty cycle limits are a design constraint
In some regions, notably across Europe at 868 MHz, duty cycle is legally limited. A common limit is 1 percent, which at high spreading factor can mean waiting tens of seconds between transmissions.
Work out your worst case airtime, apply the regional limit, and confirm your reporting interval is legal before committing to it. This catches many projects late.
Regions differ substantially. A product intended for both Europe and North America needs region specific behaviour, not one configuration.
Joining and key management
OTAA (over the air activation) performs a join procedure and derives session keys dynamically. More secure, handles rejoin cleanly, and is the right default.
ABP (activation by personalization) hard codes session keys. Simpler, but frame counter management becomes your problem and key rotation is impractical.
Use OTAA unless you have a specific reason not to.
Plan how keys get into devices during manufacturing. Doing this properly at production time is much easier than retrofitting a secure provisioning process later.
Hardware implications
Integrated versus separate radio. A part like the STM32WL puts the MCU and sub-GHz radio on one die, saving board area and an SPI link. See our STM32WL LoRa design guide for integrated SoC layout. A separate MCU plus SX126x gives more MCU choice.
Crystal accuracy. LoRaWAN receive windows are timed. A poor crystal or excessive temperature drift causes missed downlinks. A TCXO is usually the right choice.
Antenna. At 868 or 915 MHz a quarter wave is 82 to 87 mm. Still large for compact products, though easier than 433 MHz. Ground plane length remains the dominant factor in efficiency.
Power. Transmit at high spreading factor draws substantial current for a relatively long time. Size the battery and the bulk capacitance for that pulse. See GPS tracker hardware design for energy budget methodologies.
Certification
Beyond the usual emissions requirements, LoRaWAN devices intended to carry the certification mark must pass LoRa Alliance testing. Budget time and cost for it if the mark matters to your market.
Regional parameters differ enough that you should plan to test in each target region rather than assuming one result transfers.
Common mistakes
- Specifying Class C on a battery device
- Designing the payload after the reporting interval, then discovering the airtime is too long
- Using ABP and then struggling with frame counters after a power cycle
- Ignoring duty cycle limits until certification
- Assuming public gateway coverage exists at the deployment site without checking
Getting a LoRaWAN product to market
Most of the difficulty in LoRaWAN devices sits in the interaction between payload size, airtime, duty cycle and battery life. Those four are one problem, not four.
SRQ Robotics designs sub-GHz devices including LoRaWAN and point to point LoRa nodes, with power budgets validated against real airtime rather than nominal figures. Explore our Embedded & IoT services or contact us if you need a node that meets its reporting interval and its battery target at the same time.