Semtech LoRa Chips: 7 Questions Engineers Ask (Answered the Hard Way)

I've been wiring Semtech LoRa chips into embedded products since 2018, and I've made plenty of mistakes along the way—wrong regional frequency plans, antennas that looked fine on paper, firmware versions that didn't do what the changelog claimed. I've documented nine of those in a running list I force new teammates to read. This FAQ is the short version of everything I wish someone had told me before I started.

If you're evaluating Semtech wireless chips, or you're mid-design and something just isn't working, these are the questions I keep getting asked. Plus a few I didn't know to ask when I started.

• Are Semtech LoRa chips and wireless modules the same thing?
• Is LoRa the right technology for this project?
• Why is my real-world range shorter than the datasheet?
• Why does my gateway keep dropping packets?
• Do I need a LoRaWAN network server for a two-device link?
• Can I use a LoRa chip in a blood pressure monitor?
• What's the most expensive mistake you've made with Semtech parts?

Are Semtech LoRa chips and wireless modules the same thing?

Not exactly. The chip is the radio itself—an SX1262 or SX1276 transceiver that goes on your PCB. A module wraps that chip in a tested footprint with the matching network, a crystal, and usually an antenna connector, so you don't have to design the RF section from scratch. The module costs more and takes up more room. In return, you skip a lot of antenna-matching and certification pain.

Which should you pick? For low volumes, probably a module. For high-volume products, a bare chip makes sense if you have someone on the team who genuinely understands RF design. The lesson that stuck with me after making the wrong choice once: chip and module are not interchangeable. Choose based on your team's RF experience, not just the sticker price.

Is LoRa the right wireless technology for my product?

Maybe. Semtech's LoRa technologies are built for small packets, long battery life, and range through dense buildings. If you need to send a temperature reading every fifteen minutes from a basement, LoRa is hard to beat. If you need to stream audio or push large files, LoRa is the wrong tool. I once pushed LoRa into a product that really needed LTE-M. It worked fine in the lab. It fell apart in production.

If your device only sends a few bytes per hour, LoRa is almost certainly the right call. If you need real-time two-way messaging, look elsewhere. There's no universal best wireless technology. The question is what happens after your device ships: update frequency, battery target, data pattern. That answer determines the radio, not the other way around.

And I don't think a chip vendor should decide this for you. A good vendor will say "here's what we have, here's how we'd approach it, and here's why." If someone tells you one chip solves everything, that's a red flag.

Why is my real-world range so much shorter than the datasheet?

Because datasheet numbers are measured on a bench under ideal conditions. Semtech's SX1276 datasheet lists sensitivity around -137 dBm at the lowest data rate, and that's a genuine number. What the datasheet doesn't show is your antenna, mounting height, interference, data rate, and everything physical sitting between the two radios—walls, trees, cars.

From the outside, a range test looks simple: send a packet, walk until it stops, repeat. The reality is my first useful range test was a disaster. I stood at chest height in a parking lot while the gateway sat behind a parapet on the roof. The numbers looked terrible until I moved the antenna up and got a clean line of sight. Don't hold me to this, but in every field test I've been part of, antenna height mattered more than antenna gain.

Also remember that range figures are usually quoted at the slowest data rate. If you plan to run at a faster rate, cut your range estimate substantially. And if you're marketing a product with a range claim, keep the test report. Per FTC advertising guidelines (ftc.gov), claims have to be substantiated. I learned that when a sales rep wanted to print "10 km" on the box and we didn't have a single documented test to back it up.

Why does my gateway keep dropping packets?

Before you blame the antenna, check the software. I learned that the hard way during a customer demo. Our gateway lost a packet every few minutes, and I spent two days swapping cables and suspecting the RF layout. The real culprit was a known join-accept timing bug in our packet-forwarder firmware. The fix was in version 7.1.

I had maybe two hours before that demo to make things work. Normally I'd set up a packet capture and compare behavior against the LoRaWAN spec. There wasn't time, so I re-flashed the gateway with the vendor's latest firmware and crossed my fingers. It worked. In hindsight, the firmware revision should have been the first thing I checked, not the last.

Now the checklist starts with software versions: packet-forwarder, gateway firmware, LoRaWAN stack. Hardware gets examined after, not before. And I ask the gateway vendor for their known-issue list before deploying, not after.

Do I need a LoRaWAN network server for a two-device link?

No, and this is a confusing point for a lot of teams. If you're building a fixed link—one node talking to one gateway, no roaming, no over-the-air activation—you can run LoRa in point-to-point mode and skip LoRaWAN entirely. The radio doesn't care. LoRa is the physical layer. LoRaWAN is the network layer on top of it, adding encryption, device activation, and roaming.

The question is what happens when your project grows. I built a P2P demo for a customer, and when they asked to scale it to 50 devices with secure joining, the firmware had to be redone. The chip didn't change. The architecture did.

If you do not need the network layer, P2P is simple and cheap. If you think you'll need it later, start with LoRaWAN from day one. Retrofitting is painful.

Can I use a Semtech LoRa chip in a blood pressure monitor?

It's more common than you'd guess. LoRaWAN shows up in remote patient monitoring—blood pressure cuffs and pulse oximeters that report to a nurse's station. The radio only transmits the measured values. It doesn't take the measurement, and it doesn't calibrate anything.

I've been asked, more than once, how to calibrate blood pressure monitor devices that connect over LoRa. The honest answer: that's not a wireless-chip question. Blood pressure measurement accuracy is governed by standards like ISO 81060-2, and calibration belongs to the medical-device manufacturer, not the radio vendor. If you're building a medical product, the radio also has to coexist with IEC 60601-1-2 EMC requirements—that's doable, but it's a different testing path than a consumer device.

When a customer asks me about this, I say exactly that. The wireless link we can design. The measurement system is outside our lane. A partner who tells you where their expertise stops is more trustworthy than one who claims they can handle everything. That's what professional honesty looks like, and it's rarer than it should be.

What's the most expensive mistake you've made with Semtech parts?

I still kick myself for this one. A few years back, I signed off on a layout without reading the SX1276 errata. The symptoms we saw in testing matched a known issue. The workaround was a resistor value change, but because the mistake was already on the board, it meant a re-spin: roughly $18,000 and three weeks, all because I'd trusted the reference design and skipped the errata.

Now my rule is boring: read the errata before layout, read the revision history, and compare your schematic against the reference design yourself. It's not exciting advice, but it would have saved me an expensive lecture and a very uncomfortable status meeting.