Dec . 2025
When selecting a LoRa module, common mistakes include not only misreading parameters but also buying the wrong product type. Many people want to achieve "ultra-long range low power wireless" but end up buying a LoRaWAN node when they intended for a point-to-point direct connection, or buying a LoRa transceiver module when they wanted to access a city-level public network directly. These situations all fall under choosing the wrong product type. Below we will clarify the key points in the order of "First determine the direction, then select the chip, then check the specifications, and finally implementation".
LoRa is a physical layer modulation technology. You can understand it as the layer that handles "how radio signals are transmitted and received". LoRaWAN is a complete set of network protocols and ecosystem defined on top of LoRa, including network joining, encryption, gateway forwarding, network servers, device management, and more.
If you have not yet decided whether to use LoRaWAN, making a simple judgment is enough.
If you want direct connection between devices, to define your own protocol, no monthly fees, and a system structure that is as simple as possible, then in most cases selecting "Pure LoRa" (which means P2P or private protocol solutions) is more suitable. Common forms include SPI/UART LoRa transceiver modules or serial pass-through modules with an MCU.
If you want cross-district or even cross-city coverage, hope to reuse existing gateways and network servers, and want more standardized device management, then consider LoRaWAN terminals and LoRaWAN gateways. You should also confirm in advance whether there is an available public network in your area or if you need to build your own private LoRaWAN network.
Let us make the problem concrete.
If your project is more like "remote control, sensors directly connected to a gateway, or a self-built link within a park", often a single point-to-point link or a star private network can solve it. In this case, a pure LoRa module (SPI/UART) is the most cost-effective choice because you do not need to pay continuous fees for a public network or platform, nor do you need to be constrained by LoRaWAN regional parameters and network joining restrictions.
If you need "city-wide accessibility" and your nodes are scattered, and you do not want to maintain base stations yourself, only then do you truly need public network or large-scale LoRaWAN coverage. But note that the convenience of LoRaWAN comes from the ecosystem, which requires adhering to regional parameters and network-side rules.
The chip model determines the power consumption, sensitivity, transmission capability, cost, and future migration possibilities you can achieve. Below we clarify the positioning based on their iteration relationship.
The core reason why the SX127x series has remained active in the market for a long time is not that it is the strongest, but that its documentation and code resources are very abundant. Many historical projects, open-source libraries, and tutorials are written around it. For maintaining legacy projects, quick prototyping, or replicating old devices, it is still very convenient.
Of course, the cost is also obvious.
Under the same conditions, the power consumption performance of the SX127x is generally not as good as the new generation. Taking typical receive current as an example, the SX1276 typical receive current is in the order of about 10 mA (this changes with modes and configurations).
The registers and driver model are somewhat "traditional", so software adaptation will be more laborious when migrating to new platforms later.
If you are starting to build a battery-powered device for mass production now, the SX1262 is often the comprehensive optimal choice. Its advantages are mainly reflected in two points.
It has strong transmission capability, reaching up to +22 dBm (specifically depending on the device and external matching design).
The receive current is significantly reduced, with a typical value about 4–5 mA. This is much lower compared to common configurations of the SX127x, which directly extends battery life.
This is why for many cases of "same battery, same reporting cycle", switching to the SX1262 platform results in noticeably longer battery life.
The LLCC68 can be understood as a "budget-friendlier LoRa chip with an architecture close to SX126x". It is suitable for scenarios with large-scale deployment that are not sensitive to extreme spreading factors or extreme bandwidths but are very sensitive to BOM cost.
If your scenario (such as smart home) does not require extreme communication distance, it allows you to obtain the low-power architecture advantages of the SX126x class at a lower single-unit cost.
The LR2021 is the 4th generation LoRa chip from Semtech. It covers Sub-GHz/2.4GHz and supports S-band satellite communication; the same hardware can adapt to frequency bands of various countries through software configuration.
Compared to the previous generation, the typical receive sensitivity in Sub-GHz is improved by 4.5 dB, reaching a maximum of -141.5 dBm, making it more stable in long-distance and weak signal scenarios. At the same time, it fills the gap where Sub-GHz previously did not support FLRC. In FLRC mode, the rate can reach 2.6 Mbps (standard LoRa mode is up to 125 kbps), allowing applications to expand from traditional low-speed sensing to higher data volume transmission needs like audio and image transmission. While maintaining a low power consumption base of sleep current ≤ 2 µA, it also integrates LR-FHSS anti-interference, supports RTToF ranging, and is compatible with mainstream IoT protocols like LoRaWAN, BLE 5.0, and Wi-SUN, facilitating quick access to existing ecosystems.
Here we provide distance test data for the LR2021 in a real environment. Interested readers can refer to the article "G-NiceRF LoRa2021 Communication Range Field Test".
Buying a module is not about looking at the words "max distance", but looking at regulations, interfaces, power consumption, and RF details together.
For common frequency bands, you will see 433 MHz, 868 MHz, 915 MHz, etc. However, choosing them is not a matter of "picking whichever has a better signal", but rather "following the rules of where you sell". LoRaWAN regional parameters write out the frequency planning for common regions very clearly (even if you use a private protocol, you can use it as a reference framework for regional spectrum).
A practical approach is to determine the frequency band based on the market first.
The US market commonly uses US915.
The European market commonly uses EU868.
China commonly uses CN470 (some people also use 433 MHz for specific scenarios, but this must be strictly performed according to local radio regulations).
If your product will be sold across regions, try to reserve space in the architecture for "swappable frequency bands" and "swappable antennas", or directly consider multi-band solutions to reduce SKU fragmentation.
SPI is more flexible and is suitable for engineering teams that have a firmware team, need deep control over RF parameters, and want to squeeze power consumption and timing to the optimum. The cost is that the drivers, RF parameter configuration, and state machines must be solidly built by yourself.
UART modules are more like "plug and play". Many modules have encapsulated the protocol stack or basic transmission and reception. You can work using AT commands or simple frame formats. This is suitable for projects that need a quick time-to-market or where the team lacks RF experience. The cost is that controllability and portability are usually not as good as SPI direct connection chips.
If you are hesitating between "time" and "performance", a strategy that is empirically more stable is to use UART for quick verification of the business loop during the prototype phase, and then evaluate whether to switch to SPI to optimize power and cost for the mass production model.
Many people only stare at "transmit current", but for battery devices, "sleep current" often determines storage life and standby life, while "transmit current" determines power supply peak design and battery transient capability.
For example, for devices that report very rarely (like a water meter that updates daily), the device is in sleep mode 99.9% of the time. Every 1 µA reduction in sleep current has a very large long-term benefit for extending battery life.
For devices that report frequently or have a long Time on Air each time, transmit current and Time on Air will dominate battery consumption. However, under the same protocol and data volume, the core advantage of the SX126x compared to the SX127x becomes apparent, as its lower receive current can significantly pull down the average power consumption of the system.
The basis of LoRa long distance is the link budget, but the link budget is often destroyed by poor antenna matching. When the antenna and RF front-end impedance do not match, reflection occurs, which is equivalent to wasting a part of your transmit power that is already limited by regulations. The receiving end suffers just the same.
If you do not have RF debugging resources, prioritize considering the following.
Select "pre-matched" modules.
Use the reference antenna and trace layout suggested by the manufacturer.
Move the antenna away from "high-risk locations" like metal casings, shield edges, and PCB ground pours (GND).
Investments of this kind often produce more immediate results than "switching to a more expensive chip".
What truly affects delivery is "whether you can run it stably and maintain it". Therefore, when selecting a model, besides looking at parameters, you also need to check the following.
Whether there are complete demos and drivers, and whether common platforms like STM32 and Arduino are covered.
Whether there are clear RF parameter configuration instructions and typical application circuits.
Whether timely technical support can be obtained if problems arise.
Especially when migrating from legacy platforms like SX127x to new platforms like SX126x/LR2021, differences in register systems and driver models make "copying old code" unreliable. Reference drivers and routines provided by the manufacturer will significantly reduce risk.
The real KPI for many projects is not "how many kilometers is the max distance", but "no dropped connections on site, good batch consistency, and no issues in extreme environments". Therefore, when evaluating suppliers, it is recommended that you take "evidence of stability" as a hard metric, such as long-term operation cases, batch consistency data, and environmental reliability test reports.
Truly reliable solutions are often those that have been repeatedly verified in complex scenarios and long-term operations.
In actual projects, the stability of G-NiceRF technology has been verified in multiple large-scale projects, including large-scale complex scenario applications for "Run for Time" produced by Hunan TV in 2015, robot communication support for the CCTV Spring Festival Gala in 2016 and 2018, field communication support for the 2019 Wuhan Military World Games and the 2021 Centenary Celebration of the Founding of the Party, as well as the batch deployment of full-duplex audio modules for the State Grid in 2024.
Commercial products fear two things the most.
Chip or module EOL leads to you having to redo certification and hardware.
Lead time fluctuations cause you to be unable to deliver according to the contract.
Therefore, try to choose suppliers with "clear inventory strategies, long-term supply capability, and alternative component planning", and reserve alternative solutions in the design, such as footprint compatibility, adjustable RF front-ends, and a firmware abstraction layer to isolate chip differences.
When you enter the mass production stage, to ensure the complete implementation of the solution, G-NiceRF also provides supporting enhanced products including smart antennas, as well as full-stack value-added services such as ODM/OEM customization, multi-level MESH networking protocols, and OTA over-the-air upgrades.
Not necessarily. Distance depends on the link budget, which is jointly determined by transmit power, receive sensitivity, antenna gain, path loss, and system loss. If you increase the power but the receiver sensitivity, antenna efficiency, or interference environment does not improve, the improvement may be very limited. Conversely, switching to better antenna matching or reducing system noise is often more effective than blindly increasing power.
In addition, pay attention to regulatory limits on equivalent radiated power. In many regions, you cannot just set the power as high as you want.
It is not recommended to do this directly. Different regions have strict regulations on available frequency bands, duty cycles, transmit power, and channel planning. Even if the device "can transmit and receive", it may cause illegal interference and bring compliance risks. The safest way is to select the corresponding frequency band and certification path according to the target market, and design by referring to regional parameters or local regulatory requirements.
This depends on the sleep current of the module, wake-up cycle, Time on Air per transmission, transmit power, and number of retransmissions. Experience shows that for sensor devices with low reporting frequency, average power consumption is often determined by sleep current and the receive window. Generational differences in chips will significantly affect receive current and overall endurance. For example, the SX126x has an advantage in receive current relative to the SX127x, which will open up a gap in long-cycle operation.
If you are willing to use a formula for a quick estimate, you can use Battery Capacity (mAh) ÷ Average Current (mA). The average current is obtained by weighting the three parts of sleep, receive, and transmit according to their time proportions.
The spread spectrum characteristic of LoRa gives it strong anti-interference and low signal-to-noise ratio demodulation capabilities under certain conditions. At the same time, chips usually also provide mechanisms such as CAD (Channel Activity Detection) to detect channel activity, helping the device judge whether the channel is busy before sending, thereby reducing the probability of collision (specific implementation and effect depend on your protocol design and parameter configuration).
It requires adaptation, but usually, it does not go as far as "starting over". The main differences lie in the register system, command interface, and state machine control methods, so you cannot expect to directly reuse all low-level drivers. However, platforms with more mature ecosystems often have ready-made drivers and libraries for reference. The key to migration is to abstract "RF parameter configuration" and "transceiver processes" into a hardware-independent layer, and then replace the underlying driver implementation.
+86-755-23080616
sales@nicerf.com
Website: https://www.nicerf.com/
Address: 309-315, 3/F, Bldg A, Hongdu business building, Zone 43, Baoan Dist, Shenzhen, China
Privacy Policy
· Privacy Policy
There is currently no content available
Email:sales@nicerf.com
Tel:+86-755-23080616
English
