Car Health Data

Fuel Trim During a Real Drive: An OBD2 STFT and LTFT Case Study

Why one fuel-trim reading doesn't tell the whole story

An OBD2 scanner can show short-term fuel trim and long-term fuel trim at a particular moment. But fuel trim changes as engine operating conditions change. This case study uses real data recorded throughout a drive to show why the sequence and context can be more informative than one isolated number.

The vehicle was a 1998 Chevrolet S10, four-cylinder, manual transmission. It had been parked overnight. Recording began after key-on and just before the engine was started.

What STFT and LTFT represent

Short-term fuel trim (STFT) is the engine computer's relatively immediate fuel correction. Long-term fuel trim (LTFT) represents a learned correction accumulated over a longer period. Positive and negative values indicate corrections in opposite directions; interpretation depends on operating conditions and the vehicle's control strategy.

For this reason, an isolated fuel-trim value should not automatically be treated as a diagnosis. The interesting question is often what was the engine doing when the value changed, and did the behavior persist?

1. Fuel trim across the complete drive

2026-10-17T20:43:24.697292 image/svg+xml Matplotlib v3.10.8, https://matplotlib.org/

Figure 1. All recorded STFT and LTFT values plotted against elapsed recording time. Negative values in the CSV export are included.

The recording lasted about 8.2 minutes. It contains 29 STFT readings and 26 LTFT readings. STFT ranged from -18.8% to +7.0%, while LTFT ranged from -6.2% to +6.2%.

The striking feature is the difference in behavior. Short-term trim moved through a considerably wider range, including three recorded −18.8% samples, while long-term trim remained within a narrower −6.2% to +6.2% range.

2. The −18.8% short-term corrections

STFT reached its minimum recorded value three times. The table shows nearby operating measurements. Because parameters are polled sequentially, these are contextual samples rather than perfectly simultaneous readings.

TimeSTFTNearby recorded context
16:30:09-18.8%RPM 1070, speed 27, load 48, throttle 0, MAP 79, coolant 28
16:33:09-18.8%RPM 1796, speed 27, load 18, throttle 10, MAP 46, coolant 72
16:36:55-18.8%RPM 1033, speed 16, load 28, MAP 60, coolant 83

The first −18.8% sample at 16:30:09 was followed by positive STFT readings shortly afterward. The same minimum appears again at 16:33:09 and 16:36:55. That repeated but nonpersistent behavior is exactly the kind of pattern that can disappear when live data is viewed only as a snapshot.

3. Put the fuel trim in operating context

2026-10-17T20:43:24.777334 image/svg+xml Matplotlib v3.10.8, https://matplotlib.org/

Figure 2. Engine RPM during the same recording.

2026-10-17T20:43:24.863431 image/svg+xml Matplotlib v3.10.8, https://matplotlib.org/

Figure 3. Calculated engine load during the same recording.

The session also contains speed, throttle position, MAP, coolant temperature and ignition timing. These signals show that fuel-trim readings were collected while engine conditions were changing, rather than at one fixed operating state.

4. What the data does — and does not — show

The STFT excursions are values present in this recording, but this one session does not establish a vacuum leak, rich condition, fuel-delivery fault, sensor failure or another specific diagnosis. Fuel trim changes with operating conditions and control strategy, and sequential polling limits exact moment-by-moment correlation among parameters.

What the recording demonstrates is why context matters. A short-term correction can change markedly over a small part of a drive, while LTFT can present a different, more restrained pattern.

5. What a live snapshot could miss

If a conventional scanner were checked at one instant during this drive, STFT might have appeared near zero, positive, moderately negative, or at −18.8%. Each could accurately describe that sample, but none alone describes the entire session.

Live data tells you what the vehicle is reporting now. Recorded live data preserves what happened before and after.

This is the purpose of continuous car data: retain the sequence so patterns, changes and relationships can be examined after the drive rather than requiring the driver to watch changing numbers on a screen.

How this recording was made

Car Health Data recorded supported OBD-II parameters through a compatible Bluetooth adapter and mobile app. The export covers 16:29:00–16:37:15 on October 17, 2026, approximately 8.2 minutes, and contains 276 rows across ten metrics. Parameters are requested sequentially, so graphs should be interpreted as trends rather than millisecond-level synchronized measurements.

This is one vehicle and one real-world drive. The purpose is to demonstrate what can be learned from retaining live OBD2 data over time, not to claim that the observed values establish a mechanical fault.

Record the story of your own drive

Car Health Data records supported OBD-II measurements while you drive so you can review how vehicle conditions changed over time.

See How to Get StartedExplore the Features

Technical note: This case study reports the supplied measurements as recorded. It is educational information, not a substitute for mechanical inspection or professional diagnosis. Original session identifier: 1F8A1008-4682-4972-8F98-40711314DA87.