Glee hardware research: what should the sensor be?

Live at research.gleepark.me. This folder is updated continuously by a research loop: hypotheses, experiments (code + data + results) and the current recommendation. Nothing here has been tested on a street yet unless it says so.

The question

What hardware tells a city, in near real time, whether each on-street parking space is free? It must be cheap enough to cover whole streets, easy enough that a city will let us install it, and right often enough that drivers trust the map. The form factor is open. It doesn't have to be "cheese" (the thin sheet stuck under the car).

Breaking it down

Hypotheses

Experiments

Provolone v0 (designed, not yet built)

A printed box strapped to a meter post with two hose clamps: American cheese's boards, the XM125 behind a 1.5 mm window (about half a wavelength at 60 GHz in PETG), a power bank. The whole box is aimed: turn it on the post until the line on the lid runs parallel to the curb, and it faces 55° into its space. Build, aim and test steps: hardware/provolone/README.md.

Reports

• Every way to detect a parked car: methods, accuracy, power, prices, what vendors use
• Deploying on Bow Street: permits, winter, poles, pilots elsewhere, questions for the city
• What a magnetometer really sees under a car: measured fields, dead zones, drift, datasets
• Parts for a meter-pole radar: XM125 beam/power/I2C, FCC, Cambridge poles, D-cell battery, clamps
• Mounting on private buildings instead: glass loss at 60 GHz (clear 2.5-10 dB, low-E 22-45 dB one-way), Cambridge rules for boxes on facades and in windows, historic district, owner deals, mains power, a glass test protocol
• Who decides, and what it costs, to put a sensor on a Cambridge meter post: owner (Department of Transportation), Pole & Conduit Commission, no federal fee cap, Surveillance Ordinance, precedents (Burlington VT, Milwaukee, Bend, Boston), insurance, 9 questions to send
• Provolone v1 bill of materials: every part priced at 100 / 1,000 / 10,000 units, XM125 vs bare A121, cells and pulse capacitors, FCC path (A121 carries a limited modular grant), cheapest credible build
• Can a stuck-on sheet stay in over winter?: surface sensors in snowy cities, what survives plows (markers, tape, speed cushions), Cambridge plowing, glues in the cold, field-test protocol
• Rain, snow, slush and a 60 GHz radar: losses through each layer on the window, window thickness, coatings, how vendors handle it, firmware rules

Current direction

Updated after Experiments 1-10 and four research reports. Nothing below has been tested on a street yet.

The recommended system: a radar on the meter post ("Provolone"), LoRaWAN to our backend, sold as occupancy data.

Cheese's role: the learning device. American cheese (arriving now) gives the first real under-car and on-pole data: magnetometers + radar + radio signal, logged at 1 Hz. Swiss cheese is on hold until that data says the in-road option is worth building; if it is, it's a seasonal device on non-emergency streets, or a flush-mounted puck.

The two things that decide the most: (1) The city's answer on permission and fees, now first: the questions are ready in the city report (who approves; any fee, and could a pilot be waived or charged per block; does the Surveillance Ordinance apply; is Bow Street allowed). Never install anything without written permission: Cambridge ended its Flock contract after cameras went up "without the City's awareness". (2) Experiment 4: the XM125 on a real post next to real cars (Provolone v0, printable now; the radar is in stock at SparkFun).

If the fee comes back high: the radar and firmware carry over to placements that don't use city poles: a box on a private building facade or in a ground-floor window looking at the parking lane (owner's permission, no city fee; H10, untested), or selling to private lots and garages first.

Next

• Weather → firmware and box (done this tick): pole mode treats a strong return closer than 45 cm (snowbank, slush, someone leaning on the post) as "blocked": it holds the last state, reports unknown after 10 min, never "free" (sim_pole passes). Box: rain hood over the window, 1.2 m mounting height, vent/desiccant for v1. Still to do: the "canary" check (learned empty-street returns all dropping >10 dB at once = window blind), and for in-road, flag "radar blind" so the magnetometer decides.
• Provolone v0: designed (above). Printable now; needs the XM125. Range gate raised to 4 m (Exp 3 re-run at 55°: 100 % vs 99.5 % at 3 m). Still open: "blocked" detection for snowbanks, and a radar strength threshold to separate people from cars (Exp 7). v1: D-cell (LS33600 + pulse capacitor, 10+ years), IP67 box on a stainless band, tamper alarm, FCC label + Part 15B.
• Bow Street site survey, now shorter (Exp 14 covered spaces, trees, buildings and demand from open data): only what the data can't show: meter post positions and diameter, single or twin heads, height under the head, and photos of the facades at the 22 facade-ready spaces. Start pilots at the busiest spaces (the 30-minute spaces BOW-0001..0007 and BOW-0047..0055).
• Data-logging mode: built. scripts/cheese_log.sh flash then record <note>: both magnetometers' 3 axes + radar peaks/distance/strength + states at 1 Hz into research/data/*.csv (runbook: hardware/CHEESE_BRINGUP.md). Still to add: RSSI per uplink from the backend side (H6).
• Firmware v2 for any magnetometer design: event-based detection (latch on the arrival transient, low hold threshold, release on a departure transient), gradient as a veto rather than a requirement, baseline frozen while occupied (magnetics report).
• Swiss cheese v2: add an A121 radar footprint to the board (~$10), so the in-road learning device also tests radar.
• XM125 supply: DigiKey shows 0 in stock with a 16-week lead time, but SparkFun lists SEN-24540 in stock at $49.95 (checked Nov 8). Order from SparkFun. Board is 50.8 × 25.4 mm per SparkFun; the Provolone box is updated for it.
• Order one XM125 radar ($50) and plan Exp 4 with American cheese: radar under the car and on a pole, alongside the magnetometers, with RSSI logged.
• Hardware critique (docs/HARDWARE_CRITIQUE.md, merged Nov 7). Fixed: the P0 detector bug (an occupied space declared free after ~6 min whenever both magnetometers agreed; big uniform changes learned into the baseline); magnetometer B read fresh with A (every sample on the kit); sensor retries no longer stop after 255 failures; every state change is re-sent once 60 s later (TTN's ~10 downlinks/day rule out confirmed uplinks for ~30 changes/day). All as host tests. Still open: a measured time base across sleep, and an explicit "uncertain" state for the magnetometer-only build.
• Glass test (if the city fee comes back high; facade report): with the XM125, measure a metal plate's echo at 3 m through picture-frame glass, a 6 mm offcut, clear double glazing and low-E, at 0/30/50°; lighter-test Bow Street's windows for coatings. Two-way loss ≤ 10 dB: windows work; > 25 dB: facade or nothing.
• Winter field test for in-road sheets (H8, protocol in the winter report): 3 dummy sheets on Bow Street's even side with different edges (square, 1:10, dome), paint marks beside each; after every plowable storm and monthly, log present/moved, edge lift (feeler gauge), scrapes, ice under edges. Install on a dry afternoon in November (glues need ≥ 4-10 °C). Three sheets can't measure a loss rate (0 of 3 lost only bounds it below ~63 %); they show whether the blade reaches the lane at all. Any loss keeps winter removal as policy.
• Butyl peel test on cold asphalt (Exp 10's deciding unknown): a pad on an asphalt offcut in the freezer at -5 °C, pull sideways at one edge with a luggage scale. If it holds well over 2 kN (200 kg), the in-road picture changes.
• Decide the first product (Exp 9): per-space guidance on the busiest blocks (every space sensored) or a block-level heat map for the city (sample 25-50 %). It sets how many units we build.
• Send the city questions, now the top priority: 9 questions, most plan-changing first, at the end of the city report. They go to the Department of Transportation (Street Management runs the meters). A fee over ~$67/unit/yr breaks the pole sensor's economics (Exp 8 fee sweep).

Experiment 10: does a stuck-on sheet survive a winter of snowplows?

A physics model of a plow blade meeting the sheet, run over a simulated winter of plow passes (4,000 winters per case, research/sim/snowplow.py). The sheet is Swiss cheese's A4 footprint (297 × 210 mm), 8.5 mm tall on its glue with 1:4 beveled edges today.

One pass: why the bevel doesn't save it

At road speed a plow can't lift its blade over a 9 mm bump in the few milliseconds a 1:4 ramp gives it, so the push on the sheet is whatever makes something give first: the plow's spring-loaded edge folds back, a rubber edge bends, or the glue lets go. Typical values for today's design:

What the glue can hold against a push at one edge (likely values): butyl pad 1.9 kN, hot-melt bitumen 18.7 kN, epoxy 28.1 kN. Butyl is weaker than the push from every kind of plow; bitumen and epoxy beat pickup and truck plows but not a loader bucket.

A whole winter

Share of sheets still attached in spring ("survives") and with an undamaged bond ("unharmed").

snow-emergency route (Bow St odd side)

regular street (Bow St even side)

Sheets lost, by the plow that took them: city dump truck, trip moldboard 54 %, loader / backhoe bucket (no give) 23 %, pickup / one-ton with trip edge 20 %, rubber or urethane edge 2 %.

Reading

• Today's design (butyl, 8.5 mm, 1:4) does not survive a plowed winter. On the snow-emergency side it's torn off almost every time; on the regular side ~38 % make it to spring, and only because the blade never reached them or rode over hardpack.
• With butyl, nothing helps: every plow pushes harder (1.5-50 kN) than a butyl pad holds at one edge (~2 kN), so shape, height and ramps change little. Butyl's cold strength is the one number that could overturn this, and nobody publishes it: the peel test on cold asphalt (CHEESE_DESIGN.md) is now the most valuable bench test for the in-road option.
• With a strong glue, shape decides: epoxy with 1:20 ramps survives ~93 % of emergency-route winters, flush in a milled pocket ~98 %. A plow at speed can't lift its blade over a step in time, so the lower and gentler the step, the smaller the push; a flush sheet is squashed past without lifting the blade.
• Check against the real world: recessed road reflectors lose < 1 % a winter and surface markers ~10 %/yr (winter report); the model's flush/epoxy and ramped/epoxy cases land in the same range.
• But a strong glue or a pocket gives up the sheet's selling point. Epoxy and milling mean road work, a permit and no easy removal: that's the cored puck again (Exp 8: ~1.6x the pole sensor's cost). Installation is also limited to dry days above ~4-10 C, so not December-March.
• Loaders are the worst case (no give, 50 kN pushes): they work where snow is piled, which is the parking lane after big storms.
• So: stuck-on sheets come out for winter (or skip the snow-emergency side entirely); the pole sensor covers winter. The dummy-sheet field test on Bow Street's even side tells us how often the blade really reaches the parking lane there.

Assumptions that decide the answer (all estimated; replace with measurements): cold bond strength of butyl pads (0.03-0.3 MPa assumed; nobody publishes it, CHEESE_DESIGN.md calls for a peel test), the force at which plow edges trip (2-30 kN assumed; manufacturers give no numbers), the plow mix on Cambridge streets, and how often the blade reaches bare pavement in the parking lane. Not modelled: the sheet cracking before the glue lets go, ice bonding the sheet in place, abrasion (small: steel sliding over the top wears microns per pass).

Sources for the numbers used: snowplowable markers sit in epoxy-set castings in milled grooves; Vermont found 93 % of an earlier snowplowable marker type damaged (VTrans); hot-melt bitumen marker adhesive bond >= 1.4 MPa (Wyndham spec 853); epoxy marker bond >= 500 psi at 77 F (TxDOT/CTR); butyl pads need primer below 50 F (Pexco); trip edges are spring-loaded to fold back on manhole covers (Loegering, US 6073371).

Experiment 11: how many spaces can one gateway serve?

LoRaWAN US915 link budget with the 3GPP TR 38.901 urban street-canyon path-loss model (valid at 915 MHz), log-normal shadowing, 4,000 draws per distance (research/sim/link_budget.py). Device transmits at 20 dBm; gateway on a rooftop with a 3 dBi antenna. "Range" = the distance at which 90 % of uplinks reach a single gateway (each state change is also sent twice, tick 12). Spaces per gateway use 1,500-4,000 on-street spaces per km² (estimate for dense Cambridge blocks).

Radio cost per spreading factor

Range and spaces per gateway

Cells: 90 % range, then spaces within it at 2,500 spaces/km² (in brackets).

Reading

• On a post the radio is easy. From 1.2 m a pole sensor reaches a 10 m rooftop gateway ~2,102 m away at SF9; that circle holds ~20,823-55,529 spaces. Range stops being the limit; gateway placement (a rooftop with power and a view) and redundancy (each sensor should hear two gateways) set the count.
• Under a parked car it's ~4x shorter. The car and the ground cost ~20 dB: at SF10 the range is ~609 m (~2,911 spaces), and the sensor needs SF10 to get there. Still far more than Exp 8's 100-300 spaces per gateway.
• Range costs battery. At SF10 the radio alone averages ~43 µA, as much as a third of the pole sensor's radar budget; at SF7 ~7 µA. A pole sensor near a gateway can use fast data rates (ADR) and save most of that. Under a car, SF10 is the norm.
• Capacity isn't the limit at our traffic: even at SF10 one gateway carries ~3,996 sensors.
• For the cost model (Exp 8): range isn't what sets the gateway count for either design; sites (a rooftop with power and a view), redundancy (every sensor in reach of 2 gateways) and street geography are. Exp 8's 100-300 spaces per gateway was pessimistic: with ~1 gateway per 500-1,000 spaces its gateway share drops from ~$0.05-0.14 to ~$0.01-0.03 per space per month. Small next to the city-fee question, but the radio's battery cost (SF) is not small.
• Where our pilot gateway sits matters more than any of this: indoors, walls cost another 10-20 dB, which these numbers don't include. For the street pilot, put the ThinkNode on a rooftop or in a top-floor window facing Bow Street.

Assumptions to replace with measurements: the under-car and on-asphalt losses (American cheese's link test: RSSI/SNR under real cars vs on a post, logged by our backend), the street-canyon model on Cambridge's mix of 2-4 storey buildings (it ignores gateway height, which matters in practice), the spaces-per-km² density, and the gateway site. Our pilot data can't calibrate this (the pucks moved; no locations).

Experiment 12: can the pole radar tell a person from a parked car?

Exp 7's remaining error on a pole: people standing in the beam (~4 false "occupied" episodes a day). The radar gives each reflection's distance and strength. Monte Carlo (research/sim/people_vs_cars.py, 200,000 cases per setting): cars parked anywhere in the space (nearest reflection 0.7-2.5 m), people anywhere in the beam (0.4-4 m), two readings 5 s apart. Every rule is tuned to keep 99.5 % of cars; the table shows how many standing people still pass as a car.

Radar cross-sections at mm-wave are published as ranges, not one number (people are small dielectric reflectors, much weaker than vehicles: IET RSN 2019, JRC 24/77 GHz library, arXiv 1910.13706), so they're swept: car side at a slant 5 / 10 / 15 dBsm, person -12 / -8 / -4 dBsm.

Middle case (car 10 dBsm, person -8 dBsm)

All cases: standing people passed as a car

Reading

• Raw strength is the wrong number. A person at 0.5 m returns as much as a car at 2 m (1/d⁴): a plain strength threshold that keeps 99.5 % of cars passes ~10-50 % of standing people.
• Correcting for distance helps a lot when the gap is wide: strength + 40·log10(distance) estimates the reflector's size; with cars ~18 dB above people only ~1 % pass. When the gap is narrow (5 vs -4 dBsm) it fails (~54 %).
• Stillness over one pair of readings is weak: ~30 % of standing people move less than ~12 mm in 5 s.
• Stillness over 4 readings (15 s) is what closes it: combined with the distance-corrected strength, 0.07 % of standing people pass in the middle case and 1.6 % in the worst case swept (vs 21 % with 2 readings). Exp 7's ~4 false episodes a day become ~0.00-0.1. The price: an arrival is confirmed after 15-20 s instead of ~10 s. Departures can stay fast (a car leaving needs no stillness check).
• The cost: small vehicles. A size rule tuned on cars drops many motorbikes and scooters; stillness alone keeps them. For metered car spaces that's acceptable; it should be a setting.
• Firmware needs no new hardware: the data log already records peak distance and strength at every reading (scripts/cheese_log.sh). Exp 4 sets the two thresholds from real cars and real people, then they go into pole mode.

Assumptions to check in Exp 4: the RCS ranges (literature is at 77 GHz, the A121 is 60 GHz; near-range returns from a car side at a slant aren't far-field RCS), sway of a standing person (~3 cm in 5 s assumed), the A121's distance noise (~1-2 mm assumed), and that the strongest peak is the one we read (the firmware reads peak 0; the detector can sort by strength).

Test to add to the pole test plan: stand in the beam at 0.5, 1, 2 and 3 m for 60 s each (still, then fidgeting), and walk through it; log alongside a parked car at the same distances.

Experiment 13: does the radar work from a building facade? (H10)

Exp 3's ray-traced street (research/sim/pole_radar.py) with the radar moved onto the building across the sidewalk (research/sim/facade.py). Searched: sidewalk width 2 / 3 / 4 m, mounting height 2.5 / 3.5 m, down-tilt 15-45°, range gate from the curb to 0-1 m past a parked car. Then the best mounting per width with people walking under the beam (someone in the path on 0 / 15 / 40 % of readings) and with the unit aligned with its space or wherever the frontage allows (always aimed at the space's centre). A reading counts as "hidden" when people block most of the beam.

Best mounting per sidewalk width (no pedestrians)

With people on the sidewalk, and with imperfect placement

Reading

• Geometrically, a facade works as well as the meter post: looking down across the sidewalk at the middle of its space, the beam covers mostly its own space, and a range gate that starts at the curb ignores the sidewalk.
• People rarely hide the car (the beam comes down over most of the sidewalk), but they do walk into the range gate near the curb (last column): those echoes look like a car to the radar and must be rejected by Exp 12's size + stillness filter. Walking people move, so the stillness rule is at its strongest here; people waiting at the curb are the hard case, as on the pole.
• Placement along the frontage matters less than aim: a unit that can't sit exactly opposite its space still works when it's aimed at the space's centre, until the angle gets steep enough that the neighbour's car enters the beam.
• What the geometry can't answer is whether there's a facade at all (setbacks, driveways, blank walls, trees in the beam), whether the owner agrees, whether glass is in the way, and whether projecting over the sidewalk needs a city permit anyway: see the facade report.

Assumptions: flat sidewalk and street; no trees, signs or meter heads in the beam (Bow Street has street trees: a tree trunk in the path would look like a parked car and must be learned as background); people as 0.5 m boxes; the same idealised beam and box cars as Exp 3, so absolute accuracies are optimistic in the same way.

Experiment 14: Bow Street from the city's open data

A desk survey instead of a model: every metered space on Bow Street from the city's Metered Parking Spaces layer, Street Trees, building outlines and the street centreline from OpenStreetMap, and every parking ticket written on Bow Street since 2014 (tickets carry the meter ID). Raw downloads in research/data/cambridge/, analysis in research/sim/bow_street.py.

What's there

• 38 metered spaces (27 odd-numbered, 11 even-numbered IDs), 6.2 m long on average (5.5-7.0 m). Rules: 2 hour at $2.00/h (34), 30 minute at $2.00/h (4). None are smart meters.
• Tickets: 1,510 a year on Bow Street meters in 2023-25 (40 per space per year, busiest space 164); before 2020 it was ~3,292. Almost all are expired meters. Tickets mark where demand and enforcement meet, a rough map of which spaces matter most.
• Street trees in a pole radar's beam: for 1 of 38 spaces a street tree stands within 4 m inside the 55° beam from a post at one end of the space. Those units must learn the trunk as background (empty-space calibration) or be aimed from the other end.
• Building fronts: for 25 spaces a building stands straight behind the curb, 2.7 m away on median (1.3-6.4 m); 13 face no building within 25 m (open space, Harvard property set back, a corner). 22 of 38 have a building front within 6 m of the curb with no tree in the line of sight, the facade option's best case (Exp 13).

Per space

Reading

• The site survey shrinks to what the data can't show: meter post positions and diameters (not in the city layers), whether posts carry one head or two, mounting room under the heads, and photos of the facades that look usable.
• Trees are the main obstacle for both placements and the reason the firmware needs an empty-space calibration that records the static background (Acconeer's detector supports a recorded threshold).
• Pick pilot spaces from the ticket map: the busiest spaces see the most turnover, so they produce the most parking events per week of testing.

Caveats: OpenStreetMap building outlines and the city's space polygons are a few tens of centimetres off each other; "odd/even" here is the space ID's parity, not verified against the street side; trees use the city's trunk diameter; the 2022 ticket file appears to be missing from the dataset.

Experiment 15: real parking from a city's live in-ground sensors

Real data, recorded for this experiment: the City of Melbourne's open live feed of in-ground parking bay sensors (On-street Parking Bay Sensors, CC BY 4.0), polled every 2 minutes for 18 minutes starting 2026-11-08T04:12:23+00:00 UTC (a Sunday afternoon in Melbourne). Recorder: research/sim/melbourne_poll.py; data: research/data/melbourne/; analysis: research/sim/melbourne_analysis.py. Melbourne is the closest thing to our in-road option deployed at city scale, years after installation.

1. How many of the sensors still work?

6,324 bays in the feed. Share whose state had not changed for:

In a city centre a working bay changes state many times a day, yet 39 % of these haven't changed in a month and 19 % in a year. Mostly whole areas, not single sensors: a stuck bay's neighbours (within 30 m) are stuck 78 % of the time, a working bay's only 14 %; 95 of 410 zones are stuck entirely. That pattern fits streets closed for works, sections retired or network outages more than sensors dying one by one. Isolated stuck sensors (fewer than a quarter of their neighbours stuck), the likeliest individual failures, are ~4 % of all bays: a lower bound on single-sensor failure in a fleet years in the ground, each one a lane closure and a core drill to fix. A pole unit's battery and electronics can be swapped from the sidewalk.

2. How often does a working space change state?

3,475 bays were clearly working (changed in the last day or during the recording). They changed state 1.12 times per bay per hour on a Sunday afternoon, ~13 over a 12-hour day at that rate (our battery models assumed ~30 changes a day, Exp 7 and Exp 11). Occupancy at the end: 56 %.

3. How long do cars stay?

646 completed stays ended during the recording (arrival time known from the snapshot or the recording).

Very short "stays" are drop-offs, cars manoeuvring through the bay, or sensor flicker; our pole firmware deliberately doesn't report them (Exp 12: an arrival needs ~20 s of a still reflection).

4. Does every space need a sensor? (Exp 9, real blocks)

187 zones with 6+ working bays; 353 zone-moments when a zone was ≥ 80 % full with a bay free. Chance that a random subset of the zone's bays includes a free one:

Compare Exp 9's simulation: 37 / 66 / 87 % at 25 / 50 / 75 % coverage.

Caveats: one Sunday afternoon in Melbourne, not Cambridge on a weekday; Melbourne's feed reports what its own sensors decide (their errors are in the data); a 2-minute poll can miss a change that's reversed within 2 minutes (the feed keeps only the latest change), so very short stays are undercounted; zones are Melbourne's parking restriction zones, not blocks.

Experiment 16: how long does the pole sensor's battery really last?

Exp 7 said > 15 years on one D-cell, assuming ~0.5 mC per radar reading and 3 µA asleep. Acconeer's published figures say the radar module itself idles at 6.9-17.7 µA (off / hibernate) and that each reading at low rates carries a wake-up overhead (A121: ~0.2 mW at 0.1 Hz, ~1 mW at 10 Hz). The energy per reading, radar plus the XM125's own processor, is not published for our settings, so it's swept. Other inputs: RAK3172 + accelerometer asleep ~4 µA; ~20 state changes a day (Exp 15), each sent twice, + 24 heartbeats at SF7 (Exp 11); 3.6 V 17 Ah D-cell, 80 % usable, 1 %/yr self-discharge, 85 % converter (research/sim/power_budget.py).

Reading

• The battery claim hangs on one unmeasured number: the energy of one distance reading. Reading every 5 s, the cell lasts 15+ years at ≤ 1 mJ per reading, ~9-10 years at 2 mJ and ~5 years at 5 mJ (lithium D-cells themselves top out around 15-20 years, hence "15+"). Exp 4 must measure it (a USB power meter on the kit, or a Nordic PPK2 on the XM125's supply).
• Two cheap levers if it's high: read every 10 s instead of 5 (doubles the radar share's life; arrivals reported in ~40 s instead of ~20 s), and keep the XM125 in off rather than hibernate between readings (saves ~11 µA, costs a re-start per reading).
• Idle current is now a fifth of the budget: the XM125's own processor never sleeps below ~7 µA. On our own board with the bare A121 (BOM report, 10k units) the radar's idle drops to ~1 µA, a reason for v2 beyond cost.
• The radio is small at SF7 next to a gateway (~6 µA); at SF10 under bad coverage it adds ~33 µA (13 µA total at 1 mJ every 5 s).
• Check the SparkFun board for a power LED (SparkFun boards usually have one, with a jumper to cut): a lit LED alone draws ~1 mA, more than everything else together.

Sources: Acconeer A121 overview (Mouser) (power vs update rate), XM125 datasheet listing (idle off 6.9 µA, hibernate 17.7 µA), Acconeer A121 user manual (distance example 0.27 mA average), Acconeer exploration docs (power-save modes), SparkFun forum (board-level power untested).

Experiment 1: which architecture detects parked cars best?

Monte Carlo, 2500 situations (half occupied). Thresholds are chosen on one half of the trials and scored on the other. Generated by research/sim/architectures.py.

What each trial randomises: car size (small car to van) and where it stops in its 6 m space; gap to the curb (10-50 cm); cars in the spaces in front and behind (70 % each, anywhere in their space); a car or bus in the travel lane (30 %); street direction vs magnetic north; sensor noise (0.2 uT RMS); temperature drift since calibration (0.5 uT shared, plus 0.3 uT per sensor); each sensor's ~1 % gain error on Earth's field; and how magnetic cars really are (log-normal multiplier, x0.4 to x2.5, because our dipole model is uncalibrated).

Calibration: the car model is fitted to published measurements (magnetics report): 30-50 uT at the engine and axles, ~0-3 uT between the axles. With it, a single in-road magnetometer scores about 90 %, matching independent field studies (81-93 %), which is a good sign the model is realistic.

Assumptions to check against American cheese's data: the dipole car model; radar/ToF modelled as geometry with 99.5 % per-reading reliability (no snow on in-road radar, no snowbank in front of a pole sensor); a single reading per decision (real firmware confirms over 3 readings, which cuts false alarms further for all magnetometer designs).

Experiment 2: what does each form factor cost per space per year?

Monte Carlo (20,000 draws per form factor) over a 5-year horizon, 1,000 spaces. Everything: hardware, install labour, winter handling, damage/theft replacement, battery-death service, a share of the gateways and their SIMs. Generated by research/sim/cost_model.py; the input ranges are in that file.

Reading: our own hardware lands at a few dollars per space per month, all-in, versus ~$10/month for the commercial reference. The cheapest options are the ones that never need a crew in the road: pole sensors avoid lane closures, permits for digging and the twice-a-year winter removal that the in-road sheet needs. The in-road sheet's real cost is not money but 4-6 months a year without data.

Not included: our engineering time, city fees we don't know yet, insurance, and sales. Install labour assumes a trained technician; the first installs will be slower.

Experiment 3: what does a radar on a meter pole see?

Ray-traced geometry (research/sim/pole_radar.py): radar on the meter pole at the boundary between two spaces, aimed into its own space. Cars are boxes parked anywhere in their 6 m spaces (up to 40 cm over the line), neighbours present 70 % of the time, a vehicle in the lane 30 %. The radar reports "occupied" when enough of its beam hits a vehicle inside its range gate.

Searched 288 mountings: height 0.6 / 0.85 / 1.1 m (a strap on the bare post below the meter head reaches 0.6-0.85 m), aim 0-75 deg into the own space, down-tilt 0-30 deg, range gate 1.6-4.0 m. Pole 0.6 m behind the curb face; 30 deg beam half-angle (A121 datasheet).

Best mountings

For comparison: aiming straight across the street at 0.85 m height scores 66 % at best, and the worst mounting searched scores 50 %. Where you point it matters more than the sensor.

Snowbanks (with the best aim)

Reading: aim the radar diagonally into its own space (so the neighbour's car, which parks right next to the same pole, falls outside the beam) and cap the range so the travel lane is ignored. Mount it high on the pole so snowbanks along the curb don't blind it; when a bank does, the sensor can tell (everything is very close) and report "unknown" instead of guessing.

Assumptions: cars as boxes (body 0.3-1.45 m, or 1.8 m for tall vehicles), a 30 deg effective beam half-angle (A121 HPBW 65 x 53 deg), the pole at a space boundary 60 cm behind the curb, flat street, no pedestrians or cyclists in the beam (a real risk on the sidewalk side: the beam points away from the sidewalk).

Experiment 5: can firmware beat the dead zones?

Time-series simulation (research/sim/firmware_events.py): cars back into the space along a parallel-parking path, park anywhere in it (often with the sheet in a dead zone between the axles), stay 10 min-2 h, and drive out. The car model is Exp 1's, calibrated to measured fields. The cheese samples every dt seconds at a random phase.

Reading: a magnetometer alone can't both catch cars parked over a dead zone and ignore the car next door: lowering thresholds or latching on transients trades one error for the other, and catching brief transients needs faster sampling (more battery). A radar woken by the magnetometer settles it: the magnetometer only has to notice that something changed, and the radar, which sees the car body directly, decides.

Assumptions: radar per-check reliability 99.5 % and ~0.5 mC per check (A121 datasheet: ~74 mA during a few-ms sweep, plus start-up; to be measured); 40 parking events/day; noise 0.25 µT. The radar's own failure modes (slush on the window) are not modelled here.

Experiment 7: how should a pole radar poll?

On a meter pole there is no magnetometer to wake the radar, so it has to look on a timer. Event simulation (research/sim/pole_firmware.py), 30 days per setting: ~12 parked cars a day (5 min-3 h), people crossing the beam (~8/h by day, ~2 s each) and a few standing in it (4/day, 20-120 s), 0.5 % per-reading radar error. The firmware reads every P seconds and changes state after N readings in a row agree.

Reading: a pole sensor doesn't need a magnetometer. Reading every 5 s and requiring 2 agreeing readings reports cars within ~10 s, filters people walking through the beam, and still runs over 10 years on one D-size lithium cell. People who stand in the beam for a minute (loading a trunk) still cause brief false "occupied" episodes; requiring 3 readings cuts them but not to zero. The proper fix is the radar itself: a person is a weak, narrow reflector next to a car, so a strength threshold (measured in Exp 4) should separate them.

Assumptions: 0.5 mC per radar check including start-up (Acconeer's low-power figures suggest less; to be measured on the XM125), ~30 LoRa messages + 24 heartbeats a day at ~40 mC, 3 µA sleep, 17 Ah usable, 15-year shelf-life cap. Pedestrian rates are guesses for Bow Street, to be replaced with counts from the kit's data log.

Experiment 8: what happens as we scale?

Exp 2 priced 1,000 spaces without fixed costs. This adds volume pricing (small runs pay retail module prices, 10,000 units get ~30 % off), the fixed costs a real deployment carries (FCC Part 15B test, liability insurance, hosting, LoRaWAN network fees, a minimum number of gateways), and a possible city fee for using meter poles. Monte Carlo, 20,000 draws, 5-year horizon (research/sim/scaling.py; every input range is in that file). Pole sensor battery from Exp 7 (outlasts the horizon). Updated (tick 14): pole sensor unit costs from the priced bill of materials ($78 at 1,000 units vs $50 assumed before), spaces per gateway from Exp 11.

Cost per space per month, all-in

Median, with the 80 % range in brackets.

What moves the pole sensor's cost (1,000 spaces)

Every input at its likely value: $2.43 per space per month. Each bar swings one input from its low to its high value.

If the city charges a fee per installed unit (tick 15)

The city permission report found no federal cap that protects a parking sensor: the FCC's $270/yr limit covers only phone-carrier small cells (47 CFR 1.6002), and Cambridge charges its own small cells $270/yr per installation, the likely template. Median cost at 1,000 spaces:

A $270 fee per unit would make the pole sensor dearer than buying a commercial system ($25+/space/month vs ~$8.42). Two radars per unit halve it, still not enough. So the fee is not a detail to negotiate later: a pilot waiver, or a fee per block rather than per device, has to come first, and the alternatives that avoid city poles (private facades, the in-road options, which have their own permits) need a fair look.

Reading

• Scale is the first lever. The pole sensor costs ~$8.82/space/month at 100 spaces and ~$2.18 at 10,000: at pilot scale the fixed costs (insurance, certification, minimum gateways, hosting) are most of the bill. A 100-space pilot is a cost centre, whatever the hardware; the hardware choice only shows at 1,000+.
• The pole sensor stays cheapest at every scale, and the gap to the in-road options widens with scale because their cost is recurring labour (winter removal, re-coring), which doesn't get cheaper with volume.
• Unknown #1 is the city fee. If Cambridge treats a sensor on a meter post like a small-cell attachment and charges even $20/space/year, that is one of the biggest single items. It's the first question for the city (deployment report), ahead of any hardware decision.
• Two spaces per unit roughly halves per-space hardware and install; worth it where the post sits on a space boundary (Exp 3's geometry), pending the site survey.
• Against the commercial reference (~$8.42/space/month) every option of ours leaves a wide margin at 1,000+ spaces; the price we charge can be set by the value of the data, not by the hardware.

Not included: our salaries, sales, R&D, financing. Assumptions to replace with real numbers: city fee, insurance quote, Part 15B lab quote, gateway coverage on Cambridge streets (American cheese's link test).

Experiment 9: does every space need a sensor?

A 12-space block over 60 simulated days, minute by minute (research/sim/coverage.py): demand follows a daily curve, cars stay 45 min on average and take a random free space. Only some spaces carry a sensor; sensors are taken as right. The question a driver cares about: when the block is nearly full (≥ 80 %) and a space is free, does the app know where?

Reading

• Partial coverage fails exactly when it matters. On a nearly full block only one or two spaces are free, so the share of spaces with a sensor is roughly the chance the app knows about one: 50 % coverage -> ~66 %, 75 % -> ~87 %, whatever the block. The rest of the time the app says "full" while a space is free. Block-level estimates are off by ~1.2 spaces at 50 % coverage: fine for a heat map, useless for sending a driver to a space.
• Busier blocks need it more often, not differently: the packed block is nearly full ~23 % of the time, the quiet one ~13 %. On a quiet block a driver mostly finds a space without help, so sensors there earn their keep through city data (turnover, enforcement, planning) rather than guidance.
• So the product decides coverage: per-space guidance ("space 4 is free") on busy blocks needs every space sensored; a block-level heat map for planning or pricing (SFpark-style demand pricing, DDOT's finding) can run on 25-50 % coverage, plus meter-payment data, at a quarter to half the cost.
• A cheaper middle: sensor every space on the busiest blocks, sample the rest. Exp 8's cost per sensor applies only where sensors go.

Assumptions: drivers take a random free space (in reality ends of the block and spaces near entrances fill first, which would let a few well-placed sensors do better or worse; the street log will tell); perfect sensors; no double-parking or loading. Demand curves are generic, not Bow Street's.

Report: the city's permission and fees for a sensor on a meter post

Research agent, 2026-11-07. Builds on the deployment report, which covers the permit paths for each form factor. Sources at the end; [unverified] = not confirmed from a primary source.

Bottom line

1. No published process covers a private device on a meter post. The meters belong to the Department of Transportation (the former Traffic, Parking + Transportation, renamed April 2025); its Street Management division "installs and maintains parking meters". Likely route: written permission or a license from that department, possibly plus a Pole & Conduit Commission grant of location.
2. No federal fee cap protects us. The FCC's $270/yr rule covers only "personal wireless service" equipment (47 CFR 1.6002), not a LoRaWAN sensor. The city can refuse or charge anything. Its own small-cell policy charges $270/yr per installation, the obvious template for staff.
3. $270/unit/yr would sink the model: $22.50 per space per month at one space per unit, against our modelled $3.32 total (Exp 8's fee range tops out at $1.67/month). A pilot fee waiver, or a per-block fee, is the most valuable ask.
4. The Surveillance Ordinance plausibly applies once the city receives our data. Cambridge reads it broadly: its reports list the Water Department's meter-reading system and TP&T's traffic-count cameras. Per-space occupancy radar is borderline; we need a written answer.

1. Meters, owners and permits

2. The Surveillance Technology Ordinance (Ch. 2.128, Dec 2018)

Definition (2016 drafting text; the enacted §2.128.020(G) couldn't be fetched, so [unverified]): any electronic device "capable of collecting... audio, visual, digital, location, thermal... information... specifically associated with, or capable of being associated with, any specific individual or group". Examples include "through-the-wall radar or similar imaging technology". Parking Ticket Devices (and, per a Brookline-hosted copy, "related databases") are excluded.

Process if it applies. It applies when a City department acquires the technology, or enters "an agreement with any other person or entity to acquire, share or otherwise use surveillance technology or surveillance data". The department files a Surveillance Technology Impact Report (how it works, purpose, where deployed and why, cost, civil-liberties impacts) and a Use Policy. Then come community meetings, a public hearing (draft: no sooner than 45 days after filing), a Council vote, and annual reports. Allow 3-6 months [unverified].

Does a non-imaging occupancy radar count?

• Against: no images, plates or identity, only "BOW-0012 occupied 14:02-15:40". Parking devices are carved out. San Diego's 2020 ordinance explicitly excludes "sensors that detect if cars are parked in a parking space".
• For: a car in a known space at known times can be "associated with" its owner via payment or ticket records. Cambridge listed the non-camera Water AMR system. The radar could in principle sense more than occupancy.
• Our best case: output only occupancy and health data; no link to payment or enforcement; never reset meters.

Politics. The Council approved ALPRs (Feb 2025), paused them (Oct 2025), and the city ended the Flock contract (Dec 2025) after Flock installed two cameras "without the City's awareness". It dropped ShotSpotter (May 2026), then restored it for 90 days (Aug 2026). Lesson: never install without written permission, and label the box "not a camera". San Diego's 2017 meter-pole boxes caused alarm because they held calibration cameras.

3. Precedents elsewhere

(LA ExpressPark and SFpark were grant-funded procurements, not startup paths.) The pattern: a free vendor pilot under a short letter agreement, then procurement if the city buys.

4. Pilot agreement, insurance, who runs it

• Agreement: expect a no-cost pilot letter or revocable license from the Department of Transportation, reviewed by the Law Department. If the city later pays, MA Ch. 30B applies: three written quotes from $10k, an RFP above $50k.
• Insurance [unverified for this use]: Cambridge bids ask for about $1 M per occurrence / $2 M aggregate liability from an A-rated carrier. MA permits typically add the city as additional insured, workers' comp if we have employees, and our indemnity of the city. Get a real quote for Exp 8.
• Public records: data given to the city may become public (G.L. c. 66), so share occupancy only.
• Who: the Commissioner's office, Street Management (meters, posts) and Parking Management (data users). The Pole & Conduit Commission is reached via the License Commission.

5. Questions to send (most plan-changing first)

1. Who can approve a small battery sensor strapped to a meter post (no drilling, no wiring): your department alone, or also the Pole & Conduit Commission?
2. Would there be a fee, per device or per space? Could a ~40-space Bow Street pilot be fee-free?
3. If it records only "occupied/free" per space (no camera, images or plates), is it surveillance technology under Ch. 2.128? Does that change if the city gets no data during the pilot?
4. Would you allow it on Bow Street meter posts at all, or prefer sign posts or another street?
5. What paperwork does a pilot need (letter, revocable license, MOU), and what insurance and indemnity?
6. Are meter replacements planned that would move Bow Street posts within 2 years?
7. Could you share anonymised meter/app session counts for Bow Street so we can check accuracy?
8. Who must be told before installs or battery swaps; any no-work periods (snow, sweeping)?
9. If the pilot works, how would the city buy the data: quotes, RFP, or an existing contract?

Sources

• https://www.cambridgema.gov/transportation/aboutus
• https://cambridgema.gov/Departments/transportation
• https://www.cambridgema.gov/parking
• https://www.cambridgeday.com/2025/12/16/cambridge-ups-parking-ticket-cost-to-40/
• https://www.cambridgema.gov/departments/transportation/news/2025/12/paybyphone
• https://www.cambridgema.gov/Departments/transportation/News/2025/01/harvardsqmeterfeechanges
• https://gisserver.cambridgema.gov/arcgis/rest/services/TrafficAGOLLayers/MapServer/10
• https://www.cambridgema.gov/-/media/Files/licensecommission/poleandconduit/pcminutes/pcminutes2025/102325pcminutes.pdf
• https://www.cambridgema.gov/-/media/Files/licensecommission/poleandconduit/smallcell/smallcellpolicyadopted103119.pdf
• https://public.destinyhosted.com/bilmtdocs/2023/CCWS/20230821_1445/10198_Small_Cell_Ordinance.pdf
• https://www.law.cornell.edu/cfr/text/47/1.6002
• https://cambridgema.gov/Departments/trafficparkingandtransportation/News/2021/02/changestostreetoccupancypermitfees
• https://cambridgema.gov/iwantto/requestsundayholidayworkpermit
• https://www.srevilak.net/wiki/images/8/84/Cambridge-surveillance-ordinance.pdf (2016 Council order with the draft text)
• https://www.brooklinema.gov/DocumentCenter/View/19547/MA-Cambridge (copy of Ch. 2.128; not fetched, per search excerpt)
• https://www.cambridgema.gov/news/2019/11/~/media/9BB00441E0684AB99E3D181185B7224F.ashx (Surveillance Use Policy)
• https://www.cambridgema.gov/-/media/files/citymanagersoffice/surveillanceordinancedocuments/annualsurveillancereport_coverletter_02282020.pdf
• https://docs.sandiego.gov/cityattorneyreports/RC-2020-6.pdf.pdf
• https://www.cambridgeday.com/2025/10/21/cambridge-wants-surveillance-tech-paused-until-company-addresses-fears/
• https://bdc2020-php8.boston.com/news/local-news/2025/12/11/cambridge-ends-contract-for-license-plate-cameras-after-breach-of-trust/?amp=1
• https://www.cambridgeday.com/2026/05/19/council-drops-shotspotter-in-close-vote/
• https://www.boston25news.com/news/local/cambridge-city-council-votes-temporarily-restore-shotspotter-90-days/5WC46R42QRALDB5N4UD7QO6WZQ/
• https://api.thecrimson.com/article/2025/2/4/cambridge-surveillance-technology
• https://www.sevendaysvt.com/?p=87503
• https://www.fox6now.com/news/milwaukee-parking-sensors-offer-real-time-availability-data
• https://www.sandiegoreader.com/news/2017/mar/24/stringers-parking-meter-perversion-hillcrest/?page=all
• https://bendoregon.gov/home/showpublisheddocument/56309/638241570429936380
• https://www.boston.gov/departments/transportation/smart-streets-0
• https://www.pittsburghpa.gov/files/assets/city/v/1/ip/documents/pgh-lab/25747_pghlab_rules__regulations_8-26-2024_1.pdf
• https://cityclerk.lacity.org/onlinecontracts/2018/C-119654_c_12-5-18.pdf
• https://www.govtech.com/data/sensors-help-la-create-demand-based-parking-pricing.html
• https://cambridgema.gov/oldbids/documents/9299/Bid9299.pdf
• https://malegislature.gov/Laws/GeneralLaws/PartI/TitleIII/Chapter30B/Section4

Report: deploying on Bow Street, Cambridge

Research agent, 2026-11-07. Primary sources linked; [unverified] marks estimates.

Site facts that drive the choice

• Bow Street has single-space meters (about 40 spaces, BOW-0001 to BOW-0057, $2/hr, 8 AM-8 PM, 30 min or 2 h, SmartMeter = No) in the City's metered-spaces GIS layer (layer, dictionary). Coin + app meters, no replacement planned (Cambridge Day). So there are meter poles at the curb; one pole per space vs twin heads per two spaces is [unverified].
• The odd-numbered side of Bow Street is a primary Snow Emergency tow route (~235 ft); cars are towed during bans and plows run to the curb (Snow Center). Brine pre-treatment since 2018; monthly mechanical sweeping April-December (Street Cleaning).

Form factors

Evidence from other pilots

• SFpark (~8,000 sensors): interference varied space to space and nearly half the spaces needed two sensors; batteries failed early and at random; occupancy reliable, turnover/stay length not; SFMTA bought data rather than hardware and later replaced sensors with a model built on payment data.
• Boston (330 Streetline in-ground sensors, 2013): sensors "do not give plug-and-play reliably high-quality occupancy data"; scaling needs methods "other than a sensor at every meter" (New Urban Mechanics).
• No published Boston-area winter damage rates found.

Power

No solar under a car. At curb/pole height in a street canyon, winter sun is weak and often blocked; solar-only curb devices have struggled in northern winters. Primary lithium battery for 5+ years; solar trickle on a pole as a bonus.

Takeaways

1. Cheese is a seasonal pilot device, not a city-scale product. If kept: even (non-tow-route) side of Bow Street only, recover before the first snow emergency.
2. Clamp-on to the existing meter poles is the most deployable option: no dig, ~5 min, no lane closure, above plows, easy battery swaps, probably one TPT agreement. Its risk is accuracy (Boston's experience): it must be proven, including when snowbanks block the view.
3. Core-drilled pucks are the proven winter answer but slow to permit and costly to service: a vendor play, not a student one.
4. Avoid cameras (Surveillance Ordinance; Flock episode). Ask whether non-imaging radar counts.
5. Design for a primary battery (5+ years) and over-the-air recalibration; report health data.
6. Sell the data, not the hardware: SF and Boston both found per-space hardware maintenance was the long-term pain.

Questions for Jeffrey Parenti / TPT

• Who approves a device on a meter pole (TPT or the Pole & Conduit Commission)? Insurance/indemnity?
• Is there a permit category for a surface-adhered device in a space? Any DPW objection on a tow route?
• Is Bow Street a 5-year moratorium street?
• Does a non-imaging radar or magnetometer count as surveillance technology under Ch. 2.128?
• Any planned meter replacement (integrate rather than clamp)?
• Who removes/reinstalls devices before snow emergencies and sweeping?
• Can we get ground-truth (meter / PayByPhone / Passport sessions) to validate accuracy?

Report: the radar on a building facade or behind a shop window (H10)

Research agent, 2026-11-07. Builds on the city report and the weather report. Glass losses are our own transfer-matrix calculation (57-64 GHz, ITU-R P.2040-1 glass: εr 6.27, ~0.56 dB/mm); we modelled each low-E coating as a metal sheet of resistance Rs and checked the results against published measurements. [unverified] = no primary source found; [est] = our estimate.

Bottom line

1. Clear glass works; low-E glass blinds the radar. One-way loss is ~2.5-5 dB through single or laminated clear glass, 4-10 dB through clear double glazing, and 22-45 dB through any metal-coated (low-E or solar-control) glass, so 45-90 dB for the round trip. Every 12 dB two-way halves the range.
2. Recent Massachusetts storefront glass is probably low-E [est] (needed to meet the energy code). The candidates are old single-pane windows and transoms. A $0 lighter test finds a coating.
3. Inside a window: no city permit. A facade box sticking out ≤6 in avoids the Council and bond process but needs a Historical Commission certificate on Bow Street. The Surveillance Ordinance doesn't reach private hosts.
4. It beats the meter post only if the city fee is over ~$67/unit/yr or the city says no, and only where the glass is clear or facade owners agree. An afternoon's test decides it (section 5).

1. Glass at 57-64 GHz

Why: a metal film far thinner than the skin depth attenuates ~20·log10(1 + 377/2Rs) at any frequency. Hard coats run under ~14 Ω/sq, single silver ≤10, double silver ≤3.5 (coater patents). Metallised window film acts the same way; dyed or ceramic film should be harmless [est].

Also: the glass reflects 10-40 % back: mount 2-3 mm off it, tilted 5-10°, and start the range gate beyond it. Winter condensation costs ~6 dB two-way per 0.05 mm. The A121 has worked through an intercom's hardened glass (Lund thesis).

Spotting low-E: (a) lighter or phone torch: one reflection with a different tint = a coating ($0); (b) EDTM AE1601 detector, single and dual pane, beeps on a coating (~$200); (c) best: the radar itself (section 5).

2. Cambridge rules

3. Owner agreements

For us [est]: a one-page revocable licence (12 months, auto-renew, 30 days' notice; we insure, indemnify, don't drill). The host gets $0-10/month and their block's parking data. The tenant signs for a window, the landlord for the facade.

Churn: Cambridge's empty storefronts doubled to 109 (2019 to fall 2024); vacant windows get leasing signs (2025 policy), fit-outs paper them over, cleaners move boxes. Expect 10-20 % of window hosts lost a year [est]; facade units survive tenant changes. One owner of several frontages (check assessor records in the Bow Street survey) could cover a block.

4. Power

A USB outlet allows 1 s polling (XM125: 0.33 mW at 1 Hz): arrivals in ~2-3 s and more readings to filter the pedestrians who constantly cross a facade beam. It also makes room for a gateway in the box: e.g. The Things Indoor Gateway Pro, $150 + $60/yr including cellular backhaul, ~2-3 W ≈ $5-6/yr of electricity at MA's ~24¢/kWh, though its ground-level range is short [est]. The new failure mode is being unplugged (cleaners, a new tenant), so add a small Li-ion backup that reports "power lost". Mains doesn't fix glass loss or geometry.

5. Verdict and the cheap test

Facade or window wins only when all of these hold:

1. The city fee is over ~$67/unit/yr (Exp 8 break-even) or the city refuses; otherwise the post wins (aim, height, one landlord).
2. The glass is uncoated single or laminated. If not, mount outside at ≤6 in with a Historical Commission certificate.
3. The product is a block-level map: hosts cover only some frontages (Exp 9: 25-50 % suffices for a heat map, not per-space guidance).
4. The geometry works: the radar looks across a 2-4 m sidewalk full of people, so mount high (transom, ≥2.2 m) looking down. Re-run Exp 3 and Exp 12 for this geometry.

Cost: the same ~$78 hardware without the hood or D-cell; $0-120/yr to the host instead of a possible $270/yr fee; plus a few hours of sales per host and the churn above [est].

The test (one afternoon, ~$50 of glass, plus the XM125 already on order):

1. Bench: log a metal plate's peak strength at 3 m, then put samples in front of the radar: picture-frame glass, a 6 mm clear offcut, a clear double-glazed unit and a low-E unit (glass shops sell rejects), each at 0°, 30° and 50°. The drop in dB is the two-way loss.
2. Bow Street walk: lighter-test every window and transom; note owner and sidewalk width.
3. On site, with one willing owner: aim at a parked car from inside the window, then from outside on the sill, for an hour each.
4. Rule: two-way ≤10 dB, the window works; 10-20 dB, marginal (try the transom or door glass); >25 dB, facade or nothing.

Sources

• ITU-R P.2040-1 (glass parameters): https://www.itu.int/dms_pubrec/itu-r/rec/p/R-REC-P.2040-1-201507-S!!PDF-E.pdf
• ITU-R Report P.2554-0 (2025), glass and window penetration loss: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-P.2554-2025-PDF-E.pdf
• 3GPP TR 38.901 §7.4.3.1 (glass, IRR glass): https://itecspec.com/3gpp/38.901/s/7.4.3.1
• Anderson & Rappaport, partition loss at 2.5 and 60 GHz: https://arxiv.org/pdf/1701.03415
• Ryan, MacCartney, Rappaport, penetration loss at 73 GHz (NYU Wireless): https://ar5iv.labs.arxiv.org/html/1703.08030
• TIP 28/60 GHz indoor study (via RCR Wireless): https://www.rcrwireless.com/20201214/test-and-measurement/what-does-tips-mmwave-testing-tell-us-about-indoor-5g
• Dense urban O2I coverage (cites the low-E and tinted figures): https://arxiv.org/pdf/2203.03813
• NIST, 60 GHz penetration loss: https://www.nist.gov/ctl/building-penetration-loss
• IEEE 802.15 safety glass at 60 GHz: https://grouper.ieee.org/groups/802/15/pub/2005/15-05-0382-00-003c-reflection-and-transmission-measurements-safety-glass-60ghz.doc ; laminated glass calculation: https://grouper.ieee.org/groups/802/15/pub/2005/15-05-0388-00-003c-transmission-caculations-60ghz.doc
• Low-E RF shielding at 1-18 GHz (Ängskog et al.): https://www.scilit.net/publications/144fa2135c08455bf0fb0abf15e748df
• Low-E sheet resistance (patents): https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/8337988 ; https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/10333009
• Lund thesis, A121 behind glass: https://lup.lub.lu.se/student-papers/record/9129725
• Lighter test: https://greenfilmusa.com/blogs/post/how-to-tell-if-your-windows-have-low-e-glass ; LBNL field verification: https://webarchive.library.unt.edu/eot2008/20090814053759/http:/windows.lbl.gov/win_prop/component_verification/default.htm
• EDTM AE1601 detector: https://inspectortools.com/edtm-etekt-low-e-coating-detector
• MA energy code, 780 CMR ch. 13: https://www.mass.gov/doc/10th-edition-chapter-13-energy-efficiency/download
• Cambridge, projecting sign and structure process (>6 in, §12.08.010, §12.12.220): https://www.cambridgema.gov/~/media/Files/inspectionalservicesdepartment/OnlineForms/projectingsigndirectionsapplication.pdf ; https://cambridgema.gov/-/media/Files/CDD/ZoningDevel/Signs/signcertificationform_2024.pdf
• MA G.L. c.85 §8 (permits for objects over public ways): https://law.counselstack.com/statute/ma/85/8
• Harvard Square Conservation District: https://www.cambridgema.gov/historic/districtsHistoricProperties/harvardsquarencd ; order (exclusions, Non-Applicability): https://www.cambridgema.gov/-/media/Files/historicalcommission/pdf/HSQ2000_AmendedOrder.pdf ; subdistrict B, Bow Street: https://www.cambridgema.gov/-/media/Files/historicalcommission/pdf/hscdstudy/subdistrictdescriptionsexcerptedfromfinalreport2000.pdf
• Cambridge Surveillance Ordinance (draft text): https://www.srevilak.net/wiki/images/8/84/Cambridge-surveillance-ordinance.pdf ; Use Policy: https://www.cambridgema.gov/news/2019/11/~/media/9BB00441E0684AB99E3D181185B7224F.ashx
• MA wiretap law: https://malegislature.gov/Laws/GeneralLaws/PartIV/TitleI/Chapter272/Section99 ; privacy statute: https://malegislature.gov/Laws/GeneralLaws/PartIII/TitleII/Chapter214/Section1B
• Netmore gateway hosting: https://netmoregroup.com/host-gateway-earn-350/
• Helium host programmes: https://gristleking-blog.pages.dev/blog/getting-your-hotspot-on-a-commercial-building ; https://medium.com/alpine-capital-markets/analysis-of-4-major-helium-hotspot-providers-jag-industrials-vs-hositfy-vs-meshly-vs-ihub-3f9a9f559086
• Small-cell lease ranges: https://www.celltowerleaseexperts.com/cell-tower-lease/ ; https://airwaveadvisors.com/?p=1776
• Footfall counters, landlord permission: https://democracy.testvalley.gov.uk/Data/Overview%20and%20Scrutiny%20Committee/201704261730/Agenda/gWJR9TVwOBqnAkaGhgozzJJbhL43BF.pdf
• Cambridge empty storefronts: https://harvardsquare.com/media_room/empty-storefronts-have-doubled-in-cambridge/ ; https://www.cambridgeday.com/2026/04/05/long-term-vacancies-cambridge/
• The Things Indoor Gateway Pro: https://thethingsindustries.com/gateways/the-things-indoor-gateway-pro
• MA commercial electricity price: https://electricrates.org/massachusetts/business-electricity/

Report: what a magnetometer really sees under a parked car

Research agent, 2026-11-07. "(read from plot)" = read off published figures; "(derived)" = our calculation.

Summary: no public table gives "µT under engine / cabin / trunk", but every primary measurement points the same way: 30-50 µT at the engine and axles, ~0 µT in "dead zones" between the axles, and one car parked over a slot-centre sensor changed the field by only ~3 µT steady-state. A large vehicle ~40 cm outside the space can disturb a sensor more than a small car parked over it.

Measured values

Accuracy in the field

Failure modes: dead zones between axles (worse with high clearance), big vehicles next door or in the lane, slow traffic, sun/shade temperature swings, building steel, cars entering at an angle.

Drift

MMC5603NJ: offset drift 0.2 mG/°C typical (1.0 max), removed by SET/RESET; sensitivity changes 5 % over -40…85 °C (derived: ~0.14 µT/°C on Cambridge's vertical field, ~3.5 µT for a 25 °C pavement swing; common-mode, so it largely cancels between two sensors). Berkeley's fix: an adaptive baseline updated only while the slot is empty and quiet.

Datasets

None is a labelled parked-car raw-field dataset (IEEE DataPort road vehicles, moving traffic; Colorado School of Mines logger, tiny; Geelong occupancy events, no field values). We have to collect our own.

What it means for Glee

• Thresholds: our model's 5-10 µT mid-sedan estimate is optimistic. A fixed 5 µT steady-state threshold will miss some cars (SUVs, pickups with mid-wheelbase over the sensor), and lowering it lets big neighbours in.
• Switch to event-based logic: trigger on the arrival transient (axle/engine passage is 2-10× the steady value) and/or the gradient; latch "occupied" with a low hold threshold (~1.5-2 µT); release on a departure transient or a return to within ~1 µT of baseline; freeze the baseline while occupied.
• The gradient is a good veto (adjacent cars, traffic, drift), not a required AND-condition: in dead zones both sensors see ~0.
• Under-car features vary over 30-100 cm: a 30-40 cm baseline or 3 sensors separate "under" from "beside" better than 21 cm. Or place the sensor one-third of the space from the front, where engines land.
• Log raw 3-axis data at ≥ 10 Hz with camera ground truth for 2-4 weeks, including SUVs, pickups and EVs.

Report: Provolone v1 bill of materials

Research agent, 2026-11-07. Distributor prices looked up today (some are cached listings); est = our estimate where no public price exists, to be replaced by quotes. US dollars, per unit, before sales tax.

Bottom line

• One radar: ~$112 / $78 / $44 per unit at 100 / 1,000 / 10,000 units before certification. With certification spread over the run: $212 / $88 / $45. Two radars: $133 / $97 / $52 before certification, $233 / $107 / $53 with it.
• Above Exp 8's assumption ($38-70 at 1k). Re-run Exp 8 with ~$65-90 at 1k.
• Biggest items at 1k: XM125 ($16.50), box ($11), cell + pulse capacitor ($9.40), stainless bands ($8), RAK3172 ($6.50), labour ($6). 10k is lower mainly through the bare A121, a moulded box and a contract manufacturer.
• Bare A121 vs XM125 makes no FCC difference. The XM125 has no grant of its own; both rely on the A121's limited single-modular approval (FCC ID 2AQ6KA1201). Either way we do host testing only (Part 15B plus a radiated-spurious check), not a new radar certification.
• Keep the RAK3172 even at 10k. Our own STM32WL radio saves ≤ ~$1/unit and costs ~$8-15k in radio certification.

Line items: one-radar unit

100 and 1k: XM125 + Hammond box. 10k: bare A121 on a 4-layer board + moulded box.

Totals

Choices

Radar. The bare A121 ($8.22 at 1k vs $16.49 for the XM125) saves ~$8 per radar. It needs:

• a 1.8 V rail that holds through ~75 mA steps (the XM125 needs 1.8 V too, so the buck is in both);
• a 24 MHz crystal (CL 9 pF, 8 pF load caps in Acconeer's example) and SPI up to 50 MHz;
• every GND pad on top-layer ground, no ground openings near λ (5 mm), no lens raising EIRP; the 0.5 mm-pitch fcCSP probably needs 4 layers;
• Acconeer's radar library (RSS) ported to the RAK3172's STM32WL (Cortex-M4, 64 KB RAM), replacing the XM125's ready-made I2C firmware.

Recommendation: XM125 for the first 100, bare A121 from 1k.

FCC. Both paths carry "Contains FCC ID: 2AQ6KA1201". Because the grant is limited, the host maker must follow Acconeer's integration instructions, run "a limited set of transmitter module verification testing, including radiated spurious emissions", test the host under Part 15B / SDoC, and evaluate co-location with LoRa (firmware can avoid simultaneous transmission).

LoRa.

Cell and pulse support (Exp 7 draws ~1 Ah/yr, so any 17-19 Ah D cell is enough):

Avoid coin-type 0.47 F supercaps: their ESR is tens of ohms, useless for 120 mA pulses.

Mechanical. Hammond 1555 (IP68 PC, gasketed) fits a D cell and the board; fallbacks Takachi WP11-15 (~A$33) and Polycase WP-23 ($12.77 @250, IP65 only). Polycase pole kits ($28-37) cost more than our saddle + bands. Hose clamps (~$2) save ~$6 at 1k but come off with a screwdriver.

Uncertain: check before buying

1. Certification cost. Published Part 15B figures: $800-5,500 (vendor guides). Our $6-18k adds 60 GHz radiated-spurious verification (few labs; up to 200 GHz), LoRa host checks, ISED. Get two lab quotes. At 100 units it is $60-180 per unit.
2. Does the limited grant cover our own A121 layout? Ask Acconeer and a TCB. The XM125 carries the same "limited" condition.
3. Box wall. If the Hammond wall is 3.0 ± 0.1 mm PC (second half-wave), the radar can look through it with no separate window. 2.25 mm is the worst case.
4. XM125 supply. DigiKey: 0 in stock, 16-week lead time. A121: 10,698 in stock.
5. Tariffs. RAK's store price excludes ~25 % US import duty; the boards and cells are also Chinese. Only the 10 % contingency covers this.
6. Voltage. A fresh Li-SOCl2 cell (3.67 V) is just above the RAK3172's 3.6 V rating (STM32WL absolute max 3.9 V): common practice, but confirm. The XM125 (VIN max 3.45 V) must run from the 1.8 V rail, never straight from the cell.
7. "est" prices at 10k (tooling, bands, saddle, cell) are judgement, not quotes.

Sources

• A121 at DigiKey: https://www.digikey.com/en/products/detail/acconeer-ab/A121-001-T-R/17883300
• XM125 at DigiKey: https://www.digikey.com/en/products/detail/acconeer-ab/XM125/17883267
• A121 datasheet v1.3 (§6.2 crystal, Table 13, §8.2 FCC): https://docs.sparkfun.com/SparkFun_Qwiic_Pulsed_Radar_Sensor_XM125/assets/component_documentation/A121%20datasheet.pdf
• XM125 datasheet v1.2 (§7.2 FCC): https://docs.sparkfun.com/SparkFun_Qwiic_Pulsed_Radar_Sensor_XM125/assets/component_documentation/XM125_datasheet-3133248.pdf
• Acconeer A121 electrical integration: https://docs.acconeer.com/en/latest/hw_integration/a121/electrical_integration.html
• RAK3172, RAK store: https://store.rakwireless.com/products/wisduo-lpwan-module-rak3172
• RAK3172, Rokland: https://store.rokland.com/products/rak-wireless-rak3172-evaluation-board-us915-sku-316045
• STM32WLE5JC at LCSC: https://www.lcsc.com/product-image/C2971285.html
• LIS2DH12 at LCSC: https://lcsc.com/product-detail/accelerometers_stmicroelectronics-lis2dh12tr_C110926.html
• TPS62840 at LCSC: https://lcsc.com/product-detail/DC-DC-Converters_Texas-Instruments-TPS62840DLCR_C2071859.html
• Johanson 0915AT43A0026: https://www.digikey.com.mx/en/products/detail/johanson-technology-inc/0915AT43A0026001E/2392134
• JLCPCB assembly fees: https://jlcpcb.com/help/article/pcb-assembly-price
• JLCPCB 4-layer price per m²: https://jlcpcb.com/blog/special-discount-on-quality-4-layers-pcbs
• EVE ER34615 at nkon: https://www.nkon.nl/en/eve-er34615-d-formaat-lithium-batterij-3-6v.html
• ER34615 on Alibaba: https://www.alibaba.com/product-detail/3-6V-Lithium-D-Cell-Prices_1600669359651.html
• Tadiran TL-5930/S at Master Electronics: https://masterelectronics.com/en/tadiran-batteries/tl5930s-45573065.html
• Tadiran SL-2780 at 123accu: https://www.123accu.nl/Tadiran-Aanbieding-10-x-Tadiran-SL-2780-SL-780-D-batterij-3-6V-19000-mAh-Li-SOCl2-i49287.html
• Saft LS33600, prices: https://www.findchips.com/search/LS336 and https://ie.rs-online.com/web/p/d-batteries/2019466
• Tadiran PulsesPlus TLP-93111: https://www.onlinecomponents.com/en/tadiran-batteries/tlp93111asm-56151968.html and RS status: https://uk.rs-online.com/web/p/speciality-size-batteries/1946717
• Tadiran HLC-1550A at RS: https://uk.rs-online.com/web/p/speciality-size-batteries/0559961
• EVE SPC packs (Endrich): https://www.endrich.com/en/product-categories/accus-batteries/lithium-ion-cells/super-pulse-cap
• Eaton PHV-5R4V255-R: https://www.digikey.ie/en/products/detail/eaton-electronics-division/PHV-5R4V255-R/3878055
• Hammond 1555F2GY, prices: https://findchips.com/search/1555F2GY
• Takachi WP11-15-4C: https://au.element14.com/takachi/wp11-15-4c/outdoor-waterproof-enclosure-abs/dp/2472097
• Polycase WP-23: https://www.polycase.com/wp-23
• Gore VE80205 vent at RS: https://uk.rs-online.com/web/p/enclosure-ventilation/2879532
• BAND-IT 3/4" clamps at Zoro: https://www.zoro.com/band-it-band-clamp-34w-slotted-lock-pk25-ul2139/i/G808229693/
• FCC certification costs (vendor guides): https://markready.pages.dev/guides/fcc-certification-cost and https://markready.pages.dev/learn/fcc-certification-cost

Report: parts for a meter-pole radar ("Provolone")

Research agent, 2026-11-07, from datasheets and vendor/municipal documents. (unverified) marks secondary sources or inferences.

Radar: Acconeer A121 / XM125

Existing meter / pole sensors

Cambridge meters and poles

• Coin + PayByPhone/Passport meters, no card readers, no modems (City): Provolone can't piggyback on meter connectivity.
• Model, single vs twin heads, post position: not found; needs a Bow Street site survey.
• Regional standard (Boston detail A102): 2" Schedule 40 pipe (60.3 mm OD), 0.61 m from the curb face. A band at 0.6-0.85 m fits on the bare post below the head; the car's side is then ~0.7-1.2 m away.

Battery

RAK3172: 87 mA at 20 dBm (datasheet), users measure 115-148 mA at 20-22 dBm; 22 dBm needs ≥ 3.3 V. Use a pulse capacitor and 20 dBm max. Budget: radar at 1 Hz ≈ 3.4 Wh/yr + ~60 uplinks/day ≈ 1 Wh/yr → well over 5 years on one D-cell (~40 usable Wh).

Mounting

Stainless band clamps (BAND-IT, removable only by cutting: the street-furniture norm), Polycase pole-mount kits ($28-37), pin-in Torx screws (~$0.20-0.40 each), IP67 polycarbonate enclosure, tilt/accelerometer tamper alarm.

Recommendations

• v0: XM125 with Acconeer's I2C distance-detector firmware; range gate ~0.4-2.0 m; profile 3-4; poll at 0.2-1 Hz with the parking app's stationarity logic on the host; aim into the stall (~20° down, 20-40° yaw per the agent; our Exp 3 says 50-65°); 1.5 or 3.0 mm PC window; LS33600 + pulse capacitor; log raw distance and strength.
• v1: site survey first (meter model, heads, post position, OD); IP67 enclosure on a stainless band; tamper alarm; FCC label + Part 15B test; city license.
• Avoid Boston's failure mode: automatic per-pole calibration (learn the empty space), a stored pole-to-space map, and a 2-4 week video ground-truth check with published accuracy.

Report: the radar in rain, snow, salt and dirt

Research agent, 2026-11-07. Window losses are our own normal-incidence multilayer calculation at 60 GHz (1.5 mm polycarbonate window + one layer; water from the Liebe 1991 model at 0 °C; snow, slush, mud and leaves by a mixing rule, ±30 %). Check: it gives ~20 dB per mm of water, vs 18 dB/mm measured at 24 GHz (Suzuki 1979). † vendor claim.

Rule of thumb: range scales with loss^-1/4, so every 12 dB of two-way loss halves the range. Our real margin needs Exp 4; working guess: <6 dB harmless, 10-20 dB marginal on the pole, >25 dB blind.

1. What blinds the sensor

On the window (two-way loss, plus how much power the layer reflects straight back):

In the air, over the full 6 m round trip of a 3 m gate:

Bottom line: the air is negligible; the window is everything. Liquid water blinds (a 0.3-0.5 mm film, wet snow, slush, brine, wet mud); ice, dry snow, dust and dry leaves don't. A blinding layer also reflects 20-40 % of the power straight back: an easy signature to spot.

2. Window (radome) design

A coating helps a tilted pole window (drops roll off), not a horizontal in-road one (drops sit; tyres and plows abrade it). Treat it as a consumable.

3. How commercial radar + magnetometer sensors cope

• Acconeer: its parking app has optional obstruction detection (watches 3-5 cm out, inside the direct leakage, for change from a clean calibration; recalibrate after 20 °C). Its developer guide says switch to the magnetometer when rainwater covers the device and flag it for cleaning.
• Bosch (patent US10656299): the magnetometer decides; radar only when its data aren't "clear enough" (SNR). IR and ultrasound fail under snow or dirt. No covered-radar logic disclosed.
• Option SPS200 (60 GHz pulsed radar, 30-600 mm): "radar and magnetic detection enable operation under … sensor obstruction e.g. leaves, snow"†; no detail.
• Libelium: radar "not affected by dirt, dust, rain"†. Section 1 says otherwise above ~0.2 mm.
• Fleximodo: 99.96 %†; nothing published on covered sensors.
• Winter accuracy: no independent figure found. Q-Free's 5-month Nova Scotia winter pilot ">98 %"† (method not stated); NYC's 2012 Bronx winter pilot never published results.

Pattern: magnetometer always on, radar confirms; when the radar can't see, the magnetometer decides. Nobody publishes an "unknown" state.

4. Risks specific to the pole (Provolone)

Detector settings (Acconeer docs; I2C register map): CFAR threshold (default, 0x46) adapts per sweep but is one-sided near the start; RECORDED learns static clutter but must be re-recorded when the scene changes (e.g. a snowbank). Close-range leakage cancellation (0x43) is on by default in the I2C firmware, yet only applies when the range starts below ~20 cm and holds for ±15 °C; without it CFAR reaches ~6-7 cm. Reflector shape 0x4B: GENERIC (PLANAR is for liquids). All 10 peaks are returned regardless of sorting; register 0x10 carries NEAR START EDGE, CALIBRATION NEEDED and a relative temperature.

5. Recommendations

Hardware

1. 1.5 mm UV-stabilised PC window (±0.1 mm), 2.5-3.5 mm from the PCB; never ~2.25 mm. (Acconeer; calc)
2. Pole: tilt ~20° down under a short rain hood, plus a superhydrophobic coating renewed yearly. (Acconeer; Wei 2023)
3. Pole height 1.2 m, not 0.85 m: above snowbanks and most spray. (Exp 3; slush row)
4. Vent membrane + desiccant: 0.05 mm of condensation inside costs ~6 dB. (calc)
5. In-road: expect the radar blind whenever water stands on the sheet (≥0.3 mm); the magnetometer must decide then. (calc; Acconeer; Bosch)

Firmware

1. Detect "blocked": (a) custom XM125 firmware: Acconeer's obstruction detection; (b) stock I2C firmware: a second config starting ~60-70 mm (CFAR, leakage cancellation off) where NEAR START EDGE or a strong peak <0.2 m = covered; (c) background canary: if the empty scene's learned static peaks (curb, pavement) all drop >10 dB at once with no new peak, the window is blind. (Acconeer parking app; I2C guide; TI "RF visibility obscured" diagnostics)
2. Fallback: in-road, blocked → the magnetometer decides and the uplink says "radar blind" (reuse the "radar decided" flag). Pole, blocked → report unknown and hold the last state, never "free". Blocked >6 h → maintenance alert. (Acconeer developer; TI)
3. Car config: 0x43 = 0 (gate starts ≥0.25 m anyway), CFAR, sensitivity 500, GENERIC, max profile 3-4; read all 10 peaks; keep the empty-scene background on our MCU. (Acconeer; I2C guide)
4. Recalibrate on CALIBRATION NEEDED or a >15 °C change, only when the scene looks clean and empty (magnetometer quiet, canary normal), or snow gets baked into the baseline. (Distance-detector docs)
5. Change occupancy only on fast, stable changes (a car-distance peak appearing within ~30 s, held ≥3 readings). Slow growth = snow → unknown; near moving peaks = people → hold. (Parking-app logic, adapted)
6. Exp 4 add-on: weighed spray-bottle films to measure our real dB margin against this table; log background-peak strength daily against weather.

Sources

• Acconeer, Radome and mechanical design (A121): https://docs.acconeer.com/en/latest/hw_integration/a121/radome_and_mechanical_design.html
• Acconeer, Distance detector: https://docs.acconeer.com/en/latest/detectors/a121/distance_detector.html
• Acconeer, Parking reference app (obstruction detection, presets): https://docs.acconeer.com/en/latest/applications/a121/parking.html
• Acconeer Developer, Parking space occupancy (water, snow, obstruction, magnetometer fallback): https://developer.acconeer.com/?p=21587
• Acconeer, I2C Distance Detector User Guide (register map): https://docs.sparkfun.com/SparkFun_Qwiic_Pulsed_Radar_Sensor_XM125/assets/component_documentation/I2C%20Distance%20Detector%20User%20Guide.pdf
• Acconeer, Distance detector FAQ (CFAR ~6-7 cm without leakage cancellation): https://support.acconeer.com/support/solutions/articles/25000034271-a121-distance-detector-faq
• Texas Instruments SWRA705, mmWave Radar Radome Design Guide: https://www.ti.com/lit/swra705
• Wei et al. 2023, Durable superhydrophobic coatings for prevention of rain attenuation of 5G/weather radomes (Nature Communications): https://pmc.ncbi.nlm.nih.gov/articles/PMC10198997/
• Suzuki et al. 1979, Countermeasures against snow accretion and icing on radomes (24 GHz, 18 dB/mm): https://trid.trb.org/View/86433
• Sato et al. 2024, Wet snow accretion on a 79 GHz radar (JSAE): https://tech.jsae.or.jp/paperinfo/en/content/jt202405.27/
• Hallikainen et al. 1987, Extinction behavior of dry snow in the 18-90 GHz range: https://doi.org/10.1109/TGRS.1987.289743
• Liebe, Hufford, Manabe 1991, Permittivity of water below 1 THz: https://doi.org/10.1007/BF01008897
• ITU-R P.838-3 (rain): https://www.itu.int/rec/R-REC-P.838-3-200503-I/en ; P.676 (gases): https://www.itu.int/rec/R-REC-P.676/en ; P.840 (fog): https://www.itu.int/rec/R-REC-P.840/en ; computed with the itur package: https://itu-rpy.readthedocs.io/
• Gunn-East snowfall model (MathWorks snowpl): https://www.mathworks.com/help/radar/ref/snowpl.html
• Bosch patent US10656299B2: https://patents.google.com/patent/US10656299B2/en
• Option SPS200 datasheet: https://www.option.com/wp-content/uploads/2024/11/Option-ParkingSensor-SPS200.pdf
• Libelium radar parking (eeNews, 2019): https://www.eenewseurope.com/en/smart-radar-parking/
• Fleximodo, How do parking sensors work: https://www.parking.net/parking-news/fleximodo/how-do-parking-sensors-work
• Q-Free ParQSense winter pilot: https://www.parking.net/parking-news/q-free-asa/announces-successful-parqsense-pilot
• NYC Bronx sensor pilot (2012): https://www.govtech.com/transportation/new-york-city-testing-parking-sensors.html
• Pedestrian RCS at 77 GHz (Polarimetric RCS of pedestrians): https://arxiv.org/pdf/1910.13706

Report: every way to detect a parked car

Research agent, 2026-11-07, from datasheets, papers and city reports. † vendor claim, not independently tested. ‡ estimate or not confirmed in the primary document. "SFpark 2014" figures via Table V of arXiv 1902.07401.

Commercial products

City prices: NYC $250 per sensor (2 per space); Milwaukee $245; Burlington VT $250.

Takeaways

• The industry moved from magnetometer-only to magnetometer + radar (Bosch, Libelium, Option, Fleximodo, KKM): the magnetometer watches at µA, the radar fires only on a change to confirm. Urbiotica is the exception (mag-only, 98 %†).
• Independent long-term data puts magnetometer-only at ~81-93 %, not 98-99 %. Glee's target should be a ground-truthed, multi-month measurement on Bow Street.
• Best upgrade for cheese: a 60 GHz pulsed coherent radar (A121, ~$10, ~5×5 mm) that only confirms magnetometer events (< 1 µA extra). Avoid Doppler-only parts. Risk: slush/water on the window (hydrophobic window; ignore returns closer than ~5 cm).
• RF attenuation is free: every TTN uplink carries RSSI/SNR; LoRa RSSI alone reached 96-97 %. Log it now (works best when baseline RSSI > -90 dBm).
• ToF/IR get dirty in the road; better on a curb or pole. Cameras: cheapest per space but a poor fit for Cambridge (ordinance, power, 77-83 % in curb pilots).
• Not every space may need a sensor: DDOT found ~50 % sensor coverage fused with meter-payment data still predicted block-level occupancy (DDOT).

Report: can a stuck-on sheet stay in over winter?

Research agent, 2026-11-07. Tests H8's "remove every winter" assumption. [estimate] marks our own judgment, not a published figure.

Short answer

Not "always remove", but "remove unless the sheet is built like a snowplowable marker and sits on the even side". No one publishes winter loss rates for glued-on street parking sensors, and every snowy-city deployment we found is in-ground. The analogues (road markers, rubber speed humps, marking tape) show that height, edge angle, hardness and anchoring decide survival, plus whether a steel blade ever reaches that pavement. Today's 7 mm polymer sheet on butyl has a casting's height with tape's strength: the worst mix. A lower, ramped sheet in a space the plow rarely scrapes could plausibly stay in, losing perhaps 5-25 % per winter [estimate].

1. Surface-mounted parking sensors in snow

Bottom line: no published plow-loss rate for surface parking sensors; the one plow-rated surface product is rated only against light rubber-edged plows.

2. What survives plows: markers, markings, humps

Lessons: a blade catches a lip, so survivors ramp ≤ 6° all round; even 6-10 mm needs hardened metal keyed into the pavement; 2-4 mm fused material survives but wears; a shallow groove protects what can't be made strong.

3. How Cambridge (and Boston) actually plow

• DPW plows arteries during storms and "clears all streets … once a storm has ended"; it may "widen streets" but can't haul from every street.
• Without a ban, cars stay put; DPW warns plows will "push snow back … onto your parked car". The blade runs at the lane edge and reaches bare parking-lane pavement only at empty spaces or during later widening.
• Snow Emergency streets (Bow St odd side): cars towed, plows to the curb. Worst case.
• "Objects left in on-street parking spaces may be removed" (space-saver rule).
• Sweeping: monthly mechanical brooms April-December, none January-March. Brine on thoroughfares.
• Boston: main roads first; side streets largely dug out by residents; in big winters legally parked cars were moved to haul snow.
• No Cambridge rule found specifically on devices fixed to the road; DPW/TPT consent still needed.

Implication: on the even side the sheet spends most plow events under a parked car or a windrow. The risk is an empty space at the first pass or during widening, plus shovels and ice chippers.

4. Adhesives in cold, salt and freeze-thaw

Nevada DOT dropped cold-applied adhesives as unreliable. Freeze-thaw failure starts at the edge: water under a lifted edge freezes, wedges it open, and gives the blade a lip. Practical: dry pavement measured ≥ 10 °C, torch-warm, roll hard, seal the perimeter: the next few sunny November afternoons. December-March is outside almost every spec.

5. When could a sheet stay in?

Loss per winter (gone or lifted) [estimate], anchored on ~10 %/yr casting and speed-cushion losses:

A dislodged sheet is also debris/liability.

6. A cheap winter field test (2-3 dummies, even side)

Install at pavement ≥ 10 °C with TPT/DPW told (ask them to brief the plow contractor). Dummies match real footprint, weight and adhesive; vary the edge: square, 6° ramp, 4° ramp/dome. Paint reference marks beside each. After each plowable storm (log date, snowfall) and monthly, record:

1. Present / moved / gone (fixed-spot photo, offset from paint marks).
2. Edge lift: feeler gauge at 8 points, % of perimeter debonded.
3. Blade evidence: scrapes, gouges, chipped ramp.
4. Ice under the edge on freeze-thaw mornings.
5. Space occupied during plowing? One dummy with an accelerometer on the LoRa link logs strikes and heartbeats.
6. Install pavement temperature; adhesive tack in January.

Honest reading: 0 of 3 lost only bounds loss below ~63 % (95 %). The test finds failure modes; it can't measure a 10 % rate (that needs ~30 sheet-winters). Rule: any loss or > 25 % edge lift on a ramped sheet by March means removal stays policy; clean survival through ≥ 3 plowable storms justifies a 10-20 sheet trial next winter.

Sources

• https://www.parking-mobility.org/news/urbiotica-launches-u-spot-iot-surface/
• https://www.parking.net/parking-news/urbiotica/magnetic-parking-sensors
• https://urbiotica.com/us/?p=87627
• https://manualmachine.com/nedapnv/sensitsm/11369043-users-guide
• https://lora-alliance.org/wp-content/uploads/2019/07/parking-lot-sensor-datasheet.pdf
• https://www.manualslib.com/manual/3028818/Bosch-Pls.html?page=6
• https://spacewell.atlassian.net/wiki/x/kc0H
• https://gospacetech.atlassian.net/wiki/spaces/Doc4cus/pages/418709515/Fleximodo+Disclaimer
• https://itsinternational.com/products/libeliums-surface-mounted-sensor-provides-long-range-solution
• https://www.hansab.com/en/node/1220
• https://www.parking.net/parking-showcases/nedap-identification-systems/moscow-sensit
• https://www.govtech.com/transportation/new-york-city-testing-parking-sensors.html
• https://news.yahoo.com/why-burlington-added-sensors-street-100041956.html
• https://www.parking.net/parking-news/q-free-asa/new-smart-parking-sensor-pilot
• https://patents.google.com/patent/US5257875A/en
• https://cpcsigns.com/stimsonite-model-101-high-profile-snowplow-marker-castings-box-16/
• https://ftp.dot.state.tx.us/pub/txdot-info/cst/DMS/4000_series/archives/4210-0804.pdf
• https://connect.ncdot.gov/projects/research/RNAProjDocs/RP2020-59_Final%20Report.pdf
• https://www.roadsbridges.com/winter-maintenance-time-recessed
• https://rosap.ntl.bts.gov/view/dot/21736/dot_21736_DS1.pdf
• https://trid.trb.org/View/155568
• https://publications.iowa.gov/19741/
• https://resources.vtrans.vermont.gov/documents/archivedresearch/U1988%20-%2005%20%28OCR%29%20Stimsonite%2096%20Snowplowable%20Raised%20Pavement%20Markers.pdf
• https://resources.vtrans.vermont.gov/documents/archivedresearch/2002%20-%2006%20%28OCR%29%20Recessed%20Thermoplastic%20Pavement%20Markings%20Montpelier%20Vermont.pdf
• https://docs.lib.purdue.edu/jtrp/1700
• https://vtrc.virginia.gov/reports/all-reports/96-r3/
• https://www.audacy.com/kywnewsradio/news/local/winter-storms-damage-speed-cushions
• https://engaged.edmonton.ca/ramsay
• https://www.mass.gov/doc/mansfield-speed-bumps-on-highland-ave-draper-ave-and-howe-st/download
• https://www.cambridgema.gov/Snow
• https://www.cambridgema.gov/-/media/Files/publicworksdepartment/Snow/2011dpwsnowbrochureweb.pdf
• https://cambridgema.gov/news/2015/02/cityofcambridgesnowoperationsupdates
• https://cambridgema.gov/Services/StreetCleaning
• https://www.boston.gov/managing-winter-and-snow
• https://www.cbsnews.com/boston/news/drivers-unaware-as-city-moves-legally-parked-cars-to-haul-snow/
• https://hbfullerproducts.com/products/st-3001-standard-butyl-pad
• https://www.manualslib.fr/manual/664974/Uline-H-9872.html
• https://www.pexco.com/wp-content/uploads/2025/09/Pexco-RPM-Halftrack_installationprocedure_2025.pdf
• https://www.corpuschristitx.gov/media/jk2adkx3/025828-ref-txdot-dms-6130-bituminous-adhesive-for-pavement-marker.pdf
• https://www.columbus.gov/files/sharedassets/city/v/1/design-amp-construction/contractor-information/2002-construction-and-material-specifications/621[1].pdf
• https://abilenetx.gov/DocumentCenter/View/3108/810-1-PDF
• https://translineinc.com/wp-content/uploads/2017/11/e-bond_epoxy_data_sheet.pdf
• https://cdn.standards.iteh.ai/samples/83792/e455ea50563546ca8cfaac4e23aeecea/ASTM-D4592-12.pdf
• https://dot.ca.gov/-/media/dot-media/programs/research-innovation-system-information/documents/preliminary-investigations/use-of-cold-applied-adhesive-for-raised-pavement-marker-applications-pi-a11y.pdf