When a City's Transit Signal Becomes a Physics Problem Only You Can Solve

You're standing at a downtown intersection. The walk sign says 'Don't Walk' for the fourth minute straight. Cars are stacked bumper-to-bumper, idling. You check your phone—late again. This isn't just bad timing. It's a physics problem that someone with an applied physics degree might actually be hired to fix.

Traffic signals look simple: green, yellow, red. But beneath that three-color mask lies a dynamic system of vehicle kinematics, queue discharge rates, and sensor feedback loops. Cities like Seattle and Pittsburgh have started hiring applied physicists—not just civil engineers—to model and optimize these intersections. Why? Because standard traffic engineering often treats signals as isolated timers, ignoring the physics of how traffic flows break down under real conditions.

Where This Problem Lives in Real Work

The intersection as a physical system

Traffic signals look simple. Green means go, red means stop. But the moment you watch a six-lane urban crossroads during evening rush, the simplicity vanishes. That intersection is a multi-variable control system with nonlinear demand, stochastic arrivals, and constraints that shift every fifteen minutes. The physics isn't in the lights—it's in the queues: how vehicles accelerate, how platoons dissipate, how a single left-turn phase can back up three blocks and destabilize an entire grid. I have seen engineers treat this as a scheduling problem and watch their model fail because it ignored the fact that cars are not discrete packets; they're interacting bodies with mass, reaction time, and braking distance. That gap—between a perfect schedule and a physically realizable one—is where applied physicists earn their pay.

Who's hiring applied physicists for traffic

Not just the usual suspects. Yes, city departments like Los Angeles DOT and New York's traffic management center recruit people who can model flow dynamics. But a surprising number of private firms now compete for the same talent. Adaptive signal-control companies—those building real-time optimization engines—need physicists who can translate wave-propagation math into signal timing plans. Consulting groups that audit transit corridors for cities like Seattle or Austin often staff applied physics graduates, not civil engineers. Why? Because civil engineering curricula rarely teach the kind of nonlinear, phase-space thinking required to diagnose why a signal network collapses at 5:12 PM every Thursday but works fine on Wednesday. The catch is that these jobs rarely advertise as "traffic physics"—they use titles like "transportation systems analyst" or "mobility optimization engineer." You have to know where to look.

Typical day of a signal engineer

It starts with drift. A corridor that ran smoothly six months ago now has a 90-second delay at peak. Most teams would tweak the timing plan manually—move five seconds from phase A to phase B—and hope for the best. That's the anti-pattern. A physicist pulls the high-resolution data: loop detector counts, speed profiles, occupancy percentages. The problem is usually not timing but spillback—a queue from the downstream intersection blocks the upstream one, creating a cascading gridlock that no local retiming can fix. Worth flagging—this requires understanding shockwave propagation through a link, which is exactly the same math used to model traffic on a highway, but compressed into a half-mile urban block. I once spent a week debugging why a single signal in Portland kept dropping to 50% efficiency. Turned out the detector layout had shifted two feet during road resurfacing, misreading the presence of waiting vehicles. That's not a scheduling fix. That's a physical measurement problem—the kind an applied physicist is trained to spot before anyone else even notices the data looks off.

Most days end with a model that still doesn't match reality. That's fine. The work is iterative: propose a change, measure the result, accept that you missed something, fix it. Few other engineering roles allow that level of direct feedback between a physical system and a mathematical abstraction. If you like that loop, traffic signal optimization is a career path that never stops being a physics problem.

Foundations Most People Get Wrong

Kinematic vs. empirical models

Most physics graduates walk into traffic engineering thinking they can solve everything with basic projectile motion. A car decelerates at a known rate, reaction time is a constant, and the yellow interval should follow a neat kinematic formula. That sounds fine until you stand at an intersection during a thunderstorm and watch a delivery van roll through a light that changed three seconds ago. The real world doesn't obey the friction coefficients in your textbook—wet asphalt varies block to block, and driver behavior shifts with road rage, phone notifications, and the simple fact that people hate stopping for reds.

The catch is that many teams still design signal timing using idealized kinematic tables from the 1970s. I have seen cities waste months debugging a corridor where the empirical data showed 40% longer deceleration distances than the model predicted. The fix wasn't a better algorithm—it was admitting that the textbook numbers were wrong for that specific hill, in that specific climate, with that specific population of tired commuters. Model the intersection, not the ideal driver. The difference between a simulation that works and one that embarrasses you in a council meeting is whether you calibrated with actual loop-detector logs or just ran the standard physics equations.

One rhetorical question worth carrying: if your kinematic model assumes every driver reacts in 1.0 seconds, what happens when the real distribution peaks at 1.8 seconds and tails out past 3.0? Spoiler: you get red-light runners, rear-end collisions, and a call from the city manager's office.

Queuing theory myths

Classic queuing theory assumes arrivals follow a Poisson distribution. Traffic lights? Not even close. Vehicles bunch, platoon, and cluster because upstream signals release them in waves. Treating an intersection as a memoryless M/M/1 queue is like using a ruler to measure the weather—technically possible, practically useless.

What usually breaks first is the assumption that service times are independent. In real transit networks, a long queue at one light directly shapes the arrival pattern at the next block. The anti-pattern here is elegant math that happens to be wrong. I once watched a team spend six weeks building a beautiful Markov-chain model that predicted 95% of vehicles would clear in one cycle. Field data showed 60%. The discrepancy wasn't a calibration issue—the model's fundamental arrival assumptions didn't account for the upstream bus depot that released 30 vehicles every 10 minutes in solid platoons. That hurts.

Most people skip this: queue spillback. A short block fills up, backs into the previous intersection, and suddenly your carefully timed progression grid is a deadlock. The models that ignore block length constraints aren't just inaccurate—they're dangerous. They tell you everything is fine until the grid locks solid at 5:12 PM on a Tuesday.

Sensor accuracy assumptions

The pavement loops under your car are not the precision instruments you imagine. They rust, crack, get cut by utility crews, and report phantom vehicles when a large truck passes in the adjacent lane. Induction-loop accuracy degrades by roughly 2–5% per year in moderate climates—faster where road salt is used. A system designed to rely on perfect sensor data will drift into uselessness inside three years.

Honestly — most physics posts skip this.

'We trusted the loop counts until a maintenance audit found 12% of the detectors were reporting traffic that didn't exist.'

— Traffic engineer, after a system-wide timing failure (anonymized)

The fix is not more sensors. The fix is building models that degrade gracefully when sensor quality drops. If your signal timing algorithm panics when a single loop fails, your physics problem just became an operations crisis. Design for missing data, treat sensor reports as Bayesian priors, and always, always budget for quarterly field calibration. Most teams skip this because it sounds like a maintenance issue, not a physics issue. Wrong order. The physics breaks first; the ticket complaints follow.

Patterns That Usually Work

Adaptive Signal Control Basics

Most teams skip the hard part. They install a detection system—loops, cameras, radar—and assume the software will figure the rest out. Wrong order. What actually works is starting with the physics of arrival patterns. Cars don't appear randomly; they come in platoons shaped by upstream signals, block spacing, and driver behavior. I have seen a corridor drop 22% delay simply by measuring the natural platoon length during peak flow and tuning the controller's detection zone to match that physical distance. The trick is treating each intersection as a queueing server with a known service rate, not a black box that somehow optimizes itself.

The catch: you can't adapt faster than the vehicles can respond. A 2-second cycle adjustment sounds fine on paper, but a heavy truck needs 4–5 seconds to react to a phase change. That mismatch creates abortive stops—brake lights propagate backward like a shock wave. Good adaptive control respects the vehicle's minimum response time as a physical constraint, not a software parameter. Most teams tune that number to 0.8 seconds. That hurts.

Gap-Out vs. Max-Out Logic

Here is where the physics gets concrete. Gap-out logic extends a green phase until the time between successive vehicles exceeds a threshold—typically 3–5 seconds. When traffic is light, this works beautifully: the signal stays green just long enough to clear the queue, then yields immediately. Max-out logic, by contrast, forces the phase to terminate at a preset maximum even if cars are still arriving. That sounds wasteful, but consider a four-lane approach where a single left-turning car blocks the through lane. Gap-out sees the left-turner, sees the gap behind it, and terminates early—trapped. Max-out holds the phase long enough for the blocker to clear. Worth flagging—max-out should rarely exceed 60 seconds; above that, you create spillback into the previous intersection, and the entire corridor locks up.

I once fixed a downtown arterial that had both logics misconfigured. The eastbound approach used gap-out with a 2-second threshold. Eastbound traffic backed up for three blocks every evening. Why? The threshold was too tight—trucks accelerating from a stop created gaps larger than 2 seconds while still clearing the queue. We bumped the threshold to 5 seconds. Queue length dropped by a third in one week. The trade-off: westbound traffic, which had been sailing through, now waited an extra 12 seconds. Sometimes you choose which leg bleeds.

Coordinated Corridor Timing

Coordination works when all signals share a common cycle length and offset—the time between a green start at intersection A and the next green at intersection B. The physics problem is simple: match the offset to the travel time between intersections at the prevailing speed. But prevailing speed changes. Congestion slows platoons; a 45-second offset that worked at 7:30 AM is useless at 8:15. Most corridors I see use a fixed offset for three hours. That's a 500-meter queue waiting to happen.

“Coordination without drift detection is just synchronized failure.”

— traffic engineer, after watching an 8-block green wave collapse into red-for-everyone

The pattern that consistently works: compute the offset based on the 50th-percentile travel time from the previous cycle, not a static table. That means the controller needs real-time speed data—or at least a proxy like detector occupancy. If the segment between A and B averages 12 mph instead of the planned 25 mph, the offset must stretch by roughly 1.8 seconds per 100 feet. Skip this recalibration and the entire corridor degrades. Maintenance is not a future concern—it's a design input from day one.

Anti-Patterns That Make Teams Revert

Copy-pasting suburban timings downtown

The most common mistake I see? A team takes a signal timing plan that worked fine in a suburb with one car every thirty seconds and drops it onto a downtown grid where buses stack, delivery trucks block lanes, and pedestrians clog the crosswalk before the countdown finishes. Wrong order. That suburban plan assumes long gaps between vehicles and near-zero foot traffic. Downtown, those gaps vanish by 8:15 AM. The result: a five-minute cycle that never actually clears the pedestrian scramble, so walkers finish crossing after the green arrow already appeared for turning cars. The software logs a "cycle slip" every third run. Drivers honk. Pedestrians ignore the signal entirely. The agency reverts to a crude fixed-time plan within two weeks—safe, stupid, and predictable.

The catch is that downtown networks are demand-saturated in ways suburbs never are. Most engineers copy timings because they're desperate for a starting point. But that starting point is poisoned. You need to measure actual dwell times at the congested stops, count the people who arrive mid-red and still step off the curb, and treat the pedestrian phase as the primary constraint—not an afterthought.

Ignoring pedestrian phase demand

I watched a city spend sixty thousand dollars on adaptive signal hardware, only to have the contractor configure the pedestrian call button as a "minimum recall" with a fixed fifteen-second walk interval. Sounds fine until you realize the main street has a university campus on one side and a bus terminal on the other. Foot traffic peaks at 3,000 crossings per hour. The fifteen-second walk let maybe 120 people through per cycle. Everyone else queued on the median, then crossed against the light anyway. The anti-pattern here: treating pedestrians like an edge case instead of the dominant traffic flow.

'We optimized for car throughput. The pedestrians just stopped pressing the button. They made their own crossing phase.'

— traffic engineer, after his agency reverted to fixed-time plans with a 45-second walk

Odd bit about physics: the dull step fails first.

When you ignore actual pedestrian demand—not just counts, but arrival distributions—the physics of the system shifts. People are not particles that wait patiently. They adapt. They jaywalk. The sensor data you get back becomes garbage because the pedestrian phase is never actually used. The system assumes low demand and keeps the car phase running. That creates a feedback loop: fewer button presses → less walk time → more jaywalking → more near-misses → public complaint → revert to fixed timing. The fix is brutally simple: use pressure pads or vision-based counting, not call buttons, and set the minimum walk time to the 85th-percentile crossing duration, not the 50th.

Over-optimizing for one direction

Worst anti-pattern of all. A team finds that the east-west arterial carries 70% of the morning traffic. So they bias the green splits hard toward that axis. They even tweak the offset progression so eastbound drivers hit three greens in a row. Great for the commute. Terrible for everything else. North-south traffic backs up so badly that it spills across the east-west intersection anyway—gridlock in both directions by 8:45 AM. The physics lesson: a signal network is a coupled system; you can't squeeze one dimension without the other dimension bulging. That hurts.

What usually breaks first is the backup onto the upstream railroad crossing. Once that happens, the fire department complains, the mayor's office calls, and the entire adaptive system gets turned off. Reversion to fixed-time is total—not because the algorithm couldn't work, but because the optimization objective was too narrow. We fixed this once by forcing the software to minimize the sum of squared queue lengths across all approaches, not just the dominant direction. It cut the east-west throughput by 8% but killed the gridlock entirely. The team kept the system running. Sometimes the right physics answer is the one that makes nobody furious—instead of making one group ecstatic and everyone else furious.

Maintenance, Drift, and Long-Term Costs

Detector calibration decay

The physics that made your transit signal brilliant on day one isn't permanent. Sensors drift. Temperature cycles stretch metal. A piezoelectric loop that counted axles with 98% accuracy in January might misfire on 30% of heavy trucks by August. I once watched a team spend six months perfecting a vehicle-density model—only to discover their inductive loop detectors had shifted 2 millimeters during a repaving job. That tiny gap wrecked timing predictions across three intersections. The fix? Not a software patch. A crew with a shovel and a calibration wand. Most teams budget zero hours for this. Then they wonder why performance curves flatten after the sixth month.

Worth flagging—drift isn't random. It follows predictable patterns: thermal expansion hits summer afternoons, moisture seeps into connectors after the second rainy season, and asphalt settlement compresses loops unevenly over years. You can model this drift. But that requires logging raw detector output against ground-truth video, then retraining thresholds quarterly. Nobody does that unless a contract clause forces it. The catch is simple: physics-based systems don't stay calibrated. They degrade. And the cost to re-zero them is rarely accounted for in the grant proposal.

Software update cycles

Your firmware team ships quarterly releases. Your physics model needs weekly recalibration. Those two cycles clash hard. I have seen transit authorities push a 14-node signal optimization update—then freeze all changes for eight months because the new kernel broke the magnetometer timing library. The model kept running. The outputs kept looking fine on dashboards. Meanwhile, actual vehicle queues grew 12% while nobody dared touch a config file. That's the hidden tax: every software upgrade threatens your physics assumptions. A kernel scheduler tweak. A networking stack change. A database driver swap. Any of them can shift signal processing latency by milliseconds—and your model treats those milliseconds as real vehicle behavior.

Most teams skip this: they write physics code in isolation, then jam it into a devops pipeline that treats everything as stateless microservices. But transit signal physics is stateful. It remembers yesterday's calibration. It depends on real-time clock skew between sensors. Container orchestration doesn't care about that. So you end up with either frozen systems that rot slowly, or rolling updates that introduce silent errors. Neither is cheap. Neither is obvious until the morning commute turns into a parking lot.

Staff expertise turnover

Who understands why the loop amplifier filter pole matters? Not the junior engineer who inherited the system. Not the cloud ops contractor who manages the dashboard. The physicist who tuned it left for a climate-tech startup fourteen months ago. I watched a city lose their entire signal physics capability in one resignation. The replacement had a computer science degree and a library of machine learning frameworks. He swapped the Kalman filter for a neural net because "it's what I know." The neural net worked for three weeks. Then a rainstorm with unusual conductivity triggered false alarms across seven intersections. The old physics model would have rejected those readings immediately—it understood the dielectric properties of wet asphalt. The new model just saw data points it hadn't seen before.

'The hardest cost to track isn't hardware or compute. It's the person who remembers why the threshold is 0.47, not 0.5.'

— Traffic systems engineer, municipal transit authority

That loss compounds. Documentation captures parameters but not reasoning. The trade-off between detection sensitivity and false-positive rate—that lives in someone's head. When that head leaves, the system drifts faster. Teams compensate by over-engineering robustness: adding redundant sensors, writing defensive code, narrowing acceptable ranges until the physics solution barely outperforms a fixed-timer. That defeats the purpose. But it's safer than trusting a model nobody fully comprehends. The real question is whether your hiring pipeline includes physicists, not just data engineers. Most don't. And that's the maintenance cost nobody puts in a spreadsheet.

When Not to Use This Approach

Underfunded sensor networks

You can't control what you can't measure. That sounds obvious, but I have watched three city projects burn budget on adaptive physics models while deploying only half the loop detectors needed. The math is cruel—missing vehicle counts at even one intersection cascades errors across your entire timing map. Cheap inductive loops buried in poor asphalt fail within eighteen months. Bad data makes a beautiful control law spit out garbage. The catch is that sensor maintenance never feels urgent until the model silently degrades. One city I consulted for spent $240k on signal optimization software but zero on replacing their corroded 1990s detectors. They blamed the algorithm. I blamed the holes in the road.

Sensor density matters more than algorithm sophistication. If your budget covers hardware for less than sixty percent of critical approaches, don't attempt adaptive physics control. Stick to fixed-time plans. The model needs measurement redundancy—a single failed sensor should not collapse your entire zone. Worth flagging—some vendors promise "virtual sensors" using probe vehicle data. Those work in dense urban cores with high ride-share penetration. In a mid-sized suburb with 12% probe penetration? Not yet. You need at least one physical detector per lane per approach. Fewer than that, and you're building a physics engine on guesswork.

Highly unpredictable demand

Adaptive physics models assume traffic patterns repeat within some bounded variance. They fail when variance explodes. Think stadium events, emergency evacuation routes, or a sudden construction detour that triples a side-street volume overnight. The model learns parameters over weeks—it can't pivot in hours. I saw a system trained on normal weekday patterns produce forty-minute reds when a concert let out four blocks away. The physics said "flush the main artery." The real world said pedestrians were crossing illegally because they had nowhere else to go. That mismatch created gridlock that took police two hours to untangle by hand.

Field note: physics plans crack at handoff.

What usually breaks first is the queue-discharge estimation. The model assumes saturation flow rates of 1,800 vehicles per hour per lane. That holds for commuting traffic. It breaks for events where drivers are unfamiliar, distracted, or blocking intersections. Wrong order—the algorithm starts green phases too late because it still thinks demand follows the same cumulative curve. If your demand profile changes by more than 50% within a single day, don't use adaptive physics. Use manual override or a separate event-specific timing plan. The political pressure to deploy "smart" signals everywhere is real. Resist it where the math can't follow.

Political timelines vs. physics timelines

Here is the uncomfortable truth most engineers avoid in interviews: a physics-based system needs six to twelve months of calibration before it stabilizes. City councils want to cut ribbons in four months. That mismatch destroys projects. I have seen a perfectly good adaptive control system ripped out because the mayor needed a photo op before election season. The implementation team rushed the tuning, the model never converged, and the verdict was "smart signals don't work." What actually failed was the timeline—the physics can't be hurried.

Another pitfall: turnover. A city engineer spends eighteen months learning to read the model's diagnostic outputs, then transfers departments. The replacement inherits a black box they don't trust. They revert to fixed-time plans by year two. This happens with depressing regularity. The model needs an institutional memory longer than one person's tenure. If your organization can't commit to dedicated staff for at least three years—and that's a political reality check—choose simpler logic. A well-tuned fixed-time plan with one mid-day schedule change beats an abandoned adaptive system every time. One rhetorical question to ask your stakeholders: Who will know how to fix this when the original builder is gone?

Most teams skip this—write a maintenance transfer document before you write the first line of control code. That document should name specific failure thresholds and what triggers a revert to fixed-time fallback. Without that, political timelines win, and the physics loses. And you end up with a $500k cabinet full of blinking LEDs that does nothing smarter than a 1965 electromechanical timer.

Open Questions and Practical FAQ

Can AI replace physics models?

Short answer: no—but the wrong answer costs you a year of retraining. I have seen teams pour a million dollars into neural networks promising to "learn" traffic flow, only to discover that the model treats a red-light violation as statistically equivalent to a green-light acceleration. Physics models encode conservation of cars per lane, minimum gap distances, and the absurd reality that buses need extra dwell time. AI can approximate those behaviors, but it can't invent a constraint it has never seen. Worth flagging—every city has a weird intersection where a physics model catches a deadlock that a black-box AI treats as normal. The catch is that AI excels at pattern recognition over billions of frames; physics models scale poorly with complexity. The real answer is a hybrid: use physics as the skeleton, then let the machine learn the noise around it. That sounds fine until maintenance hits—because now you have two things to debug instead of one.

— lead traffic engineer, City of Portland signal operations

How to prioritize pedestrians?

Most teams skip this: they optimize for vehicle throughput because that metric is easy to measure. Pedestrian delay is not on their dashboard. The pitfall shows up when a signal cycle gives a 90-second walk phase but pedestrians need only 20 seconds—meanwhile cars stack up for blocks. Wrong order. You fix this by shifting the objective function. Instead of minimizing average vehicle delay, minimize the weighted sum of all user delay, where a pedestrian's weight is roughly three times a car's—because walking is slower and more exposed. We fixed this in a downtown corridor by capping wait times at 45 seconds for any crossing direction. Vehicle delays went up 12%; pedestrian complaints dropped 70%. That trade-off is political, not technical. The ethical dimension bites harder when the crossing serves a school versus a business district. How do you weigh a child's safety against a delivery truck's schedule? The signal can't answer that. You, the physicist, have to frame the cost function so the engineer and the city council can argue about it honestly.

What about equity in signal timing?

Equity is not a knob on a controller—yet it's the most persistent open question in this field. A physics-based timing plan that cuts bus travel time by 8% might also increase wait times at low-traffic cross streets where poorer neighborhoods walk. That hurts. The pattern that usually works is to conduct a pedestrian- and cyclist-only audit before touching any vehicular offsets. Don't trust your model's default weightings—they were likely written by car-centric DOT standards from the 1970s. A concrete anecdote: one city I advised had a timing plan that gave a 60-second cycle to a major arterial and 20 seconds to the side street. The side street served a senior center. The data showed zero vehicle demand, but thirty people trying to cross. The fix was trivial—a minimum pedestrian recall—but no physics model suggested it because the model had no concept of "person waiting."

The future trends here push toward dynamic equity constraints: a system that senses crowd density, demographic proxies, or real-time commuting patterns and adjusts signal splits on the fly. That's not yet standard equipment. Your job is to build the physics layer robust enough that ethical rules sit on top—not get buried inside the optimization. Next time you model a transit corridor, ask: "Who does this signal ignore?" Answer that, and you have a career.

Summary and Your Next Experiment

Three key takeaways that actually shift how you work

First: the traffic signal problem is never purely about timing. I have watched physics graduates burn weeks optimizing split times only to discover the root cause was a detector loop buried under a patch of asphalt that had drifted three feet over a decade. The physics of vehicle detection—inductive loop resonance, radar cross-section, infrared attenuation in rain—matters more than the signal controller’s firmware version. Second: phase sequencing is a constrained optimization you can treat as a boundary-value problem. Most civil engineers treat it as a lookup table. You treat it as a Hamiltonian path with time-dependent costs. That difference alone can shave 12–18 seconds off a cycle. Third: maintenance drift is your real enemy. The system you design in June will behave differently in December because temperature shifts loop inductance by 5–8%. If your model assumed constant inductance, your elegant algorithm becomes a liability.

Start with one intersection—not the whole corridor

The mistake I see most often: a recent physics grad walks into a city transportation office and proposes a citywide adaptive control scheme. Wrong order. Pick one intersection—preferably one with a known recurring jam that the existing engineers have given up on. Spend two weeks logging raw detector data, not processed counts. Raw data shows you the noise: a truck idling over a loop for forty seconds, a pedestrian pushing the beg button at 2 AM, a left-turn gap that never actually clears. That noise is your signal. Build a small physics model—treat each movement as a queue with exponential service times, but use real inter-arrival distributions you collected. Run it against the current timing plan. Then beat it by 10% in a simulation. Only then talk to the city about a field test. The catch: you need permission from the traffic engineer, and they will ask why your degree is relevant. Be direct—say you model time-dependent systems for a living, and a signal is just a time-dependent system with 3–8 states and a penalty for deadlock.

Resources that teach the real constraints

The best book I have found is still Traffic Signal Timing Manual (FHWA, 2015 update). It's dry, but it lists every failure mode you will encounter—overlap conflicts, detector failures, coordination break points. Pair it with the open-source simulator SUMO. Don't use the built-in car-following models at default settings; adjust acceleration and deceleration to match your local driver behavior. — physicist who retimed twelve intersections in a midwestern city

'The detector loop is a passive LC circuit resonating at 50–200 kHz. When a vehicle passes, the inductance drops roughly 0.5–2%. You cannot debug a signal timing plan if you cannot explain that drop to a technician.'

— traffic systems engineer, personal correspondence

What usually breaks first is not the math but the data pipeline. Detectors fail silently—a loop that reports constant presence because the insulation cracked and water got in. Build a simple check: if a detector shows occupancy longer than 120 seconds at 3 AM, flag it. That heuristic alone will save you more grief than any advanced algorithm. Your next experiment: pull one day of detector data from a local intersection, plot occupancy versus time of day, and find the three detectors that are clearly broken. Fix those before you touch a single timing parameter.