Daniel sent us this one — he's trying to build a parking occupancy sensor with an ESP32 and a LoRa radio, transmitter sitting next to his indoor parking spot, and he wants to know if the signal can punch through a few floors of concrete up to a receiver in the building. He noticed the frequency differences across regions, the regulatory limits on transmission power, and he's asking about the real-world gotchas — interference, competing signals, all the stuff that doesn't show up on the spec sheet. And honestly, this is the exact moment where LoRaWAN stops being a magic bullet and starts being a physics problem.
It really is. Because here's the thing — two G and three G are sunsetting, Wi-Fi can't reach three floors down through rebar, so LoRaWAN is the obvious choice for low-power wide-area IoT right now. But the gap between "this chip can do fifteen kilometers line of sight" and "I can't reach my parking spot two stories up" is where most projects die. And it's not a mystery — it's just that the regulatory constraints and the physical-layer behavior are completely non-obvious until you hit them.
The spec sheet optimism versus the concrete reality.
Literally concrete, yeah. So let's break down exactly what's happening when that LoRa packet tries to punch through three floors of reinforced concrete.
You've got your little ESP32 with an SX1276 radio, you're transmitting at eight sixty-eight megahertz or nine fifteen depending on where you live, and the signal just... And the first thing to understand is that LoRa isn't one radio — it's a dozen different radios depending on which country you're in.
The same silicon — the exact same SX1276 chip — operates on completely different frequencies depending on the region. In Europe you're on the eight sixty-eight megahertz ISM band. In North America you're on nine two to nine twenty-eight megahertz. In parts of Asia it's nine twenty-three. And these aren't just different numbers on a dial — they come with entirely different power limits, duty cycle rules, and channel plans.
You can buy a board off AliExpress, plug it in, and it's effectively illegal and non-functional depending on where you are.
In the US, the nine fifteen megahertz ISM band lets you transmit at up to one watt — that's thirty dBm ERP. In Europe, on the eight sixty-eight megahertz band, you're capped at twenty-five milliwatts, which is fourteen dBm, for most of the usable sub-bands. That's a sixteen dB difference right out of the gate. If you take a US-configured board to Europe, not only is it illegal, it won't even work with the local gateways because they're listening on completely different frequencies.
Before you even think about concrete attenuation, you've already lost sixteen deciBels just by being in the wrong regulatory regime.
That's just the power limit. Then you've got the duty cycle constraints. In Europe, under ETSI EN three hundred dot two twenty, the eight sixty-eight point zero to eight sixty-eight point six megahertz sub-band has a one percent duty cycle limit. That means if your device transmits for one second, it has to stay silent for ninety-nine seconds.
Which for a parking sensor sending a fifty-byte uplink every five minutes is totally fine. But if you think, oh I'll just poll it every ten seconds to get near-real-time occupancy data — congratulations, you've just been kicked off the network.
The gateway will drop your packets and The Things Network's fair-use policy will flag you. In the US, the FCC doesn't mandate a duty cycle limit on nine fifteen megahertz, so technically you could transmit more often — but public networks like The Things Network still enforce a one percent fair-use policy. So practically, you're in the same boat either way.
Then there's the sub-band fragmentation within the band itself, which is its own special nightmare. In Europe, the eight sixty-eight point seven to eight sixty-nine point two sub-band allows twenty-five milliwatts but only zero point one percent duty cycle. The eight sixty-nine point four to eight sixty-nine point six five sub-band allows five hundred milliwatts — that's half a watt — but only ten percent duty cycle. So you can't just crank the power. You have to pick the sub-band that matches your application's transmission pattern.
You're trading power for airtime. And that brings us to spreading factors, which is where the physical layer really gets interesting. LoRa uses these orthogonal spreading factors, SF seven through SF twelve. SF seven is fast — about five point five kilobits per second — but it has the shortest range. SF twelve is slow — two hundred ninety-three bits per second — but it can be decoded all the way down to minus one thirty-seven dBm, which is absurdly sensitive.
The tradeoff is time on air. A fifty-byte packet at SF seven takes about fifty milliseconds. The same packet at SF twelve takes roughly one point five seconds. That's thirty times longer. And on a one percent duty cycle network, that one point five seconds eats one point five percent of your allowance in a single transmission.
If you're on SF twelve and you transmit once every five minutes, you're fine — that's well under one percent. But if the network's adaptive data rate algorithm tries to push you to SF seven to save airtime, and your signal can't actually reach the gateway at SF seven, you lose packets. And ADR assumes a stable channel, which a parking garage absolutely is not.
Because cars move. People walk around. The channel changes constantly. ADR sees a moment of good signal, nudges you down to SF seven, and then a minivan parks between your sensor and the stairwell and suddenly you're offline.
Which brings us to the actual physics of concrete. The ITU-R P point two zero four zero model gives us some hard numbers. At eight sixty-eight megahertz, a twenty-centimeter concrete wall with rebar — which is basically every structural wall in a modern building — attenuates the signal by fifteen to twenty-five deciBels.
Let's do the math. You're in Europe, your transmitter is at fourteen dBm. The gateway's sensitivity at SF twelve is minus one thirty-seven dBm. That gives you a link budget of one fifty-one deciBels. But three floors of concrete slab with rebar — that's not three walls, that's three floor slabs, each one easily eating twenty dB. So you've lost sixty dB before the signal even leaves the building.
Now you're down to ninety-one dB of effective link budget. And you still need to account for the actual distance, any other walls, multipath fading, antenna misalignment, and the fact that the car itself is a metal box. If your sensor is inside the vehicle, you've just added another twenty to thirty dB of attenuation from the car body.
Your one fifty-one dB link budget evaporates fast. And there's a real case from The Things Network forum — someone reported losing thirty dB of signal just moving from a fifth-floor window to a ground-floor parking garage, with the gateway on the roof. Horizontal distance was only fifty meters. The vertical path through the building killed the link.
That's the thing that spec sheets don't tell you. "Fifteen kilometers range" is line of sight over flat terrain with clear Fresnel zone clearance. It's not "through a parking structure." A single parking level can be the equivalent of a kilometer of open air in terms of attenuation.
Then you add interference on top of that. The ISM bands are shared. In Europe at eight sixty-eight megahertz, you're competing with GSM-R for railways, some DECT cordless phones, and every other LoRa device in range. In the US at nine fifteen, Zigbee channels twenty-five and twenty-six overlap, some older nine hundred megahertz cordless phones, industrial RFID readers. And the biggest problem is other LoRaWAN devices.
LoRaWAN uses ALOHA-style random access. There's no listen-before-talk, no collision avoidance. If two devices transmit at the same time on the same frequency and the same spreading factor, both packets are lost. The network just... hopes they don't. And in a dense urban area with hundreds of devices per gateway, they do.
You've got concrete eating your signal, regulations capping your power, duty cycle limiting your airtime, ADR fighting you, and other devices stomping on your packets. And you're just trying to figure out if your parking spot is free.
Which is why the solutions are counterintuitive. Most people think "I'll just add more power" — but in Europe you can't, and in the US, more power doesn't help if the problem is multipath fading rather than simple path loss. If the signal is bouncing off concrete walls and arriving at the gateway out of phase, doubling your transmit power just gives you a louder cancelled signal.
The actual fix for indoor parking garages is to manually lock the spreading factor to SF twelve and disable ADR entirely. The network wants to optimize for throughput, but you need range. Accept the one point five second time on air, accept the battery hit, and stop letting the algorithm guess wrong every time a car moves.
There's a Reddit case study on exactly this — someone put a LoRa transmitter in a basement parking garage with the gateway on the tenth floor. At SF twelve, they got eighty percent packet success. At SF seven, zero percent. The ADR algorithm kept trying to push them to SF seven, breaking the link entirely. They had to manually lock SF twelve to make it work.
Eighty percent is not great, by the way. For a parking sensor, maybe it's acceptable — you miss an update here and there. But if you're doing anything safety-critical or real-time, that's a problem.
That's where you start looking at alternatives. NB-IoT uses lower frequencies — seven hundred to nine hundred megahertz — which penetrate buildings better. But you need a SIM card, a monthly fee, and the peak current draw is around two hundred milliamps, which is brutal for battery life. LoRaWAN wins on cost and battery life, but it loses on reliability in deep indoor environments.
The parking sensor project sits at this interesting intersection. It's exactly the kind of thing LoRaWAN was designed for — low data rate, infrequent updates, battery powered, cheap hardware. But the physical environment is about as hostile as it gets for sub-GHz radio.
That's before we even talk about antenna placement, which is where a lot of these projects get salvaged. A quarter-wave monopole at eight sixty-eight megahertz is about eight point six centimeters. For indoor-to-outdoor paths, an external antenna with three to six dBi of gain can make the difference between zero packets and eighty percent.
Higher gain means a narrower beam. A six dBi panel antenna pointed at the parking area will reject noise from the sides, but it requires precise aiming. If you mount it wrong, you're beaming your signal into a concrete pillar.
The gateway placement matters enormously. Put it as high as possible, near an external wall or a window. The signal path from a window down to the parking garage is way better than from a central corridor, because you're avoiding multiple interior walls. Every interior wall is another ten to fifteen dB.
The car itself is a variable attenuator. If the sensor is mounted inside the vehicle, you've got a metal Faraday cage around your transmitter. The fix is simple — mount the sensor on the ceiling or wall of the parking spot, not inside the car. But it's the kind of thing you don't think about until you've already installed it and nothing works.
Then there's the battery math, which is where spreading factor choice really bites you. An ESP32 in deep sleep draws about ten microamps. Waking up, reading a magnetic sensor, and transmitting a fifty-byte packet at SF seven takes about fifty milliseconds at fifty milliamps. At SF twelve, the same packet takes one point five seconds at fifty milliamps.
If you transmit once per minute, SF seven gives you about three and a half years on a two thousand milliamp-hour battery. SF twelve gives you about six months. For a parking sensor sending once every five or ten minutes, both are fine. But if you try to track real-time occupancy changes — every thirty seconds — you'll drain the battery in months, not years.
That's the thing Daniel's really asking about, I think. The gotchas aren't in the protocol spec. They're in the interaction between the protocol and the real world. The regulations you didn't know about, the concrete you can't avoid, the algorithm that's trying to help but making things worse, the interference from devices you can't see.
The spec sheet says "kilometers of range." The building says "no.
What makes LoRaWAN genuinely different from the alternatives is that it's optimized for exactly this asymmetry. Wi-Fi and Bluetooth are designed for high data rate, low latency, two-way communication over short distances. Cellular IoT like NB-IoT or LTE-M gives you better building penetration and higher reliability, but you're paying for it with a SIM card, a monthly subscription, and power draw that's an order of magnitude higher.
Wi-Fi at two point four gigahertz through three floors of concrete is a non-starter. That's sixty to eighty dB of attenuation easy. Bluetooth's even worse — it's designed for the room you're standing in. LoRaWAN is the only thing in this space that says "I will trade basically everything — speed, latency, bidirectional reliability — for the ability to whisper across a building on a battery that lasts years.
That tradeoff is encoded in the physical layer. LoRa uses chirp spread spectrum modulation — the signal sweeps across the channel bandwidth in a way that makes it incredibly resistant to noise and interference. That's how you get that minus one thirty-seven dBm sensitivity at SF twelve. For context, that's below the thermal noise floor. The receiver is literally pulling the signal out of noise you can't even measure with basic equipment.
Which is wild when you think about it. The gateway can hear a transmission that's quieter than the random electromagnetic background of the universe. But concrete doesn't care how clever your modulation is. It's just a physical barrier.
And this is the core tension Daniel's walking into. LoRaWAN occupies this unique niche — sub-gigahertz ISM bands, kilometers of range at sub-two-fifty kilobits per second, optimized for infrequent sensor uplinks. A parking occupancy sensor is the textbook use case. An ESP32 with an SX1276, a magnetic or ultrasonic sensor, waking up every few minutes to send a handful of bytes saying "occupied" or "free" to a gateway somewhere upstairs. The protocol was built for this.
The advertised "kilometer range" is line of sight over open terrain with clear Fresnel zones. The moment you put three floors of reinforced concrete between the transmitter and the gateway, you're not in Kansas anymore. You're in a world where every floor slab is eating fifteen to twenty-five deciBels of your signal, per the ITU model, and you only started with a link budget that looks generous on paper but vanishes fast in practice.
That's really the setup here. Daniel's got the right hardware, the right use case, the right protocol. Everything on paper says this should work. But the building is a radio obstacle course, the regulations are region-locked in ways that aren't obvious when you're buying a board online, and the network's own optimization algorithms can actively sabotage a marginal link.
The question isn't "can LoRaWAN do this." It's "what do you need to know to make LoRaWAN actually do this in a building that's doing everything it can to stop you.
Okay, so it's a mess. But here's exactly what you can do to make your parking sensor actually work. Four things, in order.
First, before you buy anything — check your regional frequency allocation. An eight sixty-eight megahertz board will not talk to a nine fifteen megahertz gateway. They're different radios as far as the network is concerned. Use a multiband module like the SX1276, which covers both, and configure the correct band in software. If you're in Europe, you're on eight sixty-eight. In the US, nine fifteen. Get this wrong and nothing else matters.
Second, for indoor parking garages, manually lock your spreading factor to SF twelve and disable ADR. The network will try to optimize you down to SF seven for throughput, and it will break your link every time a car moves. Accept the one point five second time on air, accept the battery hit, and stop letting an algorithm that assumes a stable channel make decisions for a channel that is anything but stable.
The Reddit case study we mentioned — basement to tenth floor, SF twelve gave eighty percent packet success, SF seven gave zero. ADR kept pushing to SF seven. The fix was manual lock. It's not elegant, but it works.
Third, gateway placement. As high as possible, near an external wall or a window. The signal path from a window down to the parking garage avoids multiple interior walls, each of which is another ten to fifteen dB. Use an external antenna with three to six dBi of gain. A quarter-wave monopole is fine for line of sight, but you're not doing line of sight. Get a proper antenna and point it at the parking area.
Fourth — test before you deploy. Walk around the parking garage with a LoRa sniffer, which is just a second ESP32 with a LoRa module running an RSSI scan. Map the actual signal strength at each parking spot. Don't assume the link budget math works. Concrete is unpredictable. Rebar placement, slab thickness, nearby metal — all of it varies. The ITU model gives you a range of fifteen to twenty-five dB per wall. That's a ten dB spread. You need to measure.
These four steps will get you from "why doesn't this work" to "my parking spot is free" without tearing your hair out. Check the band, lock the spreading factor, place the gateway smart, and measure the actual signal. Everything else is optimization.
Those four steps will get you a working prototype. But the bigger question is: will LoRaWAN still be the right choice in five years?
That's the thing. As more people figure out that LoRaWAN is the answer for these kinds of projects, the ISM bands get more crowded. And ALOHA doesn't scale gracefully. A few hundred devices per gateway, and you start seeing collision rates that make eighty percent packet success look like a good day.
It's the fundamental tension of unlicensed spectrum. The barrier to entry is zero — no SIM card, no carrier contract, just buy a board and start transmitting. Which is exactly why it's so popular. But that same zero-barrier means everyone else is doing it too, and there's no central coordination. In a dense urban area, you could have dozens of buildings all running parking sensors, water meters, temperature loggers, all sharing the same eight channels.
The protocol's response to congestion is basically "transmit again later and hope." Which works fine at low density. Falls apart fast when you've got three hundred devices all hoping at the same gateway.
LoRaWAN one point one adds some improvements — better roaming between gateways, multicast support for firmware updates. But it doesn't fix the physics. Concrete is still concrete. The ISM bands are still shared. And the ALOHA access method is still fundamentally the same.
For deep indoor applications like Daniel's parking sensor, I think we're going to see a shift. As LTE-M and NB-IoT module costs keep dropping — some are already flirting with the five dollar mark — the calculus changes. You get better building penetration from the lower frequencies, you get coordinated spectrum access instead of random ALOHA, and you get carrier-grade reliability.
The tradeoff flips. Right now LoRaWAN wins because it's cheap and the battery life is incredible. But if an NB-IoT module costs five bucks and lasts two years on a battery instead of five, and it actually works reliably from a basement parking garage — a lot of people are going to make that trade.
The question Daniel's parking sensor is really asking, underneath all the spreading factors and duty cycles, is "how much reliability do I actually need, and what am I willing to pay for it?" Right now, the answer for most hobbyists is LoRaWAN with SF twelve locked and a prayer. In five years, it might be a five-dollar cellular module that just works.
That's the arc of this whole space. The protocols don't change that fast, but the economics do. What's a frustrating physics puzzle today becomes a solved problem tomorrow — not because the physics changed, but because the alternative got cheap enough to stop caring about the physics.
Until then, lock your spreading factor, point your antenna out the window, and don't trust the algorithm.
Now: Hilbert's daily fun fact.
Hilbert: In the 1960s, researchers analyzing dust deposits on the Azores discovered that Saharan dust storms were transporting not just mineral particles but also measurable quantities of organophosphate pesticides — chemicals that had been applied to crops in North Africa thousands of kilometers away and lifted into the upper troposphere by convective storms over the Sahara.
The Sahara was air-mailing pesticide to the middle of the Atlantic.
This has been My Weird Prompts, with me, Herman Poppleberry, and my brother Corn. Produced by Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you listen — it helps. We'll be back soon with another prompt from Daniel.
