A LoRaWAN Smart Parking System That Skips WiFi at Every Lot

Urban drivers spend an average of 20 minutes per trip hunting for parking, and that circling accounts for roughly 30% of unnecessary traffic in congested city streets. My M.Tech mini-project, LoRaWAN Smart Parking System, tackled the plumbing problem behind that statistic: how do you report real-time slot occupancy from many scattered parking lots without paying for internet access at every single one of them?

The cost problem nobody mentions

Most smart-parking proposals I found in the literature survey — Bluetooth-tagged vertical parking, RFID with I2C car-parking frameworks, AI-driven image processing, GPS-plus-Android tracking, ZigBee-and-GSM reservation systems — solved detection well but quietly assumed every parking lot gets its own internet connection. That assumption is where the cost hides: an ESP8266 or Arduino board with WiFi at each lot means an ISP subscription, or at least a WiFi network, at each lot. Multiply that by a city's worth of parking lots and the "smart" part of smart parking gets expensive fast before a single spot has been detected.

The fix is almost embarrassingly simple once you see it: only the receiver needs internet. Everything upstream of it can talk over free spectrum instead.

The architecture: many transmitters, one receiver

The system has three moving parts:

Lot A ─┐
       │ LoRa (868–915 MHz, up to ~5 km)
Lot B ─┼──────────────────────────────▶  LoRa Receiver ──WiFi──▶ IBM Watson IoT ──▶ Android / browser
       │
Lot C ─┘

• Each parking slot has an ultrasonic sensor measuring the distance to whatever is above it.
• A TTGO ESP32-LoRa transmitter board at each lot reads its sensors and sends the slot states over LoRa, a long-range, low-power radio link — no WiFi, no SIM card, no per-lot internet bill.
• One TTGO ESP32-LoRa receiver, placed roughly equidistant from the lots it serves and within LoRa range (up to about 5 km line-of-sight), collects every lot's data and is the only device that needs a WiFi connection. It bridges the data to IBM Watson IoT and to a small local web server so the status is checkable from an Android phone.

Instead of three WiFi modules — one per lot — the system needed three LoRa transmitters and a single receiver with the only internet connection in the whole deployment. That's the entire cost argument in one sentence.

Detecting a parked car

Occupancy detection deliberately avoids anything clever: measure distance, compare to a threshold.

distance = ultrasonic_reading()  // in cm

if distance < 25:
    flag = 1   // slot occupied
else:
    flag = 0   // slot vacant

Twenty-five centimetres was the calibrated threshold for "something is now where the ground used to be." Each transmitter packs its slot flags together with the name of the lot before sending, because the receiver hears from multiple lots and needs to know whose flags it's looking at — a parking system that can't tell Lot A from Lot B is not a parking system, it's noise.

Placing the receiver: an antenna problem, not a software problem

With three lots and one receiver, the interesting engineering question isn't in the code — it's geometry. LoRa's range depends heavily on line-of-sight and obstructions, so the receiver has to sit at a point that's realistically within range of every transmitter it's meant to hear. For three lots, that's finding a rough centroid; for a city block, it might mean a receiver on a tall building. The report's own framing — "if we have three parking lots, we find a point which is nearly in range from the three lots" — is a reminder that IoT projects live or die on RF planning as much as firmware, and no amount of clean code fixes a receiver placed behind three buildings from its transmitters.

The hardware: one board, two roles

The transmitter and receiver are the same board, a TTGO ESP32-LoRa module — a 0.96" OLED, a Li-ion charger, and an SX1276-based LoRa radio on 868–915 MHz, programmable from the Arduino IDE with the ESP32, OLED, and LoRa libraries. Using identical hardware for both roles is a deliberate simplification: one bill of materials, one firmware toolchain, and the only difference between a "transmitter" and a "receiver" is which sketch you flash and whether WiFi credentials are configured.

What shipped, honestly

This was a mini-project prototype, not a production rollout: three lots, one receiver, occupancy flags flowing to IBM Watson IoT and readable from a browser by hitting the receiver module's IP address, with a status view intended for an Android phone. What it proved is the part that matters — that a star network of cheap radios reporting to one internet-connected receiver is a real, working alternative to WiFi-per-lot, at a fraction of the deployment cost. Scaling that from three lots to a city is a network-design problem, which is exactly what part two digs into: the LoRaWAN protocol standard this project's research pulled from, and how a production deployment would use gateways, device classes, and frame types to go from "three sensors and a receiver" to "a citywide sensor network."

Common pitfalls

1. Assuming every node needs internet. The entire cost saving of this design comes from inverting that assumption — only the aggregation point needs to be online.
2. Skipping the threshold calibration. 25 cm is right for a sensor mounted at a specific height over a specific slot type; copy the number without recalibrating and you'll misclassify motorcycles or trailer hitches.
3. Ignoring RF line-of-sight. LoRa's long range is a best-case number. Concrete, foliage, and terrain eat into it fast — always survey before committing to a receiver location.
4. Sending flags without a lot identifier. A receiver hearing from multiple transmitters needs to disambiguate; an anonymous flag is worthless the moment you have more than one lot.
5. Treating the Android view as an afterthought. A parking system nobody can check while driving is a data-logging exercise, not a smart-parking system — the point is that a driver checks before arriving, not after circling for twenty minutes.

FAQ

Want help with IoT sensor networks or a Laravel build in Dubai, UAE? Get in touch.