A scanner can decode a number and still be wrong. Range checks catch the lie.
Live OBD2 data travels through a vehicle, adapter, radio, parser, formula, and unit conversion before it reaches a gauge. Each boundary needs a check.
A polished gauge can hide a broken decode
A phone receives bytes, not a trustworthy dashboard value. The app must prove that the response belongs to the requested mode and PID, contains the right number of bytes, decodes to a finite number, uses the intended unit, and stays inside the value contract. Skipping one check can turn unrelated bytes into a smooth-looking gauge.
“Unavailable” is a valid result. A confident impossible number is not.
This matters because humans trust visual precision. A value shown to one decimal place looks measured even when it came from a stale response, wrong PID, missing byte, or bad formula.
The seven gates between bytes and a gauge
- Command gate. Build the request for the intended standardized mode and PID.
- Transport gate. Require one complete response rather than mixing fragments, prompts, status text, or multiple ECU lines.
- Echo gate. Confirm the positive response mode and requested PID are present in the expected positions.
- Length gate. Require the exact data-byte count the PID definition needs.
- Decode gate. Apply the correct formula, byte order, signedness, scale, offset, and unit.
- Numeric gate. Reject NaN, infinity, and other non-finite results.
- Range gate. Mark values outside the PID’s defined contract instead of displaying them as normal readings.
A physical plausibility check can add context after those protocol gates. It must not silently rewrite the returned observation. Keep the raw response and quality state so a developer or technician can audit what happened.
How impossible values appear
| Failure | What goes wrong | Safer behavior |
|---|---|---|
| Wrong response line | A parser grabs another ECU’s line or a reply for a different PID. | Require one canonical matching response or report no data. |
| Missing byte | The formula reads a default, shifted, or unrelated byte. | Require the exact byte count before decoding. |
| Wrong scale or offset | A valid raw byte becomes the wrong engineering value. | Bind each standard PID to one reviewed definition and unit. |
| Unsupported response | Status text or a negative response is mistaken for data. | Keep not-supported and no-data states separate from numeric values. |
| Out-of-contract result | A decode returns a number that the definition does not permit. | Label it out of range and keep it off the normal gauge. |
Percent signs deserve the same skepticism as bytes
Consider a gauge whose user-facing contract is zero through one hundred percent. A raw decoded value of 255 should not appear as an ordinary “255%” reading. The screen must either explain a different documented unit or reject the value. The same rule applies to a trim gauge that lands outside its reviewed definition, an impossible negative speed, or an engine speed that exceeds the gauge contract.
A range gate does not diagnose the cause. It says the current value failed the software contract. The source could be the response, adapter, parser, formula, PID selection, unit conversion, or a definition that needs correction.
Axlyne’s standard PID boundary
Axlyne’s standard Mode 01 decoder checks the positive response mode, exact PID echo, exact byte count, finite decoded number, and the definition’s minimum and maximum. Its phone gauge surfaces render a numerical reading only when the quality state is OK. Other states remain no data, unsupported, decode error, or out of range.
This behavior is intentionally narrower than filling every card with a value. A vehicle may return only some supported standard PIDs. Update rate and availability vary by vehicle, adapter, protocol, phone, and connection.
What a driver can do when a reading looks wrong
- Do not make a repair or safety decision from one suspicious phone value.
- Park safely and reconnect the adapter using the correct phone transport.
- Record the PID label, value, unit, time, vehicle, adapter, phone, OS, and app version.
- Compare the behavior across repeated requests without changing several variables at once.
- Use qualified equipment and service information when the value affects diagnosis or vehicle operation.
If the app exposes a raw response or quality reason, preserve it. A screenshot of only the final gauge removes the information needed to find the bad boundary.
What developers should test
- Correct response, wrong response mode, and wrong PID echo.
- Short, exact, and extra byte counts.
- No-data, negative-response, timeout, prompt-only, and adapter-status lines.
- Minimum, maximum, just-inside, and just-outside range values.
- NaN, infinity, signed values, unit toggles, and rounding boundaries.
- Multiple ECU replies, fragmented BLE notifications, and reconnects after stale data.
Tests should assert both the number and its quality state. A parser that returns the expected number with the wrong provenance can still be unsafe to display.