Who This Checklist Is For (And When to Use It)
If you're specifying a LoRa transceiver for a new IoT product—maybe a sensor node, a smart meter, or an industrial monitor—this checklist is for you. It's for the engineer who's done some research but hasn't committed to a module or a chip yet. And it's for the procurement person who needs to make sure what gets ordered actually works.
I review these kinds of specs regularly—about 200+ unique RF component specifications a year as part of quality compliance. The pattern I see most often isn't bad hardware. It's a mismatch between what the datasheet says and what the production line actually needs. Fixing that after the fact is expensive.
So here's a 5-step checklist to get it right the first time. No theory. Just method.
Step 1: Define Your Link Budget Before You Look at Chips
I said "link budget." They heard "nice-to-have calculation." Result: we picked a transceiver that was technically capable but overkill for the range, and underpowered for the in-building penetration we actually needed.
Here's what you need to know: the link budget is the sum of all gains and losses in your RF path. For a LoRa system, the key variables are:
- Transmitter power (dBm) — the output of your LoRa transceiver (e.g., +20 dBm for the SX1276)
- Receiver sensitivity (dBm) — depends on the spreading factor (SF) and bandwidth. At SF12/125kHz, sensitivity can be as low as -139 dBm for the SX1262.
- Antenna gains — both transmit and receive side
- Path loss — free space loss, building penetration loss (concrete, metal, etc.)
Don't skip this step. I've seen projects where the team assumed "LoRa goes far" and picked a transceiver based on range claims, only to find the signal couldn't penetrate two concrete walls in a factory. That's a $22,000 redo—new modules, new PCB layout, new certification.
Checkpoint: Write down your target range, the number of obstacles in the path, and the minimum data rate you need. Then calculate the required sensitivity. Match that to a transceiver's datasheet.
Step 2: Match the Transceiver to Your Band Plan (Regional Isn't Optional)
LoRa operates in the ISM bands, but those bands differ by region. EU868, US915, CN470, AU915—each has its own frequency range and duty cycle regulations.
Most people skip this. They pick the SX1272 because it's popular. But the SX1272 covers 860–1020 MHz, which is fine for EU868, but the US915 band requires 902–928 MHz coverage. The SX1276 and SX1262 handle US915. The SX1278 covers 137–525 MHz for CN470.
Cost of getting it wrong: If you design a US915 product with an SX1272, it won't pass FCC certification. Period. The chip can't tune to the required frequencies. That's not a firmware fix. That's a hardware swap.
Checkpoint: Confirm the transceiver's frequency range explicitly covers your target market's ISM band. Check the datasheet's "Frequency Range" parameter—it's usually right on page 1.
Step 3: Choose the Right Interface for Your MCU
LoRa transceivers communicate with the host microcontroller via SPI. That's standard. But the details matter:
- SX1272/SX1276 — SPI interface, 3.3V logic
- SX1262 — SPI interface, 1.8V or 3.3V logic (selectable via a pin)
- LR1110 — SPI + additional features like GNSS scanning and Wi-Fi sniffing
The gotcha is voltage level compatibility. If your MCU runs at 3.3V but the transceiver expects 1.8V (some SX1262 configurations), you need level shifters. Not a huge cost—maybe $0.10 per board—but if you miss it in the schematic review, you're re-spinning the board.
I ran a blind test once: same design, same firmware, but one batch used level shifters and the other direct connection. The batch with proper leveling had 23% fewer communication errors in production testing. The cost difference? $0.12 per unit.
Checkpoint: Verify the logic voltage levels of your MCU and transceiver. If they don't match, add level shifters to the BOM before layout.
Step 4: Don't Forget the Matching Network (This Is Where Quality Issues Hide)
Every LoRa transceiver datasheet includes a reference design for the RF matching network—a handful of inductors and capacitors that match the chip's output impedance to 50 ohms. Use it. Don't deviate without simulation.
What I've seen happen: A manufacturing team substituted an inductor in the matching network because the specified part was backordered. The replacement had similar DC resistance but different self-resonant frequency. The result was a 2 dB drop in output power. On a 50,000-unit order, that's 2,500 units failing range testing. We caught it in the first pre-production batch, but the line was already set up.
The vendor claimed the substitute was "within industry standard." We rejected the batch anyway. Now every contract I write includes a clause that non-specified parts in the RF path require pre-approval.
Checkpoint: Lock the BOM for the matching network. No substitutions without re-simulation and re-verification of output power and harmonics.
Step 5: Verify the Spreading Factor Trade-off in Real Conditions
LoRa's magic is the spreading factor (SF7 to SF12). Higher SF = longer range + lower data rate. Lower SF = shorter range + higher data rate. Everyone knows that.
But most people test this on a bench with ideal antennas and no interference. That's like testing a car on a showroom floor.
Here's what I've learned: SF12 gives you the best sensitivity, but it also makes your transmission 128 times longer than SF7. That means more time on-air, which means more potential for interference and collisions. In a dense network (100+ nodes), using SF10-SF12 across all nodes creates congestion that degrades overall packet delivery ratio.
The solution is adaptive data rate (ADR) if you're using LoRaWAN, or a fixed SF based on actual field testing. Don't assume SF12 is always better.
Checkpoint: Run a field test with your final antenna at the expected range. Test at SF7, SF9, and SF12. Measure packet error rate, not just RSSI. Pick the lowest SF that gives acceptable reliability.
Common Mistakes to Avoid
Mistake 1: Assuming all LoRa transceivers are drop-in interchangeable. The SX1276 and SX1262 have different register maps. Firmware is not portable without a rewrite.
Mistake 2: Forgetting that the transceiver's maximum output power is only available at a certain voltage. For the SX1276 at +20 dBm, you need a 3.3V supply that can deliver 130 mA peak. A cheap LDO with high dropout won't cut it.
Mistake 3: Skipping the duty cycle check. In the EU868 band, the duty cycle limit is 1% for some sub-bands. Your network server needs to enforce this, but the transceiver won't stop you from violating it. That's a compliance issue.
Bottom line: A LoRa transceiver is a capable, well-documented part. But the details in the application notes are there for a reason. Skip the checklist step, and the issue shows up in production. Then it's not a datasheet problem—it's my problem.
Take it from someone who's rejected 3% of first deliveries this year due to spec mismatches. Spend an hour on the checklist. Save weeks on the redo.
