OBD2 PIDs identify requested data. The vehicle still decides what it supports.

The plain answer

PID means parameter identification. In a standardized OBD request, the scan tool sends a service or mode and a PID that names the item it wants. The vehicle can then return response bytes for that item when it supports the request and has data available.

Think of the mode as the shelf and the PID as the labeled slot. A valid reading still requires the right reply inside that slot.

A PID is not a sensor, diagnosis, or repair instruction. It is an identifier in a communication contract. Several modules, calculations, and operating conditions may influence the value a vehicle reports.

Mode, PID, response, value

The ELM327 data sheet explains that the first request byte identifies the diagnostic mode and later bytes identify the requested parameter. SAE J1979 defines the regulated emissions-related services and data used between compatible vehicles and test equipment. A typical current-data request follows this path:

1. The app chooses the intended standardized mode and PID.
2. The adapter carries the request over the selected vehicle protocol.
3. One or more controllers may return response lines.
4. The app matches the positive response mode and exact PID echo.
5. The app checks byte count, decodes the bytes, applies units, and sets quality.

Each step can fail independently. A successful Bluetooth connection proves only that the phone reached the adapter. It does not prove that the vehicle supports the PID or that the final number passed validation.

Support bitmaps prevent blind guessing

Standardized PID ranges include support requests. The ELM327 documentation describes PID 00 within a mode as the request used to report which following PIDs the vehicle supports. The response acts like a row of switches. Each bit corresponds to a PID in the covered range. A set bit advertises support, while an unset bit does not.

Further support-range requests can describe later PID blocks when the applicable continuation bit says another block exists. Software should walk only the advertised ranges and preserve the raw bitmap for debugging. It should not poll a giant memorized list and treat every timeout as a normal zero.

An advertised bit is evidence of declared support. It does not guarantee that every later request will return a timely, unique, well-formed value under all operating conditions. Response validation still comes next.

Supported, unavailable, and invalid are different

Zero can be a legitimate measurement for some parameters. That makes it a dangerous fallback for missing data. Software must keep absence separate from a measured zero.

“NO DATA” does not mean “everything is fine”

The ELM327 data sheet uses “NO DATA” when its wait period ends without a matching vehicle response. It lists several possible causes, including no data for that PID, an unsupported mode, a busy vehicle, or a response hidden by a filter. Timing and transport configuration can also affect what the interface sees.

Keep that message as a transport or availability observation. It does not prove a component works, a code is absent, or the vehicle is safe. Repeated requests and a clean connection can help separate a transient transport problem from consistent lack of support, but qualified tools and service information decide the diagnostic next step.

Multiple replies need provenance

More than one controller can answer a functional OBD request. The ELM327 documentation describes multiline responses and header display because a tool may need to distinguish senders. A parser must not mix bytes from separate response lines or silently choose a convenient value.

A useful record keeps the request, matching response, controller or header context when available, decoded value, unit, timestamp, and quality reason. That provenance matters when two controllers return different values or one replies after another.

Decoding is part of the measurement

A response begins as bytes. The app must apply the reviewed definition for that PID, including byte order, byte count, scale, offset, signedness, and unit. It must reject a response for another mode or PID. It must also reject a non-finite or out-of-contract result.

Our companion guide, why OBD2 live data needs range checks, follows that pipeline from request through gauge. The important rule is simple: a polished number does not become trustworthy until its identity, bytes, formula, unit, and range agree.

What to save when a value looks wrong

• PID label, displayed value, unit, time, and quality state.
• Selected vehicle and the controller or response source when available.
• Adapter model, connection transport, phone, operating system, and app version.
• The exact raw request and matching response when the tool exposes them.
• Operating context you observed without converting it into a diagnosis.

Do not choose a repair or make a safety decision from one suspicious live value. Use the owner’s manual and qualified help for warning lights or symptoms that affect vehicle operation.

Axlyne’s PID boundary

Axlyne requests a reviewed set of supported standard generic OBD2 parameters. Its current Mode 01 path checks the response mode, PID echo, expected bytes, finite result, and defined range before showing a normal numerical value. Unsupported, no-data, decode-error, and out-of-range results remain separate states.

Vehicle, controller, adapter, protocol, phone, and operating conditions affect the available parameters and update rate. Axlyne does not claim manufacturer-enhanced PID coverage or use a live value as a diagnosis, safety certification, or repair order.

Official sources

• SAE International, current J1979 diagnostic test modes
• SAE International, current J1978-1 OBD2 scan-tool functions
• U.S. EPA, OBD inspection and maintenance program guide
• California BAR, On-Board Diagnostic Test Reference
• ELM Electronics, ELM327 data sheet