FIG. REF: PUMP-CTRL-01  ·  SUBJECT: PUMP CONTROL  ·  READ: 8 MIN

RPM-Threshold vs. Pressure-Based Fuel Pump Control

A lot of fuel pump controllers get marketed as "smart" because they vary duty cycle with RPM instead of running the pump flat-out all the time. That's genuinely better than nothing. But watching RPM and watching pressure are not the same job, and a controller that only does the first one is still, fundamentally, guessing.

The difference matters more than it sounds like it should, because the entire point of fuel pressure control is to hold a number you can't see from the RPM gauge.

What RPM-based control actually does

Strip away the marketing and most RPM-based fuel pump controllers do one thing: look up a duty cycle from a table or a threshold keyed to engine RPM. Below some RPM, run a lower duty cycle; above it, run higher, sometimes with a few steps in between. It's a lookup, not a measurement.

That's a real improvement over a pump wired straight to battery voltage with no control at all, which has its own well-documented downsides for pump heat and motor life. But a lookup table only ever answers one question: "what duty cycle has usually worked at this RPM before?" It cannot answer "what is the fuel pressure right now," because it was never measuring that in the first place.

RPM is a proxy for demand, not a measurement of pressure

The assumption baked into an RPM table is that engine speed tracks fuel demand closely enough to control a pump by. Most of the time, loosely, it does. But the cases where it doesn't are exactly the cases a fuel system needs to get right.

Aeromotive makes this point directly in their own documentation on pump speed control, noting that "ignition spark/RPM signals are also not reflective of what the exact engine fuel needs are, since downshifting/downhills can make the pump run very fast, but little fuel is needed." High RPM with a closed throttle, coasting downhill or during a downshift, is the textbook case: the engine is spinning fast, an RPM table reads that as high demand and runs the pump hard, and the actual fuel need in that moment is small.

That's the demand side. The supply side has its own blind spots that an RPM table can't see either:

• Supply voltage sag. A given PWM duty cycle produces less actual pump speed, and less pressure, at 11V during cranking or heavy electrical load than it does at a healthy 14V. The table doesn't know the voltage dropped.
• Pump wear. A pump that's a year and 15,000 miles further into its life doesn't move the same volume at the same duty cycle it did when new. The table was calibrated once, against a pump that no longer exists in that exact state.
• Line restriction and temperature. A partially clogged filter, a kinked line, or hot fuel aerating in the line all change the relationship between duty cycle and delivered pressure. None of it shows up as an RPM change.

In every one of these cases, actual fuel pressure can drift away from target while the RPM table keeps outputting the exact same duty cycle it always has, because as far as the table is concerned, nothing changed.

What closed-loop control means in plain terms

Closed-loop control flips the whole approach: instead of looking up what duty cycle should produce the right pressure, you measure the actual pressure and correct toward the target in real time. A sensor reads line pressure continuously, the controller compares it to the setpoint, and the difference, the error, is what actually drives the duty cycle.

You'll see this called "PID control," which sounds more intimidating than it is. It's three simple ideas stacked together:

• Proportional (P): the bigger the error, the bigger the correction. Pressure is 2 PSI low, push duty cycle up more than if it were 0.2 PSI low.
• Integral (I): if a small error keeps hanging around even after the proportional response, slowly add more correction until it's actually gone. This is what cleans up the "close but not quite" steady-state offset that proportional-only control tends to leave behind.
• Derivative (D): if pressure is changing fast, react faster, rather than waiting for the error to build up first. This is what helps the loop respond quickly to a sudden hit of throttle instead of lagging behind it.

None of that requires knowing RPM at all; a true pressure loop would work even with no RPM signal present. In practice, RPM is still useful as a feedforward term, a head start, so the pump ramps toward the right ballpark immediately on throttle input instead of waiting for pressure to actually sag before reacting. RPM sets the starting guess; pressure feedback is what actually gets it right and keeps it there.

Why this specifically matters for a carburetor

Carburetors make this worse to get wrong in either direction, because the acceptable pressure window is narrow and specific. Holley's own carburetor documentation specifies 5 to 7 PSI, with 7 PSI at idle and a floor of 4 PSI at redline — not a wide band, and not "more is better." Pressure above spec pushes against the float needle and seat harder than it's designed to seal against, and owners chasing a flooding, rich-idle, or fuel-weeping carburetor after "just turning the pressure up a little" is a recurring theme in carburetor troubleshooting threads. Pressure below spec, meanwhile, lets the float bowl run low under load and leans the engine out exactly when it can least afford it.

An RPM table has no mechanism to hold inside that window if any of the drift sources above are present. A pressure loop, by definition, is built to hold inside it, because holding a target pressure is the entire thing it's measuring and correcting against.

When RPM-based control is good enough

To be fair to the simpler approach: a well-tuned RPM table on a healthy pump, stable charging system, and a street-driven car that isn't chasing a tight pressure window can run fine for a long time. The drift sources above are real, but they're gradual, and a generous margin in the table can absorb a fair amount of them before anyone notices a problem.

Where it stops being good enough is exactly where the stakes go up: a build that's being tuned at the edge of what the carburetor wants, a car that sees real voltage sag under load, a pump that's going to spend years in service before anyone looks at it again, or anyone who's tired of troubleshooting a flooding or lean-feeling carb that "should" be fine on paper.

What Wraith does

Wraith is built around a real closed loop: fuel pressure is measured continuously, RPM feeds in as a feedforward head start, and the duty cycle sent out to Golem for power switching is whatever the pressure error actually calls for, not a lookup from a table that doesn't know the pump is twelve months older than the day it was calibrated.

Wraith is in production now. If you're running a pump controller that's really just a dressed-up RPM switch, or no controller at all, get on the list below.