This is the thing most cheaply made adapters are least honest about, and it is worth setting out plainly, because it decides whether a given tool can help you with a given problem.
What the standard actually requires
OBD-II is a legal requirement, not a feature. Every car sold in the United States from the 1996 model year has to provide a standard connector, speak one of a small number of standard protocols, and expose a defined set of data.
That defined set exists for one reason: emissions. Regulators wanted any inspector, anywhere, to be able to plug into any vehicle and check that its emissions equipment was working. So what the standard guarantees is engine and emissions related: powertrain trouble codes, readiness monitors, freeze frame data, and a list of live parameters such as engine speed, coolant temperature, fuel trims, oxygen sensor readings and vehicle speed.
That is a genuinely useful set of information, and it covers the great majority of check engine light problems, because the check engine light is itself an emissions warning.
What it does not cover
Everything else in the car is outside the standard.
ABS and traction control codes, airbag and restraint system codes, tyre pressure monitoring, body control modules, climate control, and the manufacturer specific codes stored inside the transmission controller are all outside generic OBD-II. Those systems have their own modules, their own codes, and their own manufacturer specific protocols for talking to them.
An adapter that reads generic OBD-II cannot see them. That is not a limitation of a particular adapter, it is the boundary of what the standard defines, and it applies to any generic tool regardless of price.
DriveDecode reads engine and emissions systems. It does not read ABS, airbag, tyre pressure or transmission specific manufacturer codes.
The transmission case is the confusing one
P0700 is a good example of where this gets genuinely misleading.
P0700 is a standard powertrain code, so any generic adapter reads it. But what it means is only that the transmission control module has found a fault and asked the engine computer to turn the light on. It is a notification, not a description.
The code that actually says what is wrong lives in the transmission module, and it is usually manufacturer specific. So a generic scan tells you the transmission has reported something, and getting the detail behind it needs a tool that speaks that make’s protocol.
The same applies to U codes. U0100 tells you a module stopped hearing from the engine computer. Tracing that properly means polling each module on the vehicle network individually, which is not something generic OBD-II provides for.
Why B, C and U codes are unreliable on a generic tool
Trouble codes are grouped by their first letter: P for powertrain, B for body, C for chassis, and U for network.
Generic OBD-II guarantees access to P codes. It does not guarantee the others. Some vehicles will report some B, C and U codes through the standard interface, and many will not report them at all. So a generic adapter that shows no ABS codes has not proved there are none. It has proved it cannot see them.
Our code library explains B, C and U codes, because understanding what a code means is useful regardless of what read it. Reading them off your own car is a separate question, and the honest answer is that a generic adapter often cannot.
What this means in practice
If your check engine light is on, a generic adapter is the right tool and will usually get you to an answer.
If your ABS light, airbag light or tyre pressure light is on, it will not, and no amount of looking at generic data will change that. That is the point at which a make specific scan tool or a workshop is the correct next step.
Knowing which of those two situations you are in before you buy anything is the whole reason this page exists.