Unlocking Advanced Car Diagnostics: Mastering Car Scanner Custom PIDs

For automotive enthusiasts and professional mechanics alike, car scanners have become indispensable tools for diagnosing vehicle health. While standard car scanners offer a wealth of information through predefined Parameter IDs (PIDs), the true power of these devices is unleashed when you delve into Car Scanner Custom Pids. These custom sensors allow you to access data beyond the standard OBD-II parameters, pulling information directly from your car’s Electronic Control Unit (ECU) as defined by the manufacturer. This capability is crucial for in-depth diagnostics and performance monitoring.

Creating custom PIDs might seem daunting at first, but with a clear understanding of the process, you can tap into a wealth of vehicle-specific data. This guide will walk you through the essentials of setting up car scanner custom PIDs, empowering you to retrieve and interpret data tailored to your car’s unique specifications. To effectively create custom sensors, you need two key pieces of information: how to request the data and how to decode the ECU’s response.

Understanding the Essentials: Command and Formula

To create a custom sensor, you must define how your car scanner communicates with your vehicle’s ECU. This involves specifying two critical elements: the Command and the decoding Formula.

1. Crafting the Command: Requesting Specific Data

The Command is essentially the instruction your car scanner sends to the ECU to request specific data. It’s composed of two parts:

Mode: This defines the type of diagnostic service you’re requesting. For many common parameters, Mode 01 (Show current data) is used.
PID (Parameter ID): This is a specific code that identifies the data you want to retrieve within the chosen Mode. For example, 0C in hexadecimal corresponds to engine RPM.

Combining these, a command to request engine RPM would be 010C.

In addition to the Command, you may need to specify the Header. The Header is the address where the request is sent, particularly relevant for CAN (Controller Area Network) protocols. For instance, 7E0 is a common header for CAN 11-bit communication. In many cases, you can leave the Header field blank, and the car scanner will automatically use the default functional header for your car’s communication protocol. However, for many custom PIDs, providing the correct Header is essential for successful data retrieval. Consult your vehicle’s service manual or online resources specific to your car model to determine the correct Header, if needed.

2. Decoding the Response: The Formula

Once the car scanner sends the Command, the ECU responds with a string of data. The Formula is the equation that tells the car scanner how to interpret this raw data and convert it into a meaningful value.

The formula uses letters to represent bytes within the ECU’s response. A refers to the first byte of data, B to the second, C to the third, and so on, up to Z, then AA, AB, and continuing.

Important! Formulas are case-sensitive. Ensure you use uppercase letters for byte references and function names as specified.

To understand byte assignment, car scanners typically skip certain parts of the ECU response before processing the data bytes. This skipped information usually includes header bytes, data length indicators, response markers (like 41 for Mode 01 responses), and the PID identifier itself.

Let’s revisit the engine RPM example. A request for 010C (engine RPM) might yield a response like: 7E804410C**0C9C**. The car scanner would skip 7E804410C, leaving **0C9C** as the data. In this case:

A would represent the byte 0C
B would represent the byte 9C

You can then use these byte representations in mathematical formulas. Basic operators like addition (+), subtraction (-), multiplication (*), and division (/) are supported. For example, a simple formula could be A+B. To control the order of operations, use parentheses, like (A*256+B)/4. Formulas can also include floating-point numbers, for example A+13.54.

Advanced Formula Functions: Bitwise Operations and More

For more complex data decoding, car scanner custom PIDs often support a range of advanced functions:

Bitwise Functions:

@~: Bitwise unary complement (NOT)
@&: Bitwise AND
@^: Bitwise exclusive OR (XOR)
@<<: Shift left
@>>: Shift right

Example: A@&B performs a bitwise AND operation between byte A and byte B.

Additional Functions:

GetBit(A,N): Extracts a specific bit from a byte. A is the byte number, and N is the bit number (0-7).
SIGNED(A), signed(A), Signed(A): Interprets a byte as a signed 8-bit integer (-128 to 127).
ShortSigned(A,B): Interprets two bytes as a signed 16-bit integer.
And(A,B): Bitwise AND (same as A@&B).
Shr(A,B): Bitwise shift right (same as A@>>B).
Shl(A,B): Bitwise shift left (same as A@<<B).
MAX(A,B): Returns the maximum value between A and B.
MIN(A,B): Returns the minimum value between A and B.
abs(A): Returns the absolute (unsigned) value of A.
FLOAT32(A,B,C,D), float32(A,B,C,D): Converts four bytes into a 32-bit IEEE 754 floating-point number.
FLOAT64(A,B,C,D,E,F,G,H), float64(A,B,C,D,E,F,G,H): Converts eight bytes into a 64-bit IEEE 754 floating-point number.
if(A,B,C): A conditional function. If A is true (non-zero), it returns B; otherwise, it returns C. Comparisons like =, >, <, >=, <= can be used within the condition. Example: if(A>5,5,A) – if A is greater than 5, return 5, else return A.
SetVar(key,value): Stores a value in a shared memory dictionary associated with a key (integer). Returns the stored value.
SetVarOnce(key,value): Stores a value only if the key doesn’t already exist. Returns the stored value.
GetVar(key,default_value): Retrieves a value from the shared memory dictionary using a key. If the key doesn’t exist, it returns the default_value. Example: GetVar(123,789.244).

Referencing Other Sensors:

Custom PIDs can even reference values from other sensors, either standard or custom, making complex calculations and derived data possible. You can reference other sensors in two ways:

PID(ID) or pid(ID): Use the sensor’s numerical ID. You can find sensor IDs in your car scanner app’s settings. Example: PID(5) would use the value of the sensor with ID 5.
{name}: Use the exact full name of the sensor (case-sensitive). Example: {Fuel temperature} would use the value of the sensor named “Fuel temperature”.

Action PIDs and Diagnostic Commands

Beyond retrieving sensor data, Action PIDs allow you to send commands to the ECU when triggered manually (e.g., by tapping a button in your car scanner app). These PIDs do not decode a response but simply execute a command. A common use case is initiating diagnostic routines like a forced DPF (Diesel Particulate Filter) regeneration. You’ll need the specific header and command for such actions, which are vehicle-specific.

Furthermore, you can configure Start diagnostic commands and stop diagnostic commands to be executed before and after a custom PID request, respectively. These commands should be complete ELM327 commands, separated by semicolons (;), commas (,), or backslashes (\). Example: ATCRA7E8,ATFCSH7E0,ATFCSD300000.

Conclusion

Mastering car scanner custom PIDs opens up a new dimension of vehicle diagnostics and monitoring. By understanding how to construct commands and formulas, and leveraging the advanced functions available, you can access a wealth of manufacturer-specific data, going far beyond the limitations of standard OBD-II PIDs. Whether you’re a seasoned mechanic or a dedicated car enthusiast, exploring custom PIDs empowers you to gain deeper insights into your vehicle’s performance and health. Start experimenting with car scanner custom PIDs today and unlock the full diagnostic potential of your car.