Smart Places and Infrastructure · Study deck
Smart Parking Sensor Contracts
LoRaWAN is short for Long Range Wide Area Network.
Ada is your guide for this deck.

After studying this chapter
Learning objectives
You will be able to:
- Explain how a magnetometer detects vehicle occupancy by measuring local magnetic-field distortion.
- Identify why adjacent-bay vehicles create false positives and how per-sensor baselines and thresholds reduce crosstalk.
- Describe why event-driven LoRaWAN reporting saves battery but needs a recovery heartbeat.
- List the field metadata needed to scale a parking deployment without guessing.
Major section
Start With the Story
LoRaWAN is short for Long Range Wide Area Network.
- A parking sensor may use it to report when a bay becomes free or full.
- One wrong reading can waste time and trust.
- The system must prove how it sensed the car, how sure it was, when the result was sent, and what happened when no new message arrived.
Major section
Start With the Story (continued)
A magnetometer is a sensor that measures a nearby magnetic field.
- A vehicle can bend that field.
- Cars in the next bay can also bend the field, so the team must test them too.
- Sending only when a bay changes can save battery power.
- It helps the system spot a silent or lost sensor.
Major section
Start With the Story (continued)
A heartbeat is a small message sent at set times even when nothing changed.
- This plain chain leaves out exact field limits, radio settings, and city rules.
- The Practitioner section records those site facts.
- The map should not show an old state as fresh.
- A bay state needs a time and a clear source.
Major section
Motion Marley's Math Bridge: Magnetic Field to Comparator Voltage
The mathematical gist: A Hall junction gives VH=IB/(nqt).
- With a 1.00 mA bias, 10 micrometre InSb film, and 12.0 microtesla field swing, the raw signal is only 0.375 microvolts.
Major section
Smart Parking Magnetometer Case
A city puts an in-ground sensor in each parking bay to report whether it is occupied, feeding a "find a free space" app.
- The sensor detects a car with a magnetometer: a parked vehicle's steel body distorts the Earth's magnetic field, about 25-65 microtesla, at the sensor, and that change signals occupancy.

Major section
Smart Parking Magnetometer Case (continued)
To see how small the field-sensing part really is, look at the breakout board in Figure: This ACS712 board is a Hall-effect sensor implementation.
- That chip is the whole sensing element, and it turns a magnetic field into a voltage with no moving parts.
- Mechanism note: a magnetometer senses a car by its distortion of Earth's roughly 50 microtesla field; occupancy is reported over LoRaWAN.
- That framing also separates local context from reusable pattern.

Major section
Smart Parking Magnetometer Case (continued)
The mechanism sounds simple but hides a real engineering problem the case must confront: a magnetometer cannot see a bay's boundary, only a magnetic field, and cars in neighbouring bays distort that field too.
- The hard part is telling this bay's car from the neighbour's.
- The map in Figure: Case-study reading frame shows how far an occupancy reading has to travel before it can support any city-level claim.
- Band one puts parking beside lighting, waste, and water, so the bay sensor is one feed among several.
- A deployment lesson is transferable only when that whole chain is visible.
Major section
The Cross-Detection Problem
Parking sensors need installation depth, bay geometry, empty-baseline sample, adjacent-vehicle test result, firmware version, LoRaWAN spreading factor, gateway RSSI/SNR, battery estimate, and complaint history.
- This cross-detection is the defining real-world challenge of magnetic parking sensors, and it is solved by calibration, not by a bigger sensor.
- A neighbour's car produces a smaller shift that the threshold rejects.
- Setting the occupancy threshold at 6 microtesla catches the real occupant and rejects the neighbour.
Major section
The Cross-Detection Problem (continued)
Each sensor learns its own empty-bay baseline field and flags occupancy only when the local change exceeds a threshold set above the crosstalk a neighbour's car produces.
- Worked example: A sensor calibrated to a 50 microtesla baseline sees a 12 microtesla swing when a car parks directly over it, but only a 3 microtesla swing from a truck in the next bay.
- For practitioners, the case-study question is what must be recorded before rollout expands.
- Those records let teams tune thresholds without guessing and separate a weak sensor, weak model, weak network, or weak workflow.
Major section
Event Reporting Failure Mode
To pursue a multi-year battery target on LoRaWAN, the sensor reports on state change rather than streaming periodically: it sends a message when a bay transitions between vacant and occupied.
- In EU868, the applicable duty-cycle or channel-access constraint depends on the sub-band, device, and network configuration; 1% is a common case, not a universal LoRaWAN limit.
- Event-driven reporting still has a specific failure mode: an uplink may be configured as confirmed or unconfirmed, but either can ultimately be lost after interference or exhausted retries.
- Getting the balance right is what makes the deployment trustworthy rather than merely cheap.
Major section
Event Reporting Failure Mode (continued)
If the only "now occupied" message is lost, the app shows the bay free until a later update.
- Worked example: A car leaves a bay and the sensor's "vacant" uplink is lost to interference.
- With pure event reporting the app wrongly shows the bay occupied for hours, sending drivers past an empty space.
- The same heartbeat lets the backend flag a sensor that has gone silent for a day as failed.
Major section
Event Reporting Failure Mode (continued)
The four-hour interval bounds stale-state error only under that delivery assumption; a lost heartbeat extends the error to the next successful update.
- The transferable decision from this case, pairing change-events with a recovery heartbeat and an explicit delivery assumption, applies to any lossy, low-power, event-driven IoT link.
- Under the hood, the backend should treat every parking or maintenance event as a state update with evidence attached.
- A parking message should include device id, bay id, sequence number, measured field delta, threshold version, battery, RSSI/SNR, gateway id, event timestamp, and whether the message is a change event or heartbeat.
Deck summary
Key takeaways
LoRaWAN is short for Long Range Wide Area Network.
- A magnetometer is a sensor that measures a nearby magnetic field.
- A heartbeat is a small message sent at set times even when nothing changed.
- The mathematical gist: A Hall junction gives VH=IB/(nqt).
- A city puts an in-ground sensor in each parking bay to report whether it is occupied, feeding a "find a free space" app.
Retrieval practice
Recall check 1 of 5

Ada says: answer from memory, then check your reasoning.
Q1Using Phoebe's worked Hall-element numbers, why does a parking sensor need low-noise amplification before a microcontroller can classify the small occupancy field change?
Show answer
Answer: C see answers page
Retrieval practice
Recall check 2 of 5

Ada says: answer from memory, then check your reasoning.
Q2A city wants to copy a well-known parking pilot. What evidence should it demand before adopting the design?
Show answer
Answer: C The full chain shows what caused the outcome and what must transfer.
Retrieval practice
Recall check 3 of 5

Ada says: answer from memory, then check your reasoning.
Q3Per this chapter's smart parking case, why is occupancy state reported over LoRaWAN rather than a high-bandwidth wireless link?
Show answer
Answer: B because it offers long range, low power, and acceptable underground performance in the bay housing.
Retrieval practice
Recall check 4 of 5

Ada says: answer from memory, then check your reasoning.
Q4In this chapter's worked crosstalk example (12 microtesla swing from the actual occupant, 3 microtesla swing from a truck in the next bay), why does setting the occupancy threshold at 6 microtesla work?
Show answer
Answer: B see answers page
Retrieval practice
Recall check 5 of 5

Ada says: answer from memory, then check your reasoning.
Q5Why does a change-only (event-driven) parking sensor also need a periodic heartbeat?
Show answer
Answer: C A change-only sensor only reports when its state flips, so a dropped transition message over a lossy LoRaWAN uplink leaves the backend holding a stale state indefinitely.
Print reference
Answers 1 of 3
Answer key.
- C · Phoebe's worked numbers compute the Hall voltage from the chapter's own occupant swing (12.0 microtesla) as about 0.375 microvolts, then note this needs roughly 26,700x (about 88.5 dB) of gain to reach a usable comparator level -- exactly why a production Hall-effect parking sensor is a chopper-stabilized amplifier chip built around this junction, not a bare Hall element with a wire to a microcontroller pin.
- C · The full chain shows what caused the outcome and what must transfer.
Print reference
Answers 2 of 3
Answer key.
- B · because it offers long range, low power, and acceptable underground performance in the bay housing.
- B · The chapter's worked example: a car in the bay produces a 12 microtesla swing, a truck in the next bay produces 3 microtesla of crosstalk, and the threshold is set at 6 microtesla -- above the crosstalk, below the direct occupant -- so the sensor 'catches the real occupant and rejects the neighbour.'.
Print reference
Answers 3 of 3
Answer key.
- C · A change-only sensor only reports when its state flips, so a dropped transition message over a lossy LoRaWAN uplink leaves the backend holding a stale state indefinitely.