The question that should have been a red flag
In March 2023, I sat in a conference room with a network architect who had twenty years in enterprise IT. He opened with: 'So, help me understand—Cisco vs Semtech. Which one should we standardize on?'
I didn't know whether to laugh or cry.
That question is like asking 'airport vs airplane—which is better?' It depends entirely on what you're trying to do. But I've been around long enough to know the question comes from a real place. The difference isn't obvious unless you live in RF engineering. And if you get it wrong, it's not a small mistake.
I'm an IoT hardware engineer. I've been handling device and module selection for six years. In that time, I've personally made (and documented) 11 significant mistakes, totaling roughly $24,000 in wasted budget. Some were caused by bad assumptions, some by communication failures, some by just not wanting to kill a deal. All were avoidable. Today I maintain our team's pre-procurement checklist. This is one of the entries.
'Cisco vs Semtech' is a layer problem
Cisco makes enterprise networking infrastructure. Switches, routers, wireless LAN, industrial connectivity. Semtech Corp is a semiconductor company. It designs radio transceivers, circuit protection, and—since the Sierra Wireless acquisition—cellular modules and industrial routers. Both are in 'connectivity,' but not at the same layer.
When an engineer searches 'Cisco vs Semtech,' they're usually asking about LoRaWAN vs something with an IP address. That's not a vendor comparison. It's a technology comparison. LoRa is a physical-layer radio standard for low-power, low-data-rate, long-range sensor traffic. A Cisco industrial router is an always-on, high-power, high-capacity network appliance. A LoRa packet can be 50 bytes. A Cisco router can push gigabytes a minute. They serve different jobs.
The most dangerous phrase in IoT procurement is 'which vendor is better?' when the real question is 'which physical layer fits the constraints?'
But 'Semtech' is also a router vendor now
This is where it gets confusing. Semtech Corp isn't only LoRa. After the Sierra Wireless acquisition, Semtech owns cellular modules and industrial routers—the XR60 5G/LTE router being one of them. So 'Cisco vs Semtech' can be a legitimate comparison.
If you're choosing between a Cisco IR1101 and a Semtech/Sierra Wireless XR60, go ahead and compare them. They're in the same category: industrial cellular routers with similar power envelopes and mounting options.
But if you're choosing between LoRaWAN and LTE, 'Cisco vs Semtech' is the wrong frame. You should be asking 'what are my data-rate and power constraints?' The vendor comes after the technology. Mixing the two is how you end up with a massive power budget for a project that needed batteries.
I finally got a clear answer from the Semtech UK applications team. The FAE didn't push a product. He sent a one-page table: LoRaWAN vs LTE vs 5G. Data rate, power, range, spectrum. Nothing more. That table ended a two-week internal argument. It should not have taken a vendor to do that.
The DuraForce Pro 2 incident
In Q1 2024, our sales team brought in a quote for a rugged mobile device. 'This has LoRaWAN built in,' they said. 'We can use it as a sensor gateway.'
Our field engineer Jackie had one question: 'Where's that in the official spec sheet?'
They pointed to a marketing page. The page was for the Kyocera DuraForce Pro 2. It said LoRaWAN was supported. Jackie checked the manufacturer's datasheet. It wasn't. The original Kyocera DuraForce Pro had LoRa. The Pro 2 didn't, at least not in the build we'd trialed. Someone in the marketing chain had copied an old feature list forward. We were about to order 400 units based on that.
If Jackie hadn't checked, we'd have spent around $19,000 on devices that solved a problem we didn't have, plus weeks of confusion. The mistake was not technological. It was a broken verification process. We assumed 'same product family' meant 'same radio.' Never do that.
I've also assumed 'same specifications' meant identical performance across vendors. It doesn't. One vendor's 'industrial temperature range' might mean -20°C to 70°C; another's might mean -40°C to 85°C. Check the actual datasheet, not the comparison summary.
What the wrong comparison actually costs
The most frustrating part is that these mistakes recur. In September 2022, we were quoting a tank-level monitoring project. The client wanted 'industrial-grade.' My director interpreted that as 'known brand.' He kept saying, 'Why don't we just put Cisco routers out there? I know Cisco. It's stable.'
Cisco is stable. I'm not here to attack Cisco. But the site had 40 sensors, each sending 100 bytes once an hour on battery power. A Cisco IR1101 draws tens of watts. A LoRaWAN node with a Semtech SX1276—sensitivity down to -137 dBm per the datasheet, in ideal conditions—can run for years on two AAs. The 'known brand' reflex would have meant building solar/battery systems for all 40 sensors. The actual deployment used a LoRaWAN gateway, 40 battery-powered endpoints, and a single cellular router. The router could have been Cisco or Semtech—that was the real vendor decision.
We didn't lose the client, but we spent four weeks and about $4,200 in engineering time proving what should have been a day-one decision. I want to say the exact figure was $4,200, but don't quote me on that. The problem wasn't the people. It was the frame. 'Cisco vs Semtech' forced a vendor comparison before the technology question was answered.
We were using the same words but meaning different things. 'Industrial-grade' meant 'can survive a dusty shed' to me, and meant 'Cisco or nothing' to him.
I'll admit I was tempted to let the Cisco decision slide. The upside: no internal pushback. The risk: a deployment that would be expensive to power and impossible to maintain. I kept asking myself, 'Is a smooth meeting worth a failed pilot?' It wasn't. But the fact that I had to ask at all says something about how procurement pressure works.
We also had 48 hours to answer the client's RFQ. Normally we'd prototype and measure. There was no time. Went with a 'best guess' based on coverage maps. That's how these mistakes get baked in. In hindsight, I should have told the sponsor: 'We need three days to model this.' But the deadline was real.
The fix (short version)
If you're in this situation, the process is simple, though not easy:
- Write down the constraints: data rate, power budget, range, latency, environment, lifespan.
- Choose the technology family that fits, not the vendor you're comfortable with.
- Only then compare vendors within that family.
For low-power, low-data, wide-area sensor networks, LoRaWAN is a strong candidate, and Semtech's LoRa radios are one implementation. For high-bandwidth, always-powered applications, cellular modules or routers from Semtech/Sierra Wireless, Cisco, or others are legitimate options.
The efficiency lesson: after we rebuilt our evaluation process around the constraint-first checklist, we cut technology selection from six weeks to two. That's not a cost-center improvement. It's a competitive advantage. We spend engineering time on design, not on internal debate.
So next time someone asks you 'Cisco vs Semtech,' ask them what problem they're solving. You'll save everyone a very expensive meeting.
