When Drive-By-Wire Logic Oscillates: What to Fix First

You're logging CAN traces and the torque command looks like a sine wave—10 Hz, ±30 Nm. The car lurches. The driver complains. Your boss wants a fix by Friday. Where do you start?

I've been there. Oscillating torque commands in drive-by-wire systems are a nightmare because they feel like a software bug but often trace back to arbitration logic fighting itself. This article walks you through the most common culprits and the order to attack them. No fluff, just the stuff that works.

Why This Oscillation Problem Demands Your Attention Now

The Cost of Ignoring an Oscillation

An oscillation in drive-by-wire logic is not a tuning nicety. It's a safety event waiting to break something. I have watched a 12 Hz torque ripple turn a smooth highway merge into a bucking, lurching sequence that triggered a hard brake intervention. The driver was fine. The warranty claim was not. When the arbitration layer—the software that decides which torque request wins—hits a steady oscillation, the physical result can be unintended acceleration, driveline shudder, or components that fatigue in hours instead of years. This is not rare. Hybrid and steer-by-wire systems are the usual suspects, but any x-by-wire architecture with multiple request sources can cross that line.

Real Incidents That Start in Software

In 2021, a major OEM had to issue a stop-sale because a 7 Hz oscillation in the torque arbitration module was causing transmission clutch dithering. The fix was four lines of code—a debounce and a hysteresis gate—but the root cause had been missed for six months because the debugging team was looking at mechanical resonance, not the arbitration logic itself. That kind of misdirection costs money. And trust. The tricky bit is that oscillation at 10 Hz or below can feel like a rough idle or a misfire, so the natural reflex is to check spark plugs, injectors, or motor windings. Wrong order. The real cause is often a vote-switch that toggles faster than the physical system can settle.

Why Classic Debugging Fails Here

Most automotive debugging workflows were built for deterministic, time-invariant systems. Drive-by-wire arbitration is neither. You have adaptive torque limits, regenerative blending, stability control overrides, driver demand ramps—each source has its own bandwidth, its own filter, its own hysteresis. When two sources with slightly different update rates compete for the same final torque target, you get a beat frequency. That beat frequency is the oscillation. Standard oscilloscope captures miss it because the shift happens at the arbitration boundary, not at the CAN or FlexRay level. Traditional debugging fails because it assumes the conflict is between hardware and software. Most times the conflict is *within* the software logic itself. A single priority inversion or a missing deadband can create a 5–15 Hz cycle that ruins drivability. The fix? Stop looking at the mechanical response first. Look at the vote weights and their update cadences. That's where the seam blows out.

“We spent two weeks balancing flywheels. The problem was a 10-line arbitration routine that couldn't decide between regenerative braking and friction blending.”

— Senior calibration engineer, hybrid powertrain program, 2023

The Rise of x-by-Wire Multiplies the Risk

Steer-by-wire, brake-by-wire, shift-by-wire—every new domain adds another torque request source. More voters in the arbitration committee. More chances for a tie or a rapid flip-flop. The catch is that x-by-wire systems also have faster response times, so an oscillation that was damped by mechanical inertia in a hydraulic system now propagates directly to the actuator. Quick reality check—a 15 Hz oscillation in a hydraulic torque converter might be invisible at the wheel. In a fully electromechanical driveline, that same 15 Hz vibration can cause gear rattle, motor overheating, and driver nausea. That hurts. And it's only going to get worse as vehicles adopt zone controllers and redundant arbitration paths. The urgency is not theoretical. It's a direct consequence of removing the mechanical buffers that used to hide software oscillations. If you're debugging a NVH issue today and you haven't audited the arbitration logic, you're probably fixing the wrong thing. Start with the votes. Then the filters. Then the hardware.

The Core Idea: Arbitration as a Weighted Voting System

How Multiple Torque Sources Compete

Picture four drivers fighting over one steering wheel—each pulling a different direction. That's exactly what happens inside your arbitration module when the driver stomps the accelerator, adaptive cruise control sees a slower car, stability control detects yaw, and the torque reserve system tries to preserve battery voltage. Every microsecond, these controllers shout their desired torque value. The arbitrator listens to all four and decides which one—or what blend—actually reaches the inverter. Most teams skip this: they treat arbitration like a simple priority list. It's not. It's a weighted voting system with shifting coalitions. The driver normally holds the highest authority, ADAS comes second, stability can override both in emergencies, and torque reserve quietly adjusts the floor. But weights change based on vehicle state, temperature, and fault flags. That's where the seam blows out.

The role of weights, limits, and priorities

Each source submits three things: a raw torque request, a weight (0–100%), and a set of dynamic limits—maximum ramp rate, minimum torque floor, and a persistence timer. The arbitrator multiplies each request by its weight, then applies the limits. Quick reality check—limits often override weights. A stability controller at 40% weight but with an aggressive negative ramp can slam torque to zero faster than a driver at 90% weight can recover. That hurts. The arbitration output is never one clean value; it's a transient blend that can flip at 10–20 Hz if two sources keep trading dominance. Most production systems use a 5–20 ms arbitration cycle, which means the blend can oscillate faster than the actuator can physically respond. The result: driveline lash, audible gear rattle, or a torque surge that triggers the fail-safe monitor.

The catch is that priority tables hide this. Engineers map sources to fixed levels—level 1 always beats level 2—and assume the highest wins cleanly. But when two level-2 sources disagree and a level-3 source starts canceling one of them, the arbitration doesn't settle. It hunts. I have seen a 12 Hz oscillation in a hybrid powertrain that traced back to the electric motor controller and the engine controller both claiming level-2 urgency while the battery management system throttled both with a 70% weight cap that fluctuated with cell temperature. The arbitrator had no tie-breaker for that exact triangle. It just alternated.

“Arbitration isn't a traffic cop—it's a committee that changes its mind every 10 milliseconds.”

— powertrain calibration engineer, during a late-night debug session

Why oscillation often means one source switches rapidly

Not all oscillation comes from two sources fighting. Most comes from one source flipping between request and cancel. A torque reserve controller, for example, might request +20 Nm to pre-charge the inverter bus, then detect that the pre-charge target was hit, drop back to zero, and re-request because the voltage sagged again. That on-off-on pattern at 8 Hz looks like arbitration failure but is actually a single source with a poorly tuned hysteresis band. The arbitrator faithfully blends the on-state with the off-state—half torque in the blend window—which the actuator sees as a 50% duty-cycle oscillation. The fix is not re-prioritization; it's widening the deadband or adding a 200 ms hold timer so the source can't toggle faster than the driveline can stabilize. Wrong order: teams add more weights instead of measuring the source's switching frequency with a logic analyzer on the CAN bus. I fixed one case by adding three lines of code that debounced the torque reserve request. Three lines. The oscillation vanished.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

Under the Hood: What Makes Arbitration Logic Oscillate

Gain and Phase Margin in Feedback Loops

Arbitration logic is a control loop—period. When a weighted vote decides torque, gear, or mode, the output feeds back into the next arbitration cycle. If the loop gain is too high, the system overshoots. Too low, and it crawls. The oscillation sweet spot lives where phase margin collapses below 30 degrees. I have debugged a hybrid controller where a 5% gain bump in the arbitration weight calculation turned a steady blend into a 12 Hz shudder. The math is simple: time delay adds phase lag, phase lag reduces margin, reduced margin invites oscillation. Most teams skip checking phase margin because they treat arbitration as discrete logic, not feedback. That mistake costs weeks.

The tricky bit is that gain margin hides in plain sight. A rate limiter on the commanded torque—say, 200 Nm/s—looks harmless. But stack that with a 40 ms transport delay from sensor acquisition to arbitration output, and the effective loop phase shift hits 60 degrees at 4 Hz. Now add a nonlinearity: a deadband in the pedal map. The catch is that deadbands introduce describing-function gain that varies with amplitude. Small pedal movements see higher gain; higher gain erodes margin faster. Wrong order—fixing the rate limiter before measuring the deadband—can amplify the hunting.

Filter Time Constants and Their Interaction with Arbitration Periods

Low-pass filters clean signals, sure. But their time constants become hidden integrators in the arbitration path. A 100 ms filter on driver torque request interacts with a 50 ms arbitration period to produce a combined lag roughly equal to the filter time constant plus half the period. That pushes 150 ms of delay into the loop. Enough to drop phase margin by 10 degrees at 5 Hz. Not yet catastrophic—unless you have two filters cascaded. I once saw a powertrain team stack three first-order filters (50 ms each) on accelerator, brake, and motor-speed signals. The arbitration oscillated at 8 Hz. We fixed it by consolidating to one filter per signal and moving the filtering upstream of the vote weighting. That hurt—the software architect wanted clean signals inside arbitration. Cleaner signals caused the wobble.

The trade-off is brutal: filter aggressively and accept latency, or filter lightly and risk noise injecting into the arbitration weights. Noise looks like a high-frequency input oscillation. The arbiter sees a fluctuating vote from one sensor and counters with a fluctuating output. That creates a forced oscillation independent of loop stability. Most teams skip this diagnostic step: they plot the filter output versus the raw arbitration input and look for phase shift. Nine times out of ten, the phase shift aligns with the oscillation frequency.

'We spent three days adjusting weights before someone noticed the filter time constant was exactly one-tenth the oscillation period. Classic.'

— senior calibration engineer, after a 9 Hz hybrid-mode hunt

Command Rate Limiters That Can Cause Hunting

Rate limiters are not smoothing functions—they're integrators with a clamp. When two limiters work on different signals converging in arbitration, the system can hunt. Picture this: torque converter lockup rate limiter set to 1000 Nm/s, motor torque rate limiter set to 500 Nm/s. The arbiter blends them. At steady throttle, both limiters settle. But a transient—say, a 15% pedal jab—saturates the motor limiter first. The arbiter shifts weight to the torque converter path. That path hits its own limit. The arbiter shifts back. Oscillation emerges at the lower of the two limit frequencies. Quick reality check—the oscillation period equals roughly double the time the slower limiter takes to slew across the arbitration window. That's not theory; I measured that exact behavior on a bench test for a production SUV prototype. The fix was not software-only; we changed the hardware decoupling capacitor on the motor current sensor to reduce noise that forced the limiter to saturate early.

What usually breaks first is the assumption that limiters are independent. They're not. In weighted arbitration, every limiter adds a nonlinear gain element that varies with input slope. A step input sees a different limiter response than a ramp. That nonlinearity injects harmonics. A 10 Hz fundamental oscillation can carry a 20 Hz overtone that corrupts the next arbitration vote. Most engineers chase the fundamental. The overtone is the real culprit.

A Walkthrough: Diagnosing a 10 Hz Oscillation in a Hybrid Powertrain

The Initial Symptom: Jerky Acceleration at 40 km/h

The complaint came in from field testing: a 2025-series hybrid sedan that shuddered like a manual-transmission learner at exactly 40 km/h. Not at 38, not at 42—right on that number. The driver described it as a “rubber-band snap” every 100 milliseconds. That frequency—roughly 10 Hz—is the giveaway. Most torque oscillations in electric machines live in the 5–15 Hz band; below that you’re looking at driveline lash, above that at mechanical resonance. Ten hertz is the sweet spot where the motor’s electrical time constant and the inverter’s current controller start fighting the software arbiter.

My first move was to pull the CAN log and overlay three signals: driver-requested torque, motor torque feedback, and the battery management system’s regeneration limit. The driver pedal was smooth—a steady 25% position. The motor torque feedback, though? A sawtooth wave. It would climb to 80 N·m, then drop to 30 N·m, then climb again. The period was exactly 100 ms. Something inside the arbitration logic was flipping a switch at that rate. Quick reality check—I checked the inverter’s current regulator bandwidth. It was tuned to 200 Hz, three times faster than the oscillation. Not the inverter’s fault.

Step-by-Step Trace Analysis: Torque Monitor, Filter, Weights

I walked through the three arbitration stages in order. First: the plausibility monitor. It cross-checks driver intent against a model of what the powertrain can physically deliver. That monitor outputs a torque ceiling—120 N·m in this case—and the actual torque never exceeded 80. Not the monitor.

Second: the rate limiter. This is a software filter that caps how fast torque can change, typically set to avoid driveline shock. The limit was 200 N·m per second, meaning the motor could climb from 30 to 80 N·m in 250 ms. That’s slower than the oscillation period, so the filter should have smoothed the sawtooth. But it didn’t. Why? Because the filter only sees the final arbitrated torque request—it doesn’t see the voting that happens behind it. The oscillation was happening upstream, in the weight assignment algorithm.

Third—and here’s the culprit—the voting weights. The hybrid controller has three voters: the driver, the regeneration controller, and the battery-protection logic. Each voter submits a torque request and a “confidence weight.” At 40 km/h on a slight downhill, the regeneration controller wanted −30 N·m (regenerative braking) while the driver wanted +80 N·m. The battery-protection voter sat neutral at 0 N·m. The arbiter’s job is to blend these, but the weight for regeneration rapidly toggled between 0.3 and 0.7 every 100 ms. Why? The regeneration weight was tied to battery state-of-charge hysteresis. The SOC was hovering right at the threshold where regen is allowed—69.8% bouncing to 70.1% and back. That boundary-crossing triggered a weight recalc that flipped the blend ratio. The result: torque request alternated between 50 N·m (regen active) and 70 N·m (regen suppressed). That 20 N·m step, repeated at 10 Hz, felt exactly like a stutter.

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

“The oscillation wasn’t in the power stage; it was in the vote-weighting logic. The hardware was innocent.”

— Lead systems engineer, after the fix

The Fix: Adjusting the Regeneration Torque Ramp Rate

We didn’t touch the SOC threshold—that would require retesting the entire battery aging model. Instead, we added a 50 ms debounce filter to the regeneration weight assignment. If the SOC crosses the hysteresis band, the weight stays at its previous value for two control cycles. That one change killed the oscillation. The torque trace flattened to a steady 55 N·m, and the driver felt a smooth coast. The trade-off: a 50 ms delay in regen engagement. For this sedan, that lag was imperceptible. On a sport-battery pack with fast-charge demands, it might cause a SOC overshoot. That’s the pitfall—you trade oscillation for latency. Most teams skip this step and blindly widen the hysteresis band, which reduces battery utilization by 4–6%. Not a good swap. The debounce preserves utilization while killing the wobble. Verify on your own data: pull the weight-voter outputs, time-stamp the transitions, and if you see more than three flips in 500 ms, you’ve found your oscillator. Fix it there, not downstream.

Edge Cases: When the Obvious Fix Doesn't Work

CAN Bus Delays: The Arbitration That Isn't

You stare at the oscilloscope — 10 Hz, textbook. The obvious fix is re-tuning the arbitration weights. You bump the torque request priority, flash the ECU, and… nothing changes. That hurts. What usually breaks first here is timing, not logic. On a multi-ECU CAN bus, a 2 ms delay in message arrival can turn a stable arbitration scheme into a fistfight. The hybrid controller sends its torque target at 100 Hz, but the transmission ECU's reply arrives 3 ms late — now both controllers see stale data and keep renegotiating. I have seen teams spend two weeks adjusting gains when the real culprit was a bus load above 70% and a low-priority message getting queued behind diagnostics traffic.

The catch is that CAN arbitration is non-destructive — higher priority wins — but delivery is not synchronous. One ECU's temperature sensor update blocked a torque command for four milliseconds. That sounds fine until the oscillation threshold is 8 Hz. We fixed this once by moving the arbitration handshake to a dedicated 500 kbps bus and isolating the powertrain CAN from infotainment chatter. Wrong order: we tried software first. Always check bus timing before touching control logic.

Stuck Arbitration Bits: When Memory Corrupts the Vote

A single bit flip in an arbitration register produces the same symptom as a bad gain — oscillation at a fixed frequency, often between 5–12 Hz. But no software re-tuning fixes it because the logic itself is broken. Memory corruption from radiation, brownout, or a faulty RAM cell can lock an arbitration bit high or low, making one controller's vote permanently override — or permanently absent. Quick reality check—I once debugged a hybrid bus oscillation that vanished when we swapped the engine ECU. Bench testing showed a stuck bit in the torque arbitration register caused the ECU to always claim "I need zero torque," starving the motor controller and creating oscillation as it fought the stuck signal.

How do you catch this without spending three weeks desoldering chips? Read the arbitration status register live over XCP or UDS. If the bit field shows a constant pattern while the oscillation cycles, you have hardware corruption, not logic drift. The fix is a watchdog reset with memory scrub — or a hardware recall if the part is marginal. That said, a software-only band-aid (writing the arbitration mask twice per cycle) masks the symptom but burns CPU time and hides the root cause. Your choice: patch now, replace later.

Temperature-Driven Changes: The Actuator That Lies

Here is a pitfall that sends debug logs to the trash: the oscillation appears at cold start, vanishes under load, then returns at idle. Most teams chase the software path — recalibrate gains, adjust filters. They miss the actuator. An electronic throttle body's position sensor drifts 3% between -20°C and 80°C. The arbitration logic sees a 3% mismatch between requested and actual position and begins oscillating as it overcorrects. The obvious fix — lowering the proportional gain — just makes the car sluggish when warm.

'We spent a month rewriting arbitration tables. The throttle return spring was changing stiffness with temperature.'

— powertrain calibration engineer, after a 2023 field fix

The fix required a temperature-compensated deadband in the arbitration voter — a hardware-aware software change. You can't tune this by looking at logs alone; you need a thermal chamber or a cold morning test drive. Most teams skip this: they assume the actuator spec sheet is gospel. It's not. Measure end-to-end position error across the full temperature range, then build the arbitration margin around that real curve — not the ideal one. Otherwise the seam blows out on the first frost.

Limits of Software-Only Fixes: When You Need Hardware Changes

Why Tuning Gains Can Only Do So Much

You can tweak PID loops until your eyes bleed—and still watch the torque reference dance at 10 Hz. I have seen teams spend three weeks re-tuning a vehicle controller, convinced the oscillation was a software artifact. The catch is that a software loop can't push an actuator faster than its physical limits allow. Once the control signal demands a 50-millisecond response from a part that physically takes 120 milliseconds, the loop becomes a liar. The integrator winds up, the output saturates, and the oscillation remains untouched. That's not a logic bug; that's a boundary condition written in mechanical code.

Actuator Bandwidth and Mechanical Resonance

Every motor, clutch pack, and hydraulic valve has a natural frequency. When your arbitration logic commands a step change near that frequency—say, 12 Hz on a camshaft phaser—the system resonates. Tuning gains lower? Then you sacrifice response time. Tune them higher? The oscillation amplifies. One hybrid powertrain we fixed had a 10 Hz oscillation that disappeared entirely when we replaced a worn damper spring. The software was innocent. The hardware was tired. You can't filter out metal fatigue with a low-pass filter. The resonance lives in the steel, not the code.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

“I spent two months chasing a software oscillation that turned out to be a $4 bushing.” — powertrain calibration engineer

— Real quote from a colleague. The bushing replacement took 20 minutes.

Not every automotive checklist earns its ink.

Not every automotive checklist earns its ink.

The Case for Redundant Torque Paths

Sometimes the fix is not to tune, but to add a second path. A single electric motor driving an e-axle with one torque sensor? When that sensor drifts, the software has no way to cross-check. The arbitration logic oscillates because it's trying to reconcile one faulty signal against itself—impossible. The hardware solution: a redundant torque path or a second sensor. That hurts, because it means a PCB spin or a harness change. But throwing software at a single-point failure is like patching a leaky fuel line with tape. It holds for a while, then bursts. Most teams skip this because they want a software deadline. Wrong order. If the hardware lacks an independent measurement channel, the oscillation will return. I have seen it come back at highway speeds. That hurts.

Quick reality check—if your debugging checklist shows the same oscillation pattern across three different software builds, walk out to the lab and measure the actual actuator response. Put a current probe on the solenoid. Watch the mechanical linkage move. If the hardware can't follow what the logic asks, the logic is not the problem. The fix lives in a machine shop, not a compiler.

Reader FAQ: Your Most Pressing Questions Answered

Should I always use a low-pass filter first?

That reflex cost a team I worked with three days. They slapped a 5 Hz low-pass on every arbitration signal they could reach—and watched oscillation collapse to 2 Hz, then migrate to a different torque domain. The catch is a filter hides the problem; it doesn't fix the weighting logic. You end up with phase lag that makes the powertrain feel numb, or worse, introduces a new wobble when two filtered signals drift out of sync. I have seen this exact scenario on a mild-hybrid: the filter masked a stale sensor vote for four hundred milliseconds, then released a torque spike that tripped the traction inverter. Use a low-pass only after you know what frequency you're attacking. Otherwise you're treating a fever by breaking the thermometer—the sickness stays.

How do I set up an oscilloscope trigger for oscillation?

Wrong answer: trigger on the output signal. That gives you a trace that looks like noise until the oscillation stabilizes. Instead, trigger on the derivative of the arbitration weight signal—the slope. Most engineers skip this. Set your scope to detect a rising edge on d(weight)/dt that exceeds 0.3 per millisecond. That catches the moment two votes begin competing, before the output shows visible ringing. I watched a senior calibrator spend two hours chasing a 10 Hz ripple in the pedal map. We changed the trigger to the comparator output between two torque arbiters—found the glitch in twelve minutes. Quick reality check: you also need a persistent acquisition mode. Normal mode will miss the transient. Set persistence to infinite, let the oscilloscope build a heatmap of the oscillation window, then zoom to the first instance where vote weights cross 50 %.

Can adaptive gains fix oscillation without manual tuning?

Not yet—and that hurts. Adaptive gains look like the perfect fix: let the controller learn the plant dynamics and self-tune. What usually breaks first is the adaptation rate itself. If you set it too fast, the gain chases the oscillation and amplifies it. Too slow and you're back to manual tuning, just with more variables. I have debugged a case where an adaptive PI controller on a drive-by-wire throttle turned a 5 Hz oscillation into a 0.8 Hz limit cycle—worse latency, same instability. The trade-off is stark: adaptive gains require a convergence guarantee that most production controllers lack. You can patch the symptom with a notch filter, but the oscillation will return when the load changes. One concrete takeaway: if you must use adaptation, freeze the gains during transient arbitration phases. Let the weights settle before the learning loop runs. That alone stopped a persistent wobble on a 48-volt hybrid belt-starter generator—no filter, no hardware swap.

“We burned a month of dynamometer time chasing a 12 Hz oscillation. The fix was not a filter or a gain—it was re-ordering the arbitration priority table.”

— Calibration engineer, commercial EV program

What if the oscillation only appears at specific temperatures?

That's your signal, not your problem. Temperature-dependent oscillation points to a sensor-drift mismatch in the arbitration weights. Don't touch the filter. Instead, log each participant vote’s temperature coefficient side-by-side with the output ripple. I have seen a 0.2 %/°C drift in a hall-effect torque sensor create a 7 Hz oscillation at 85 °C coolant temperature that vanished at 50 °C. We fixed it by adding a temperature-compensation curve to the arbitration weight itself—not to the sensor readout. The oscillation was not real; it was arithmetic disagreement that grew with temperature. Measure first. Compensate second. Never filter third.

Practical Takeaways: A Debug Checklist for Monday Morning

Priority order: torque monitor, filter, rate limiter, weights

Most teams skip the torque monitor. That hurts. I have watched three different engineers spend two full days tweaking arbitration weights on a hybrid controller — only to discover the torque monitoring path had a stale input from the previous wake cycle. The seam blew out at 35 N·m. Fix the monitor first because it tells you whether the arbitration logic even sees correct data. If the monitor flags a mismatch, the whole voting system goes into a default state that looks like oscillation but isn't. You debug a ghost.

Next: the filter. Not the rate limiter — the anti-aliasing filter on the pedal position or motor speed signal. A 5 ms time constant that worked on the bench can alias a 50 Hz ripple onto a 10 Hz control loop. We fixed one oscillation by changing a single RC component on the sensor conditioning board. That said, don't touch the rate limiter until you have confirmed the filter is clean. Rate limiters mask symptoms. They introduce phase lag and can turn a 10 Hz wobble into a 2 Hz surge that feels worse to the driver. Wrong order costs you a day.

Tools: CANalyzer script to detect oscillation automatically

Build a CAPL script that watches the arbitration output signal — torque demand, clutch position, whatever your plant is. The script should count zero-crossings in a 1-second window and flag anything above 8 crossings. That catches a 4 Hz oscillation before a driver feels it. The trap is the threshold: set it too low and you trigger on benign dither from the pedal filter; set it too high and you miss a fast oscillation. Start at 8, log the last 500 ms of all arbitration inputs when triggered, then review the timestamp correlation. I have seen this cut diagnosis time from three hours to twelve minutes.

‘We ran the script on a Monday morning and found oscillation on three different ECUs. All three had the same filter capacitor value — 47 nF instead of 100 nF.’

— Field application engineer, hybrid powertrain team

When to escalate to the hardware team

You have tried every software tweak — filter constants, weight adjustments, deadband hysteresis, even a custom notch filter. Oscillation still returns at the same frequency under the same load condition. That's a hardware problem. Escalate when the oscillation locks to a mechanical resonance: gear mesh frequency, belt tensioner mode, or hydraulic line pressure ripple. The software can't fix a sway bar that's too stiff for the controller bandwidth. Send your CANalyzer trace, the oscillation frequency in Hz, and a photo of the physical layout. Hardware engineers need the spatial relationship — which sensor sits closest to which actuator — to see the coupling path. Don't escalate without the frequency. If you bring them a vague “it oscillates sometimes” you will wait three weeks.