How ELM327 Actually Learns Engine Parameters

Automotive diagnostic scanners have one feature that often remains behind the scenes. By connecting a small blue box to the OBD-II connector, the driver opens an application on their phone and sees a whole set of parameters: engine speed, coolant temperature, air flow, throttle position, and many other values.

Because of this, it's easy to assume that the ELM327 itself somehow measures everything happening in the car. In reality, this is not the case at all.

The ELM327 measures almost none of the parameters displayed on the screen independently. Moreover, the adapter doesn't even know where the engine is located in the car. Its task is much simpler: to receive a request from the phone, transmit it to the necessary electronic control unit, receive a response, and return it to the application. That is, the diagnostic chain is structured approximately as follows:

the sensor receives information about a physical parameter;
the ECU receives the signal and processes it;
the ELM327 transmits the request and response;
the application converts the received data into familiar numbers and graphs.

That's why a scanner reading doesn't always mean that the adapter directly measured something.

Who actually knows the engine speed

Let's take crankshaft rotation speed as an example. The crankshaft position sensor is responsible for determining it. It detects the passage of teeth on the reluctor wheel, after which the ECU analyzes the intervals between pulses and calculates the crankshaft rotation speed.

The same thing happens with coolant temperature, although the measurement principle is different. A thermistor changes its resistance depending on temperature. The control unit records the voltage in the circuit, correlates it with the embedded characteristic, and obtains the temperature value.

Some parameters do not have a separate sensor at all. Calculated engine load, fuel trims, and a number of other indicators appear directly as a result of ECU calculations.

Therefore, the phrase "the scanner showed 110 degrees" technically means something completely different: the control unit informed the application that, according to its available data, the temperature is 110 degrees. However, an error can occur even before the information reaches the adapter. For example, the sensor itself may malfunction, damaged wiring can alter the signal, and the ECU may receive an incorrect voltage. In such a situation, the ELM327 will only transmit the received message.

How 1726 revolutions turn into a number on the screen

Imagine that the diagnostic application wants to know the current engine speed. It sends the adapter command 01 0C. Here, 01 means a request for current data, and 0C is the parameter number corresponding to engine speed.

After that, the ELM327 automatically determines the appropriate communication protocol and transmits the request to the electronic control unit. Depending on the specific car, data exchange can occur via CAN, ISO 9141-2, or SAE J1850.

The ECU forms a response: 41 0C 1A F8. Each part of this sequence has its own purpose. 41 means a positive response to the current data request. The next value, 0C, confirms that it is indeed about engine speed. And the useful information is in the last two bytes — 1A F8.

If you convert them to the decimal system, you get 6904. Then the application applies the formula provided for the standard PID and divides the result by four:

6904 ÷ 4 = 1726 rpm.

That's the whole secret.

The ELM327 itself did not calculate the engine speed. It transmitted the request, received a response from the ECU, and gave the application a sequence of hexadecimal bytes. The program then performed the calculation and converted its result into a familiar digital tachometer. A similar scheme is used for coolant temperature. Command 01 05 requests the corresponding parameter. If the ECU returns byte 7B, the program converts it to the decimal value 123, and then subtracts 40. As a result, 83 °C appears on the screen.

Why different applications sometimes show different numbers

If all programs receive data from the same ECU, it is logical to assume that the results should coincide. In an ideal situation, this is what happens. However, parameter polling is performed sequentially, not simultaneously.

Suppose the program requests speed, then temperature, pressure, throttle position, and fifteen more parameters. By the time it's the speed's turn again, the driver might have already pressed the gas pedal. As a result, two applications with different polling speeds can show slightly different values, although both are working correctly.

Other factors can also influence the result:

switching between Celsius and Fahrenheit;
converting kilometers to miles;
rounding values;
errors in formulas for non-standard parameters;
Bluetooth delays.

Therefore, two programs can indeed look at the same car and show slightly different numbers.

A cheap adapter can also make mistakes

A separate problem is related to the quality of the ELM327 itself. Cheap clones can lose part of the response, freeze with a large number of commands, or not support the declared function. Therefore, the value of a good adapter is not that it has its own super-accurate sensors. What is more important is:

connection stability;
correct protocol support;
normal operation during sequential car polling;
absence of unexpected failures.

The ELM327 itself remains an intermediary between the car and the application.

But the adapter can still perform one measurement

The original ELM327 chip has an AT RV command. It allows measuring the voltage supplied to a special input of the chip itself. In a typical circuit, the car's on-board network voltage is supplied there through a voltage divider. This is an important exception to the general rule: the adapter can indeed measure the supply voltage independently.

But even here, the reading cannot be considered absolutely accurate. The result depends on the circuit, resistor values, and calibration. For an uncalibrated circuit, the documentation indicates a typical error of about 2 percent. And for a cheap clone, the manufacturer could have saved even on two resistors, so checking the voltage with a multimeter still makes sense.

All other familiar parameters — speed, temperature, air flow, intake manifold pressure, and fuel trims — the adapter receives from the ECU.

Why the engine is visible, but airbags are not

There is another important point. The OBD-II standard was originally created primarily for diagnosing the powertrain from an environmental perspective. Therefore, a universal program usually accesses a standard set of data:

engine fault codes;
freeze frame;
readiness monitors;
standard current parameters.

However, ABS, airbags, transmission, all-wheel drive system, and climate control may use their own manufacturer-specific addresses and commands.

Sometimes the adapter's hardware can transmit the necessary request. However, the application may simply not know the required protocol or not have access to the corresponding unit. Therefore, the message "no errors" does not necessarily mean that no malfunctions were actually found in the entire car. It may only mean that no errors were found in the units that could be accessed.

What to do with a suspicious reading

If, on a warmed-up engine, the application suddenly shows -40 °C, and at idle — 8000 rpm, you should not immediately buy a new sensor or order a set of spare parts. First, you need to check the information itself and perform diagnostics sequentially:

make sure the correct units of measurement are selected;
check the same parameter in another application;
if possible, connect another adapter or a brand-specific diagnostic scanner;
compare the reading with the result of a real measurement;
after that, check the sensor, power, ground, and wiring.

The entire diagnostic chain consists of four main links: sensor → ECU → adapter → application. A strange value can appear at any of these stages. Therefore, the task of diagnostics is not to immediately name the faulty part based on a single number, but to sequentially check the entire chain.

The ELM327 in this process is not a universal measuring device, and certainly not an "electronic diagnostician" who knows everything about the car. It is a data exchange interface between the ECU and the program.

It is the application that ultimately converts the bytes received from the control unit into familiar engine speeds, temperatures, pressures, or other parameters for the driver. Therefore, when working with a cheap scanner, it is important to understand not only what the screen shows, but also exactly where each reading came from.