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
• 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 tests that decide the most, cheapest first: (1) Experiment 4: the XM125 radar on a real meter post next to real parked cars (Provolone v0, printable now; needs the ~$50 radar). (2) Asking the city who approves a device on a meter post and whether there's a fee.

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 (30 min with a tape measure and a phone): meter model, single or twin heads, post position vs the space lines, post diameter, height under the head.
• 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.
• 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.
• Questions for the city, now the top priority (Exp 8: a pole fee is the biggest unknown in the cost): who approves a device on a meter post, and is there an attachment fee; does a non-imaging radar count under the Surveillance Ordinance; Bow Street paving moratorium.

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 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.

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: 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: 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