HOST_A: Welcome back to Clawd Talks. I'm Emma, and if you've been following the IoT space for any length of time, you've heard the name LoRaWAN thrown around — usually alongside claims that are either breathlessly enthusiastic or weirdly dismissive.
HOST_B: And I'm Ryan. I've spent the last couple of years actually building LoRaWAN sensors — not just reading about them. I have a box under my desk with fourteen handmade sensors in it. So today we're going to get into the real story.
HOST_A: Today's episode is the deep dive I've wanted to do for a while. We're going to cover the physics, the protocol architecture, the real costs, the applications, the failures — and the comparison with every competing technology that matters.
HOST_B: And we're going to disagree on some of this. Emma and I have genuinely different perspectives on where LoRaWAN sits in the IoT landscape.
HOST_A: Let's start with a hook. Ryan, what's the number that first made you take LoRaWAN seriously?
HOST_B: Okay. Switzerland. The entire country — and I mean the entire country, including the Alps, the remote valleys, the farms at fifteen hundred metres altitude — is covered by a single LoRaWAN network run by Swisscom.
HOST_A: One operator. Nationwide. Including mountains.
HOST_B: And the price for a device to connect to that network is roughly ten euro cents per device per month. Not ten euros. Ten cents.
HOST_A: I want people to sit with that for a second. If you have a thousand IoT sensors deployed across Switzerland, your total connectivity cost is a hundred euros per month. For a thousand sensors.
HOST_B: And it's not just Switzerland that has built this out. KPN in the Netherlands covers ninety-nine percent of the country. Orange in France, Bouygues Telecom — massive national deployments. And then in cities across Europe and North America there's The Things Network, which is community-run and completely free.
HOST_A: Free as in genuinely free. Open source, run by volunteers and enthusiasts, with gateways contributed by the community.
HOST_B: The scale of what's already deployed is staggering. We're talking hundreds of millions of LoRaWAN end devices in the field globally. Smart meters, parking sensors, flood monitors, livestock trackers — running on these networks right now.
HOST_A: And most of them on AA batteries. Or coin cells. That last years. That's the thing that defies intuition about LoRaWAN. You're covering kilometres of range, transmitting data to a network, and your power budget is so small that a couple of batteries last five years.
HOST_B: So how is that possible? That's what we need to explain. Let's go to first principles.
HOST_A: LoRa. L-O-R-A. Long Range. Before we say anything else, let's be very clear: LoRa is not LoRaWAN. They are different things, and people conflate them constantly.
HOST_B: LoRa is the radio modulation technique. It's the physical layer — how bits are encoded onto radio waves. LoRaWAN is the network protocol built on top of that. Think of it like the difference between the electrical signal on an ethernet cable versus the TCP/IP stack you run over it.
HOST_A: LoRa was developed by a French startup called Cycleo. They invented a clever modulation technique and Semtech — an American semiconductor company — acquired them in 2012 for a reported five million dollars. Which, in retrospect, was an absolute bargain.
HOST_B: The technique is called Chirp Spread Spectrum. CSS. And a chirp, if you're not familiar, is a signal that sweeps through a range of frequencies over time — like the sound of a bird chirp, where the pitch glides upward.
HOST_A: CSS uses these chirps to encode data. You spread your signal across a wide bandwidth instead of concentrating it at a single frequency. And here's the incredible thing that makes LoRa special — by spreading the signal, you make it extraordinarily resistant to noise.
HOST_B: The SNR figure is what gets engineers excited. Signal-to-noise ratio. Conventional radio receivers need the signal to be above the noise floor — you need your signal louder than the background static. LoRa can decode signals that are twenty decibels below the noise floor.
HOST_A: Minus twenty dB. For the non-engineers in the audience — in linear terms, that means LoRa can extract your signal even when the background noise is one hundred times stronger than your signal. It is genuinely remarkable signal processing.
HOST_B: And that sensitivity is why the range is so extraordinary. In an urban environment, a single LoRa gateway can reliably cover two to five kilometres. Rural, line of sight, you're looking at ten to fifteen kilometres as a normal operating range.
HOST_A: And then there are the extreme demonstrations. People have flown LoRa transmitters on weather balloons and received signals from over eight hundred kilometres away. Obviously that's not a practical deployment scenario, but it shows the theoretical capability of the technology.
HOST_B: The frequency bands are important too, because they're unlicensed. In Europe, LoRaWAN uses 868 megahertz. The US uses 915. Much of Asia uses 433. These are ISM bands — Industrial, Scientific and Medical — where you don't need a licence to operate.
HOST_A: Which is a big deal for cost and deployment simplicity. You don't need to apply for spectrum, you don't pay licence fees, anyone can put up a gateway and it's legal.
HOST_B: Now let's talk spreading factors, because this is where things get technically interesting. The spreading factor — abbreviated SF — is a number between seven and twelve. It controls the trade-off between data rate and range.
HOST_A: At SF7, you're spreading your signal the least — fastest data rate, shortest range. At SF12, you're spreading the most — slowest data rate, maximum range.
HOST_B: And the numbers are not linear. SF12 is roughly fifty times slower than SF7 in terms of data rate. A packet that takes a few milliseconds at SF7 might take over two seconds at SF12.
HOST_A: Why does that matter? Because of the duty cycle regulation. In Europe, the regulations say you can only transmit one percent of the time. Thirty-six seconds per hour.
HOST_B: So if your packets at SF12 take two seconds each, you can only send eighteen packets per hour. That is the fundamental capacity constraint of LoRaWAN. Not range. Not cost. Throughput.
HOST_A: And the Adaptive Data Rate system — ADR — is the network's attempt to optimise this. The network server looks at the received signal quality from each device and instructs it to use the fastest spreading factor it can while still maintaining a reliable link.
HOST_B: Devices close to gateways run at SF7 or SF8. Devices at the edge of coverage run at SF11 or SF12. This maximises network capacity overall, because the fast devices take up less airtime on the shared spectrum.
HOST_A: Now — the LoRaWAN network architecture. This is what separates it from just having a LoRa radio.
HOST_B: The topology is called star of stars. It's a three-tier structure. Your sensor devices talk to gateways, gateways talk to a network server, the network server talks to your application.
HOST_A: The gateways are intentionally dumb. They're just radio packet forwarders. When they hear a LoRa transmission, they timestamp it, note the signal quality, and forward it to the network server over the internet. They don't care about content, they don't make routing decisions.
HOST_B: The consequence of this is great — multiple gateways can hear the same transmission, and the network server deduplicates them. If your device is within range of three gateways, all three forward the packet, and the server picks the best copy. That gives you redundancy for free.
HOST_A: The network server does all the heavy lifting — authentication, encryption, deduplication, routing to the right application. It's where the intelligence lives.
HOST_B: And because gateways are dumb and cheap, you can build a very resilient network with lots of overlapping coverage. The failure of one gateway doesn't drop any devices.
HOST_A: Let's talk device classes, because they define what LoRaWAN can and can't do. Class A is the baseline — it's what the vast majority of battery-powered sensors use. After a device transmits a packet, it opens two short receive windows. The first about one second after transmission, the second about two seconds after. Those are the only moments it will accept a downlink from the network.
HOST_B: Outside of those windows, a Class A device's radio is completely off. It's sleeping. Drawing microamperes. This is how you get multi-year battery life — the device is off almost all the time.
HOST_A: Class B adds a beacon system. The network broadcasts a timing beacon, and Class B devices sync to it. This allows the network to schedule receive windows at predictable times — not just after the device transmits. Useful if you need to send commands on a schedule.
HOST_B: Class C is the always-on class. The radio is always listening. You can send a downlink at any time. Great for actuators — valve controllers, relay switches — but your power consumption is much higher. Class C devices are mains-powered.
HOST_A: Okay. Let's talk about what all of this looks like in real deployments. Because the application space for LoRaWAN is genuinely enormous.
HOST_B: Smart cities. This is where some of the most visible deployments are. Amsterdam has had LoRaWAN parking sensors embedded in the road surface for years. Small pucks with a magnetic sensor that detect whether a car is present. They send a status update when a car arrives or leaves.
HOST_A: And from a city management perspective, this is transformative. Real-time occupancy data for every parking space. Reduce circling traffic, improve enforcement efficiency, give drivers a navigation app that shows actual availability.
HOST_B: Each sensor runs on a battery that lasts five to seven years. Zero maintenance once installed. And they're communicating through existing city gateways.
HOST_A: Waste management. This is one I find particularly elegant. You put a fill-level sensor in a public bin — it's an ultrasonic sensor that measures how full the bin is. Sends an update a few times a day.
HOST_B: The collection trucks only go to a bin when it's actually full. Some cities have reported thirty percent reductions in collection costs. The bins that fill fast get serviced more. The bins in quiet areas get left until they actually need it.
HOST_A: Street lighting control. You can send control signals to individual streetlights. Dim them at three in the morning when nobody's around. Turn them off for maintenance windows. Alert the control centre when a bulb fails. The lights are Class C — mains powered — so they can receive commands any time.
HOST_B: Agriculture. This is where I get really excited, because the economics are so compelling. Think about a farm. You might have a hundred hectares of crops. You want to know soil moisture at multiple depths across the field, so you can irrigate precisely and not waste water.
HOST_A: Traditional approach: hire someone to walk the field and take manual readings. Or run cables. Or use cellular sensors with expensive monthly fees.
HOST_B: LoRaWAN approach: put a dozen sensors in the ground. Each one runs on a small solar panel and rechargeable battery. Sends soil moisture data every thirty minutes. One gateway on the barn roof covers the whole farm.
HOST_A: And if you're using The Things Network or running your own ChirpStack server, the ongoing cost is essentially nothing beyond the hardware.
HOST_B: I've done exactly this. A friend of mine has a vineyard, and I set up a network for him. Six soil sensors, one outdoor gateway, Raspberry Pi running ChirpStack, Grafana dashboards showing soil moisture across the vineyard in real time. The total hardware bill was about four hundred euros.
HOST_A: Utilities are where the really massive volume deployments are. Smart metering. Water meters, gas meters, electricity meters. The big metering companies — Itron, Diehl, Kamstrup — have shipped tens of millions of LoRaWAN meters.
HOST_B: The business case writes itself. You replace a meter reader who drives around every month with a sensor that automatically reports usage. The meter battery lasts ten years. You get daily readings instead of monthly ones.
HOST_A: And for the utility, accurate daily readings mean accurate billing, faster leak detection for water networks, and better demand forecasting. The ROI on smart metering is extremely well established at this point.
HOST_B: Cold chain monitoring is another application I love. Temperature logging for pharmaceutical shipments, blood products, food logistics. A small sensor in the shipping container records temperature every few minutes.
HOST_A: When the container arrives at a warehouse with a gateway, the full temperature log uploads automatically. If there was a temperature excursion during transit, you know about it before you distribute the product.
HOST_B: Some logistics hubs have dense LoRaWAN gateway coverage specifically to enable this — shipping containers send their data as they pass through the port.
HOST_A: Environmental monitoring. Flood early warning systems are a genuinely life-saving application. River level sensors on flood-prone waterways, sending readings every fifteen minutes. If the level rises rapidly, automatic alerts go out to emergency services and residents.
HOST_B: And these sensors need to work in remote areas, run for years without maintenance, and survive flooding events themselves. LoRaWAN ticks all those boxes.
HOST_A: Alpine weather stations, air quality networks in cities, seismic sensors in volcanic areas — there are LoRaWAN deployments in all of these. The combination of long range and low power makes it uniquely suited to environmental sensing.
HOST_B: Disaster relief is an underappreciated use case. When there's an earthquake or a flood, the mobile network goes down. But you can drop a LoRaWAN gateway with a satellite backhaul into a disaster zone and immediately have sensor connectivity across several kilometres of radius.
HOST_A: No existing infrastructure needed. No contract with a carrier. Just a gateway, an internet connection via satellite, and suddenly you have coverage. That matters enormously for search and rescue coordination.
HOST_B: Okay. Now I want to start pushing back on some of the hype, because I think the LoRaWAN narrative sometimes glosses over real limitations.
HOST_A: Let's hear it. I'll probably agree with some of this.
HOST_B: The throughput situation is more constrained than marketing materials suggest. One percent duty cycle means thirty-six seconds of transmit time per hour. But the actual data capacity is tiny. A LoRaWAN payload is typically fifty bytes. At SF7 with a short payload, you might get perhaps two hundred packets an hour from a device.
HOST_A: But if you're at SF12 — which you are if you're at the edge of coverage — that drops dramatically. And real devices in urban environments often end up at SF10 or SF11 because of interference and reflections.
HOST_B: Exactly. And people don't always account for the network capacity, not just individual device capacity. If you have five thousand devices on the same gateway all sending data, the collision rate goes up, packets get lost, effective throughput per device drops.
HOST_A: The gateway capacity question is often overlooked. A single LoRaWAN gateway can theoretically handle thousands of devices, but only because each device sends very infrequently. If you suddenly have devices that want to send data every minute, you'll saturate the gateway.
HOST_B: Latency. This is the one that really gets me when I see LoRaWAN being specced incorrectly. Class A devices can only receive a downlink in those two windows after they transmit. If your device sends data every ten minutes, and you need to send it a command, you might wait ten minutes for it to wake up.
HOST_A: And if you need any kind of closed-loop control — read a sensor, decide whether to open a valve, send the command — LoRaWAN is completely wrong. The latency is incompatible with real-time control systems.
HOST_B: I've seen projects where someone wanted to build a smart irrigation controller. Turn the valve on or off based on current conditions. They thought LoRaWAN would work. It doesn't — or at least, not without designing around the latency. You have to pre-schedule commands or use Class C, which means mains power.
HOST_A: The "it's simple" myth is another one. For a hobby project, connecting one sensor to TTN is genuinely straightforward. For a production deployment of five hundred devices across multiple sites, it is not simple at all.
HOST_B: Device management at scale is hard. Firmware updates — called FUOTA, Firmware Update Over The Air — over a low-bandwidth, intermittent channel where the device only listens for milliseconds after each transmission, can take days to complete for a single device.
HOST_A: And if your firmware update has a bug, you might brick devices that you then have to physically access to fix. At scale, physical access is expensive.
HOST_B: Security is a real concern that the industry doesn't talk about enough. LoRaWAN 1.0 — which is what many deployed devices run — had known weaknesses in the session key derivation. Replay attack vulnerabilities. The keys were sixteen bytes, which sounds fine, but the implementation had gaps.
HOST_A: LoRaWAN 1.1 addressed most of these. Better root key separation, mutual authentication, frame counter protection. But the deployed base is slow to upgrade. A lot of devices that went into the ground five years ago on 1.0 are still there.
HOST_B: And then there's Helium. Oh, the Helium story.
HOST_A: Tell me how you feel about Helium, Ryan.
HOST_B: Helium was — I want to be fair here — a genuinely clever idea that got completely distorted by crypto incentives. The concept was: people buy hotspots, deploy them at home, provide LoRaWAN coverage, and get paid in HNT tokens proportional to the coverage and traffic they carry.
HOST_A: The vision was to build a people's IoT network. Grassroots, decentralised, no big telco. And at its peak they had millions of gateways deployed in cities around the world.
HOST_B: But the dirty secret was that almost none of those gateways were carrying real IoT traffic. The token rewards were based on proof-of-coverage — proving you had a radio operational — not on actual data traffic.
HOST_A: So the rational economic behaviour was to buy a hotspot, put it in your window, farm tokens, and not worry about whether any devices were actually connecting to it. The coverage existed on paper without the demand.
HOST_B: The HNT token crashed. The company pivoted to 5G, which made even less sense. The IoT vision essentially died. And it soured a lot of serious operators on the idea of blockchain-incentivised network infrastructure.
HOST_A: To be fair — it did accidentally create genuine LoRaWAN coverage in a lot of places. Some of those gateways are still running and still forwarding legitimate traffic. But it was a cautionary tale about what happens when financial speculation drives infrastructure deployment.
HOST_B: And interference. Dense ISM band usage is a real problem. Amsterdam, which has one of the most advanced smart city deployments in the world, has documented real interference issues in the 868 megahertz band. Multiple commercial operators, TTN, Helium, private networks — all sharing the same unlicensed spectrum.
HOST_A: As LoRaWAN deployment densifies, this gets worse. The duty cycle regulation helps — it limits how much any one device can transmit. But you can't regulate other operators' behaviour, and unlicensed spectrum is a commons that can be degraded.
HOST_B: Alright. Let's do the technology comparison, because this is what a lot of people want to understand — when do I choose LoRaWAN versus the alternatives?
HOST_A: Let's start with Meshtastic, because it's the one that generates the most confusion. Meshtastic uses LoRa radio — the same chips, the same frequencies. But it is absolutely not LoRaWAN.
HOST_B: Meshtastic is a peer-to-peer mesh protocol. No gateways, no network server, no star topology. Every device is both a node and a router. When you send a message, it floods through the mesh — every node that hears it rebroadcasts it.
HOST_A: It's designed for off-grid communication in small groups. Hikers, campers, search and rescue teams, disaster relief — situations where there is literally no mobile infrastructure and you want to stay in contact with your team.
HOST_B: I have two T-Beam boards with Meshtastic. When I go into the Alps where there's no signal, I can still send text messages and GPS coordinates to hiking partners within range, or through the mesh if there are intermediate nodes.
HOST_A: The key differences from LoRaWAN: Meshtastic needs no infrastructure — that's its superpower. But it doesn't scale. Flood routing means every device has to hear and retransmit every message. In a dense city with thousands of nodes, that collapses.
HOST_B: And Meshtastic uses longer spreading factors — SF10 and up — for maximum range between nodes. So it's even slower than LoRaWAN. You're sending texts and GPS positions, not sensor data streams.
HOST_A: They're solving completely different problems. LoRaWAN is for large-scale sensor networks with centralised infrastructure. Meshtastic is for small-group decentralised communication without any infrastructure. Don't compare them as if they compete.
HOST_B: Sigfox. This was LoRaWAN's main competitor in the LPWAN space for years. Ultra-narrowband, similar range, but even lower data rate. You're limited to twelve bytes uplink per message, and maybe four messages downlink per day.
HOST_A: And the company went bankrupt in 2022. Acquired by Unabiz, a Singapore-based company. The technology still works, existing deployments still run. But the future of the ecosystem is uncertain.
HOST_B: If you're designing a new product today, I would not choose Sigfox. The risk of being stranded by ecosystem collapse is too high. LoRaWAN is an open standard — even if Semtech disappeared tomorrow, the standard lives on and there are multiple chip vendors.
HOST_A: NB-IoT and LTE-M. These are the cellular IoT options, standardised by 3GPP. They run on licensed spectrum using existing mobile towers.
HOST_B: The fundamental difference: NB-IoT and LTE-M use the mobile operators' infrastructure. You get a SIM card, you connect to the mobile network just like your phone does, except at much lower data rates and lower power.
HOST_A: The advantages: better data rate than LoRaWAN — NB-IoT does about 200 kilobits per second downlink, orders of magnitude more than LoRaWAN. Better mobility — cellular towers are designed for moving devices. Better latency — you can send and receive messages at any time.
HOST_B: The disadvantages: cost. A SIM with NB-IoT connectivity is maybe one to three euros per device per month from most European operators. Not catastrophic, but for a deployment of ten thousand sensors over ten years, that's a million euros in connectivity alone.
HOST_A: Power consumption is higher too. Not dramatically — NB-IoT has a power saving mode — but a LoRaWAN device running at a similar update frequency will typically outlast an NB-IoT device on the same battery.
HOST_B: My mental model for choosing between them: if the device moves — it's a vehicle, an animal, a person — and you need regular location updates, NB-IoT. If the device sits in one place for five years and sends a reading once an hour, LoRaWAN.
HOST_A: Zigbee and Z-Wave. Short-range mesh protocols. About a hundred metre range. They're great for what they do — home automation, building automation. Your smart lights, your thermostat, your door sensors. But they're not wide-area technologies.
HOST_B: If you need to cover a farm, a city block, or a river valley — Zigbee simply isn't in the conversation. But for a smart building where everything is within a few floors of a gateway, Zigbee is reliable and well-proven.
HOST_A: WiFi. Too power-hungry for battery IoT, full stop. The WiFi radio draws tens of milliamps. LoRa draws microamps in sleep mode and a few milliamps during transmission. The power budget difference is multiple orders of magnitude.
HOST_B: You can do IoT over WiFi if you have mains power and need decent data rate — a security camera being the obvious example. But for the "sensor on a battery for five years" use case, WiFi is completely excluded.
HOST_A: So the comparison matrix: LoRaWAN wins on range, battery life, and low cost at scale for stationary low-data devices. NB-IoT wins on mobility, data rate, and latency for moving objects or higher-frequency updates. Meshtastic wins on zero infrastructure and off-grid resilience. Zigbee wins on home automation integration and mesh reliability at short range. There's no overall winner — you pick the tool for the job.
HOST_B: Let's talk money more carefully, because the economics of LoRaWAN are genuinely compelling and I think often understated.
HOST_A: Hardware. The LoRa chip — the Semtech SX1276 is the classic — costs three to eight euros in volume. The chip itself. A complete development board like the TTGO LoRa32 or the Heltec LoRa32 is fifteen to twenty-five euros delivered from AliExpress.
HOST_B: That's the complete hardware you need to start — microcontroller, LoRa radio, antenna connector, USB port. Eighteen euros and you're playing with LoRa. I bought one, soldered a BME280 temperature sensor to it, and had it running in an afternoon.
HOST_A: Commercial production-grade sensors — the kind you'd deploy in an enterprise context — run twenty to two hundred euros depending on what they measure and how ruggedised they are. But compare that to a legacy industrial sensor requiring wired installation. The economics shift dramatically.
HOST_B: Gateways. Indoor, plastic enclosure, designed for office or factory environments — a hundred to two hundred euros. An outdoor industrial gateway with weatherproofing, proper connector, designed for pole mounting — three hundred to a thousand euros.
HOST_A: One outdoor gateway, properly placed, can cover several kilometres of radius. In a city you might want one gateway per square kilometre for dense reliable coverage. In rural areas one gateway on a hilltop can cover fifty square kilometres.
HOST_B: Network server. ChirpStack is completely free and open source. I run it on a Raspberry Pi 4 for personal projects. It handles everything — device authentication, packet deduplication, application routing, the full stack. For production, you'd probably run it on a small VPS or in your cloud account.
HOST_A: Data costs. The Things Network — TTN — is free for fair use. The fair use policy limits each device to thirty seconds of uplink airtime per day and ten downlink messages. For typical sensor use cases, that's completely adequate.
HOST_B: I've been using TTN for two years for personal projects and I've never hit the fair use limit. For a soil sensor sending data every thirty minutes at SF7, you're using a fraction of the allowance.
HOST_A: For commercial deployments needing guaranteed SLAs: Swisscom IoT is roughly ten cents per device per month for nationwide Switzerland coverage. Other European operators are in a similar range. Compare this to cellular IoT at one to three euros per device per month — LoRaWAN is typically ten times cheaper at scale.
HOST_B: And if you build a private network — your own gateways, your own ChirpStack server — the ongoing cost is basically electricity and hosting. No per-device fees. You own the whole stack.
HOST_A: That private network option is actually very attractive for enterprises with security requirements. You're not sending data over any third-party network. No carrier can inspect your packets. Complete data sovereignty.
HOST_B: Okay. Practical projects. What can a maker or an engineer actually build today, with off-the-shelf hardware?
HOST_A: The GPS tracker is the classic entry-level project. The TTGO T-Beam is a single board that combines an ESP32, a LoRa radio, and a GPS module. Connect it to The Things Network, use TTN Mapper — which is a crowdsourced LoRaWAN coverage map — and you're done.
HOST_B: I built one of these and attached it to my bicycle. Every five minutes it sends a GPS coordinate to TTN. Battery lasts about two weeks. It's not real-time — there's up to five minutes of latency — but it would tell me what area my bike was in if it was stolen.
HOST_A: Soil moisture network for a garden or small farm. RAK WisBlock is a modular platform — you pick a base board and snap on sensor modules. Soil moisture, temperature, CO2, accelerometer — dozens of modules available. You can assemble a soil sensor in minutes without soldering.
HOST_B: The RAK WisBlock base boards have low-power modes that make multi-year battery life achievable. Combined with a small solar panel, you can have a sensor that effectively runs forever. I built six of these for a friend's vineyard. ChirpStack on a Raspberry Pi, Grafana dashboards, completely self-contained.
HOST_A: The Adafruit Feather ecosystem is another accessible option for Arduino-comfortable makers. They have LoRa Feather boards and a library of compatible sensor FeatherWings. Very beginner-friendly, good documentation.
HOST_B: For the network server side — spend a few hours with the ChirpStack documentation and you'll have a working setup on a Raspberry Pi. It's genuinely well-written. And the TTN console is even easier to get started if you don't want to run your own server.
HOST_A: Cold chain monitoring is a project with real commercial potential. A custom PCB with an SHT40 temperature and humidity sensor, a LoRa module, and a battery. Stick it in a shipping container or a vaccine refrigerator. Total Bill of Materials under thirty euros.
HOST_B: When the container passes through a logistics hub with a gateway, the full temperature log uploads. Any temperature excursion during transit is flagged. For pharmaceutical or food logistics, having that audit trail is legally required in many jurisdictions.
HOST_A: Environmental flood monitoring. An ultrasonic distance sensor aimed at a river surface, LoRaWAN, solar panel, sends water level every fifteen minutes. In a flood-prone area, this gives early warning that genuinely saves lives.
HOST_B: The cost of a single river sensor is maybe a hundred and fifty euros for hardware. Traditional hydrological monitoring equipment costs tens of thousands. A community could crowdfund a flood warning network for their village for a few hundred euros.
HOST_A: Building monitoring is a great commercial application. CO2, temperature, humidity, VOC sensors across a large office building. LoRaWAN avoids the wiring nightmare. One gateway in the building covers all the sensors. Facilities managers get data without running cables.
HOST_B: One thing I tell beginners: check TTN Mapper before you buy a gateway. If you're in a city, there may already be gateways covering your area. Zoom in on your location, see if there's coverage. You might be able to start testing immediately with a node and no gateway purchase.
HOST_A: And the TTN community forums are excellent. Very active, very helpful. If you're stuck, someone will have solved the same problem.
HOST_B: RAK and Dragino both sell starter kits — gateway and node together. You can build a complete end-to-end system on your desk for under two hundred euros and understand the whole stack before you think about real-world deployment.
HOST_A: Alright. Let's synthesise. Where is this technology going over the next five to ten years?
HOST_B: I think the fundamentals are locked in. LoRaWAN is the established protocol for large-scale battery-powered stationary sensor networks. The standard is mature, the ecosystem is enormous, the cost is proven. This isn't going away.
HOST_A: I'd agree on the stability point. But I think the interesting competitive pressure is from NB-IoT. Mobile operators have a strong incentive to push cellular IoT because they already own the infrastructure. As NB-IoT hardware costs and power consumption continue to drop, the gap with LoRaWAN narrows.
HOST_B: Maybe in five years. But right now for the sweet spot use cases — agricultural sensors, smart metering, environmental monitoring — LoRaWAN's economics are still compelling. And private network deployments don't change regardless of what operators do.
HOST_A: The satellite integration is something I find genuinely exciting. Actility and Lacuna Space are flying low earth orbit satellites that carry LoRa receivers. You can now send a LoRa packet and have it received by a satellite passing overhead.
HOST_B: Which changes the economics for very remote deployments. A livestock tracker in the middle of the Australian outback, hundreds of kilometres from any ground gateway — it can still get data out via satellite. That's a fundamentally new capability.
HOST_A: And the specification is actively evolving. LoRaWAN 2.0 work is addressing the pain points — better FUOTA, better device management, improved security. The LoRa Alliance has over five hundred member companies. This is a large industry consortium.
HOST_B: The open-source stack matters enormously for long-term viability. ChirpStack, The Things Stack — these are production-grade open-source implementations. The protocol doesn't depend on any single company's financial health. Compare that to Sigfox.
HOST_A: I think the maker and engineer community is also an underappreciated driver. There's a huge amount of innovation happening in the form of open-source firmware, new sensor designs, novel applications. That grassroots energy feeds back into the commercial ecosystem.
HOST_B: One thing the industry needs to solve is the energy harvesting story. Right now most LoRaWAN deployments still rely on primary batteries. The next wave will be solar-harvesting devices that combine tiny solar cells with supercapacitors or rechargeable cells and run indefinitely in ambient light conditions.
HOST_A: That's already starting. Some of the newer RAK WisBlock modules include solar charging management built in. A sensor on a factory floor with fluorescent lighting above it can run indefinitely on a centimetre-square solar cell. No battery changes ever.
HOST_B: Another frontier is combining LoRaWAN with edge AI. Tiny machine learning models running on the microcontroller — analysing vibration data to detect machine faults, processing audio to detect anomalies — and only transmitting an alert when something interesting happens. Instead of streaming raw sensor data, you're transmitting derived insights.
HOST_A: That's a really interesting architectural shift. It solves the throughput limitation elegantly. If your device can determine locally that nothing unusual is happening, it doesn't need to send anything. When it does transmit, it's a meaningful event, not raw samples.
HOST_B: And the hardware is getting there. The nRF9160 and the ARM Cortex-M33 chips that power a lot of these sensors have enough compute for basic ML inference. TensorFlow Lite Micro runs on two hundred kilobytes of RAM.
HOST_A: The regulatory landscape is also evolving. The EU is actively pushing for mandatory IoT connectivity in infrastructure — smart metering is already law in many countries, smart water meters are coming. LoRaWAN is well positioned to be the default technology for mandated infrastructure modernisation.
HOST_B: My overall take: LoRaWAN found its niche and that niche is massive. Long battery life, wide area, low data rate, low cost. Those requirements describe an enormous fraction of all IoT deployments. The technology is going to be around for a long time.
HOST_A: And I'd add — the lessons of the last decade of IoT are important here. The technologies that succeeded did one thing well. LoRaWAN does its specific job better than anything else available. That's a durable position.
HOST_B: The thing I'd leave people with is: experiment. Buy a twenty-euro development board. Connect it to The Things Network. Send some data. Once you've done that, you'll understand the constraints and the capabilities viscerally in a way that no podcast can give you.
HOST_A: The community is genuinely welcoming. The documentation is good. The barrier to entry is low. And the skills translate directly to commercial projects if you want to go further.
HOST_B: Don't try to use it for everything — we've been clear about where it fails. But for what it's good at, LoRaWAN is one of the most elegant engineering trade-offs in wireless communications. Ten kilometres of range, five years of battery life, a few euros per year in connectivity. That's remarkable.
HOST_A: That's our show. Thanks for joining us for this deep dive into LoRaWAN. If you try a project after listening to this, we'd genuinely love to hear about it.
HOST_B: I'm Ryan. Get building.
HOST_A: And I'm Emma. We'll see you next time on Clawd Talks.