SAE J1979-2 (OBDonUDS): why your scanner suddenly reads less

You plug an adapter into a three-year-old car and get fewer live parameters than the same adapter gives you on a ten-year-old one. Nothing is broken. The newer vehicle is following a newer standard.

Related: WWH-OBD explained and OBD-II protocols explained.

What changed

Classic OBD-II defines its own request format. Mode 01 with a PID number gets live data, Mode 03 gets stored codes, Mode 09 gets the VIN.

Manufacturers have long used a different protocol, UDS, for their own deeper diagnostics — the data that lets a dealer read every module rather than just emissions parameters.

J1979-2 moves the legislated OBD data onto UDS as well. One protocol instead of two.

From the vehicle’s point of view that is simpler. From a generic tool’s point of view, it means the classic requests may return less than they used to.

Why manufacturers went along with it

Three reasons, and they are not all about restricting access.

Simplification. Maintaining two diagnostic stacks in every ECU costs development and testing effort.

Capability. UDS supports longer, more descriptive codes and richer data structures than the classic modes.

Security. UDS includes an authentication mechanism, and regulation now requires vehicles to control access to their networks: UN R155 and R156 vehicle cybersecurity and security gateway modules.

What it means in practice

Most vehicles still answer classic requests. Inspection equipment across the world expects them, so manufacturers keep them working for the legislated minimum.

What you may lose is the extras. Many manufacturers historically exposed more through Mode 01 than the standard strictly required. Under the newer approach, some of that generosity has moved behind UDS.

The practical symptom: fewer parameters in the supported PID list on a new vehicle.

Check that list rather than guessing. It is the vehicle’s own statement of what it will provide: supported PIDs and why parameters are missing and Mode 01 current data explained.

Three-byte codes

One visible consequence.

Classic DTCs are two bytes — P0420. UDS codes are three, with the third byte describing the failure type: short to ground, open circuit, signal above range, value implausible.

That is more informative. “P0420, efficiency below threshold” tells you more than “P0420” alone, and it removes some of the guessing about what the ECU actually observed.

Tools handle this differently: some show the full three-byte code, some map it back to a familiar two-byte form, some show both.

What still works

For an owner with a Bluetooth Classic adapter, on the vehicles most people actually drive:

Function	Status
Reading stored codes	Works
Reading pending codes	Works
Clearing codes	Works
Freeze frame	Works
Readiness monitors	Works
Core live data — RPM, load, coolant, trims	Works
Manufacturer-specific parameters	Increasingly needs enhanced access
Chassis, body, restraint modules	Needed enhanced access all along: scan tool limits

The legislated minimum is still legislated. That is the reason a generic tool remains useful.

The direction to watch

Diagnostics is moving toward authenticated access over Ethernet: DoIP explained.

There are legitimate security reasons — a vehicle network reachable by IP is reachable by an attacker: car cybersecurity and CAN injection theft.

There is also a genuine policy question about whether independent workshops and owners retain meaningful access: right to repair and diagnostic data access and the EU Data Act and vehicle data.

What to do about it

1. Read the supported PID list first on any unfamiliar vehicle.
2. Do not assume a missing parameter means a fault — it may simply not be offered.
3. Log what your vehicle does provide and build a baseline from that.
4. Know the boundary before you need something on the other side of it.

Pair an ELM327 adapter, open the free tier of the app and read what your specific vehicle supports. That list, not a general expectation, is what you are working with.