Engine systems

How direct drive force feedback actually works

Direct drive does not add feel. It removes the mechanical filters that gear and belt reduction stages impose. A trace of one number, from the tire model to torque at the rim.

Arthur Dutra··22 min readShare ↗RSS

The argument for direct drive is almost always made in the language of taste. It "feels better." It "feels connected." It "feels more real." None of that is measurable, and none of it survives contact with someone who has already spent the money and wants to know what, mechanically, they paid for. The honest version of the claim is narrower and far more defensible: a direct drive base does not generate richer information than a belt or gear base. It generates the same information and then fails to destroy it on the way to your hands.

This piece traces a single number from the tire model to the torque you feel at the rim, and shows where each drivetrain architecture either preserves that number or filters it. The thesis is simple. Detail in force feedback is achieved by subtraction, not addition.

1. The wheel as output device

It is tempting to file a wheelbase under input devices, alongside the mouse and the gamepad, because you hold it and you turn it and the car responds. That category is wrong, or at least it is only half right. The encoder reports your steering angle, which is the input half. The far more demanding half runs in the opposite direction. The base is an output device for the physics engine, a torque display that renders one channel of the simulation's state into a force your hands can read.

This matters because it reframes the entire quality question. If the wheel were merely an input device, "better" would mean more accurate angle reporting, and that problem was solved years ago. As an output device, "better" means higher fidelity reproduction of a signal the sim has already computed. The signal is identical regardless of what you bolt it to. A 200 dollar gear wheel and a 2000 dollar direct drive base receive the same column torque value from the same tire model on the same lap. What differs is how much of that value reaches you intact.

So the useful framing borrows from signal processing. There is a read path, where the simulation's state is sampled and reported outward, and there is a write path, where that same state is pushed back into the physical world as torque. Telemetry is the read path. Force feedback is the write path. They draw from one shared source of truth, the per tick physics state, and a good way to evaluate any base is to ask how faithfully it executes the write path that the read path has already proven is available. Hold that distinction. It returns at the end.

2. Where the torque originates

The sim does not transmit "the road," and it does not transmit a spectrum of separate sensations that the marketing copy likes to enumerate. It transmits a single scalar: the torque about the steering axis, the twisting effort the steering column would experience in the real vehicle, recomputed every physics tick. Everything you feel through a properly configured base is that one number changing over time.

The dominant contributor to that number is the tire model's self-aligning torque, the moment that tends to rotate the front tires back toward center. Self-aligning torque is the product of the lateral force at the contact patch and the distance behind the wheel center at which that force effectively acts. That distance is the sum of pneumatic trail, which arises because the contact patch pressure distribution shifts rearward as the tire takes a slip angle, and mechanical trail, which the suspension geometry sets through caster. Because pneumatic trail collapses as the tire approaches and then exceeds its optimal slip angle, the self-aligning torque rises, peaks, and falls away before the lateral force itself peaks. That early collapse is the physical event you feel as the steering going light at the limit, and it is information the tire model computes whether or not your hardware can render it.

How that torque gets computed depends on the model family. Many sims use a Pacejka style magic formula, a semi empirical curve fit that reproduces lateral force, longitudinal force, and aligning moment across load and slip with no claim to first principles, only to fitting measured tire data well. Others lean on brush models, which discretize the contact patch into elastic bristles and derive forces from how those bristles deflect and slide, trading some empirical accuracy for behavior that degrades more plausibly off the edges of the data. Production titles usually run proprietary variants that blend both approaches and add transient effects. The point for force feedback is that the model produces an aligning moment, and that moment is the spine of the signal.

The contact patch forces then resolve through the steering geometry into a column torque, and that result sums with the other modeled contributions: load transfer under braking and acceleration, suspension forces, surface texture, kerb impacts, and whatever damping and friction the model applies internally. The sum is computed at the physics rate, not the render rate, and the two are deliberately decoupled. iRacing solves its vehicle physics at 360 Hz. The Assetto Corsa family runs near 333 Hz. The Madness engine behind Automobilista 2, inherited from Project CARS, ticks its physics around 600 Hz. Those rates are several times the frame rates most people render at, which is exactly why force feedback stays smooth when the graphics stutter. The hands are fed from the physics loop, not the graphics loop.

3. Normalization, clipping, and the transport bottleneck

Before that torque value can leave the simulation it has to be made portable, and portability costs detail. The first step is normalization. The raw physics torque, which has real units, is scaled against a configured maximum into a dimensionless range, roughly negative one to positive one, where the rails represent the strongest force the output is allowed to request. Everything downstream then speaks in fractions of full scale rather than in newton meters.

That scaling sets up the most common and most misdiagnosed failure in the entire chain.

Callout: clipping, or why a strong base can feel flat. When the computed physics torque exceeds the configured maximum, normalization pins it to the rail. Every distinct value above the ceiling collapses to the same saturated output, so a corner that should read as rising effort followed by the light, grainy texture of the front tires giving up instead reads as one undifferentiated wall of force. The base is not weak in that moment. It is saturated, and saturation is indistinguishable from a flat signal because all the variation that carried the information has been clipped off the top. The cure is counterintuitive: lower the gain until only the genuine peaks, the hardest kerb strikes, touch the rail, and the detail that was being crushed reappears. People chasing a heavy wheel routinely tune themselves straight into this hole.

The second step is transport, and here the historical limits are unkind. For years the standard route on Windows was the DirectInput constant force effect, a general purpose force feedback interface never designed for a 360 Hz torque stream. Although the USB Human Interface Device pipe a wheel enumerates on typically polls at about 1 kHz, the effective rate at which fresh constant force values actually updated through the legacy path sat well below the physics tick. The consequence is that even when the sim solved at 360 Hz, the base often received something coarser, a downsampled and staircased version of the underlying signal, with intermediate values simply never delivered.

The modern workaround is to stop going through the general purpose interface. High rate direct modes and vendor SDKs let a sim hand the base its physics rate torque stream over a dedicated path, and iRacing's high rate direct connection is the canonical example, delivering the full solver output to compatible bases rather than the legacy trickle. This is also why interpolation and reconstruction exist downstream. When the input is known to arrive sparse and stepped, the base has to rebuild a continuous output from it, which is the subject of a later section. For now the important fact is that the signal can be thinned in transit before the hardware ever touches it, and no amount of motor quality recovers a value that was never transmitted.

Signal chain from physics tick to torque at the rim, with the field-oriented control current loop broken out.

Figure 1. One column-torque value from the tire model to the rim. Stages 1 to 3 happen in the sim, stages 4 to 6 happen in the base, and the field-oriented control loop in stage 5 is where a force command becomes a real current. The read path at the bottom is telemetry sampling the same state the write path renders.

4. Inside the base: PMSM and field oriented control

Most explanations of direct drive stop at "it has a big motor," which is true and useless. The component that matters is specific. A direct drive base is built around a permanent magnet synchronous motor, a PMSM, which is functionally an industrial torque servo bolted straight to the rim. It is the same class of machine that positions CNC axes and robot joints, chosen because it produces high, smooth torque at low and zero speed, which is precisely the regime a steering wheel lives in.

A PMSM is a three phase alternating current machine, and that creates a problem. You cannot simply send it a voltage proportional to the force you want, because the torque a three phase motor produces depends not only on how much current flows but on the angle between the stator's magnetic field and the rotor's magnets. Push current at the wrong angle and you get heat, vibration, and a fraction of the torque you asked for. Making such a motor render a clean, commanded torque requires field oriented control, also called vector control, and field oriented control is the real reason a good base feels like a force display rather than a power tool.

The core idea is a change of reference frame, executed in two transforms. The Clarke transform takes the three phase currents, which are offset by 120 degrees, and expresses them in a two axis stationary frame, conventionally labeled alpha and beta. The Park transform then rotates that stationary frame into a frame that spins with the rotor, the d q frame, using the rotor's measured electrical angle. The payoff of moving into the rotor frame is that the physics simplifies dramatically. In the d q frame the quadrature axis current, Iq, produces torque, while the direct axis current, Id, produces only magnetic flux and no useful torque. For a surface mounted magnet PMSM the optimal strategy is therefore to regulate Id to zero and control torque entirely through Iq. The controller stops chasing three sinusoids and instead holds two slowly varying numbers.

Key equation

T = (3 / 2) · p · λ · Iq

where p is the number of pole pairs and λ is the magnet flux linkage. With Id held at zero, torque is proportional to the quadrature axis current and nothing else. This is the line the whole section turns on: every stage upstream, the tire model, the normalization, the transport, the firmware, exists only to decide what Iq should be at this instant. Commanding a force in the sim ultimately means commanding a quadrature axis current in the motor.

The loop that holds that command runs continuously. The firmware senses the actual phase currents, applies Clarke and then Park to bring them into the d q frame, and compares them against the setpoints, zero for Id and the torque derived value for Iq. Two proportional integral controllers drive the errors toward zero and output the voltages the motor needs in the d q frame. An inverse Park transform rotates those voltages back to the stationary frame, space vector modulation converts them into switching instructions, and a three phase MOSFET inverter pulse width modulates the actual bus voltage onto the windings. This current loop runs at tens of kilohertz, far faster than anything happening in the sim, which is why the motor can be treated by everything upstream as an ideal torque source that simply produces whatever Iq is asked of it.

The transforms depend on knowing the rotor angle precisely, because Park rotates by that angle, so these bases carry high resolution absolute encoders. Premium units resolve 20 or more bits, with several flagship designs at 22 bit, which is over four million counts per revolution, and the most expensive bases go further still. That resolution does two jobs. It is the position the base reports back to the sim as your steering input, and, more subtly, it governs commutation quality, because an inaccurate angle feeds the Park transform a wrong rotation and the current ends up slightly misaligned with the magnets. Poor angular resolution shows up as a notchy, magnetic, cogging sensation at low speed, where there is little motion to mask the error. Resolution, in other words, is not a spec sheet trophy. It is one of the inputs to whether the torque you command is the torque you get.

5. Why "direct" changes the feel

Everything to this point is shared. Gear, belt, and direct drive bases can run similar tire models, receive the same normalized signal, and even use field oriented control on their motors. The architectures diverge at exactly one place, the coupling between the motor shaft and the rim, and that single junction is the entire value proposition. In a direct drive base there is no reduction stage. The rim mounts to the motor shaft, motor torque reaches your hands at one to one, and whatever the current loop produces is what you feel.

A gear drive takes the opposite approach for sound economic reasons. It pairs a small, fast, cheap motor with a reduction gearbox that multiplies torque, which is why an entry wheel can be inexpensive and still push back at all. The cost is paid in the mesh. Gear teeth have backlash, a small dead zone that the rim must traverse on every force reversal before the other face of the tooth engages, so every transition through center and every rapid load change arrives slightly hollow. The mesh also has cogging and mechanical noise, and the friction of the train absorbs the low amplitude detail that carries surface information. The characteristic result is a notchy feel and peak torque in the region of 2 to 3 newton meters, with popular units such as the Logitech G29 and G923 measuring about 2.1 and 2.2 newton meters respectively.

A belt drive improves on this by replacing gears with a toothed belt and pulleys. Backlash drops sharply because the belt has no tooth clearance in the same sense, and the result is genuinely smoother, with peak torque commonly in the 3 to 8 newton meter range and bases such as the Thrustmaster T300 measuring near 3.9 newton meters. The trade is that the belt is compliant. It stretches under load, and a compliant element in the path behaves as a mechanical low pass filter. It rounds off sharp transients, absorbs high frequency texture before it reaches the rim, and introduces a small lag while it tensions. Belt bases tend to feel smooth and pleasant and slightly muted, with a faint elasticity at the limit where the very signal you most want, the abrupt collapse of self-aligning torque, is the kind of transient the belt is best at softening.

Direct drive deletes the stage entirely, and with it deletes backlash, compliance, and the filtering they impose. There is no tooth clearance, so reversals are immediate. There is no belt stretch, so transients arrive with their edges intact. The full bandwidth of the signal reaches the hands, which means tire scrub, kerb texture, and the exact instant of grip loss survive the trip rather than being rounded away. The cost of removing the reduction stage is that the motor itself must now make the full torque directly, which is why a direct drive motor is large, heavy, and expensive, and why peak figures run from about 5 newton meters on entry units to 25 on common flagships and beyond 30 on the largest. That directness is double edged. The same path that preserves a kerb edge also faithfully reproduces the staircase of a poorly reconstructed low rate signal, and the same motor that renders a delicate texture can produce enough torque to injure a wrist, which is the subject of the safety section.

PropertyGear driveBelt driveDirect drive
CouplingReduction gearboxToothed belt and pulleysRim on the motor shaft, 1:1
Typical peak torqueabout 2 to 3 Nmabout 3 to 8 Nmabout 5 to 35+ Nm
BacklashPresent, dead zone on reversalLowNone
ComplianceLow, but lossy meshBelt acts as a low pass filterNone
Characteristic artifactNotchy, cogging, audibleSmooth but muted, slight lagExposes signal flaws and cogging directly
What reaches the handsFiltered and friction dampedTransients rounded offFull signal bandwidth

6. Artifacts and the filters that fight them

A direct path is unforgiving, and an honest account of direct drive has to admit that the architecture exposes flaws it does not create. This is where the tuning sliders come in, and the useful way to understand every one of them is that each slider is a deliberate manipulation of the signal, added back on purpose to fight a specific artifact.

The first artifacts are the motor's own. Cogging torque is the rotor's preference for certain angular positions, caused by the magnetic interaction between the rotor magnets and the stator slots, and felt as a faint periodic resistance when you turn slowly with no force commanded. Torque ripple is the related variation in output torque as a function of angle even under a steady command. Both are suppressed rather than eliminated, through good field oriented control, through motor construction such as skewed magnets and optimized magnetic geometry, and through high encoder resolution that lets commutation stay aligned. A cheap direct drive base that feels magnetic and grainy at parking speed is exposing its cogging, because there is no gearbox friction left to hide it.

The second filter answers the transport problem directly. Because the signal can arrive sparse and stepped, the base performs reconstruction, interpolating across the gaps between sim updates to produce a continuous output instead of an audible, palpable staircase. Slew rate limiting belongs to the same family, capping how fast the commanded torque is allowed to change so that a single noisy sample cannot snap the rim. Both trade a little latency for smoothness, and both are the direct downstream answer to the downsampling described earlier. Set too aggressively they become indistinguishable from the belt compliance that direct drive was supposed to remove, which is the irony every over filtered profile rediscovers.

The third group is the synthetic effects layered on top of the telemetry torque: damping, friction, and inertia. Damping adds a force that opposes velocity, steadying a nervous rim. Friction adds a roughly constant resistance to motion, a synthetic stiction. Inertia simulates a heavier rim than the rotor actually presents. None of these are in the tire model. They are physical sensations manufactured in firmware, and they mark the real divide in tuning philosophy. Pure telemetry force feedback runs them near zero and asks to feel only what the tire model computed. Effect heavy force feedback dials them up to produce a feel many drivers prefer, at the explicit cost of mixing invented forces into the measured signal. Neither is wrong. The distinction is simply whether you are reproducing the simulation or seasoning it, and a careful operator should at least know which one a given profile is doing.

7. The latency and bandwidth budget

Assemble the chain end to end and the timing argument falls out cleanly. The first term is the physics tick interval, roughly 2.8 milliseconds at 360 Hz, 3 at 333, under 2 at 600, which sets how often a fresh torque value even exists. The second term is the force feedback interface and any downsampling, which on the legacy path can dominate everything else and on a high rate direct path nearly disappears. The third is USB transit at the roughly 1 kHz poll. The fourth is the firmware current loop, which at tens of kilohertz contributes on the order of tens of microseconds and is effectively free. The last term is the motor's own electrical and mechanical response, the time for current to build in the windings and for the rotor to actually move.

That final mechanical term is where rotor inertia earns its place in the budget as a real, physical quantity. A direct drive motor large enough to make 20 or more newton meters has a substantial rotor, and that rotor resists rapid reversal exactly as any mass resists acceleration. It sets a floor on how quickly the rim can change direction no matter how fast the electronics command it, and it is also a tuning consideration, because the synthetic inertia effect adds to a baseline that is already non trivial. The honest spec for this is slew rate, the rate at which a base can swing its torque output, quoted in newton meters per millisecond, with strong flagship bases in the range of 8 to roughly 9.5 newton meters per millisecond.

The conclusion the budget forces is the thesis restated as arithmetic. The direct drive chain is fast not because a clever component was added but because the slow component was removed. There is no belt to tension and no gear lash to take up, so the only mechanical delay left is the irreducible response of the motor itself, which lands the whole system in low single digit milliseconds. Speed here is a subtraction, the same as detail.

8. Safety and torque limiting

The forces are not theoretical. Competitive drivers typically run somewhere between 10 and 15 newton meters of actual force, which is already in the region of a real race car without power steering, and flagship bases can deliver 25 and more. A motor capable of that, coupled at one to one with nothing in between, can sprain a wrist or break a thumb if the rim spins unexpectedly during a spin or a crash, which is why responsible bases ship with conservative torque defaults and ask you to raise them deliberately.

The protections are layered. Firmware torque limiting caps the maximum output regardless of what the sim requests. Soft stops apply a rising counter force as the wheel approaches the end of its modeled travel so the rotation does not slam to a hardware limit. Hands off detection watches for the signature of a released rim and damps oscillation before it builds. Above the firmware sits the hardware level safeguard borrowed from industrial drives, a Safe Torque Off path and an emergency stop that physically disables the inverter so the motor cannot produce torque no matter what the control loop is doing. The practical framing is the same subtraction that makes the whole architecture good: the directness that preserves every detail also removes the mechanical forgiveness a gearbox quietly provided, since gear friction and belt compliance absorb spikes that a direct path delivers straight to the hands. Fidelity and forgiveness are traded against each other, and the base hands you the controls to set that trade.

9. Close: detail by subtraction

Direct drive does not add feel. It removes the filters that gear lash and belt compliance impose on a signal the simulation has already computed in full. Every advantage traces back to a deletion. Detail survives because no mesh chewed it up. Transients arrive sharp because no belt rounded them off. Latency is low because the slow reduction stage is simply gone. The expensive motor and the field oriented control loop exist to make a clean torque available at one to one, and the architecture's value is that it then declines to degrade it.

That reframes the read path and the write path that this piece opened with. Telemetry reads the simulation's state and reports it outward for analysis, the lap quantifying work of turning physics into numbers. Force feedback writes that same state back into the world as torque at the rim. They are two directions across one shared truth, the per tick physics state, and a direct drive base is the most faithful executor of the write direction precisely because it adds nothing of its own between the state and the hands.

There is a final symmetry worth naming. The bus that carries this state inside the game has a real counterpart in the physical vehicle, where the same kind of signal traffic, sensor values and actuator commands, moves over the car's own network. Telemetry reads, force feedback writes, and underneath both sits a bus. That is where this thread continues.