Reference
Data identifiers
What a DID is, how values are scaled, and scan, scan-all and watch.
A car's control units hold individual readings such as battery voltage, temperature and software version. Each reading has a reference number, which the app calls a data identifier. Hanterill can read one value or collect many values during a scan. This page explains how those readings become the numbers you see on screen and why some cannot yet be interpreted.
What a Data Identifier is#
Every control unit in your car holds hundreds of internal data points. Each data point has a unique reference number called a Data Identifier (DID). When Hanterill wants to know the battery pack's state of charge or the cabin temperature sensor reading, it sends a "Read Data by Identifier" request to that module asking for that reference number, and the module replies with a short sequence of raw data bytes.
The same reference number does not always mean the same thing on two different modules. One reference number might represent a percentage on the battery module and a completely different temperature or counter on the climate module. Because of this, Hanterill's catalogue pairs every Data Identifier with the specific control unit it belongs to, except for standard vehicle-wide records such as the VIN or software part numbers.
How the catalogue turns raw bytes into real-world units#
When a control unit answers a read request, it sends back raw numbers (bytes) without any labels. To make those bytes useful to a person, Hanterill's built-in catalogue stores the translation recipe for each known identifier:
- Expected data length: How many bytes the module should return so the app never misreads a truncated or mismatched reply.
- Scaling formula and unit: How to convert the raw number into physical units such as volts (
V), amperes (A), degrees Celsius (°C), percentages (%), or kilometres (km). - Plausibility range: The minimum and maximum realistic physical values (for example, checking that a cell voltage is within a realistic lithium-ion range rather than showing a nonsensical number if a sensor is disconnected).
- Category: Whether the reading belongs to Identity, Configuration, Battery, Thermal, Motor, Charging, Body, Chassis, Driver Assistance (ADAS), Infotainment, or Diagnostics.
- Confidence and maturity grade: How thoroughly the formula has been verified across real vehicles.
Maturity grades#
Every catalogued reading carries a maturity label so you always know how much weight to give a number:
- verified
- Confirmed across live vehicles with verified units, scaling, and physical bounds.
- high / medium
- Well-understood reading whose behaviour matches expected physical changes on the car.
- provisional
- Read from the car and decoded with a working formula that is still being cross-checked across more vehicle trims.
- experimental / unknown
- The module answers with data at this identifier, but the exact physical unit or scaling formula is still unconfirmed.
If a module returns data for an identifier that does not yet have a confirmed formula, Hanterill keeps the raw response and labels its meaning as unconfirmed rather than hiding it or guessing.
Asking a module how it scales a value#
For identifiers that are not yet decoded in the built-in catalogue, Hanterill can also ask the control unit whether it provides its own scaling description. If the module supports this read-only request, Hanterill records the scaling information alongside the reading.
Inside the DID Explorer screen, you can also inspect any raw response using built-in viewing helpers (such as plain text, whole numbers, millivolts-to-volts, or tenths-of-a-degree) to see how raw data behaves in real time.
Why a reading can come back blank or skipped#
Every time Hanterill requests a Data Identifier, it records the exact outcome so nothing fails silently:
- Validated reading
- The module answered with the expected data length, and the formula produced a realistic physical value.
- Unvalidated reply
- The module answered with data, but there is no confirmed formula in the catalogue yet, so raw bytes are shown.
- Unexpected length
- The module returned a different number of bytes than expected for this software version, so Hanterill safely skipped decoding rather than showing a wrong number.
- Out-of-range value
- The decoded value fell outside realistic physical bounds (for example, an unplugged sensor reporting an extreme number).
- Unsupported by module
- The module politely replied that this specific car or trim level does not support that data point.
- No response / timeout
- The module did not answer in time, usually because the module is not fitted on this car or is asleep.
Four ways to read Data Identifiers#
Depending on what you are investigating, Hanterill offers four read modes in the DID Explorer:
| Mode | Scope | Best used when you want to... |
|---|---|---|
| Single read | One module, one identifier | Check a single live value or identity record right now |
| Bounded sweep | One module, a selected range of identifiers | Discover which data points a specific control unit supports |
| All-module scan | Every selected module across the car | Capture a complete snapshot of every readable value on the vehicle |
| Live watch | One module, a small group of identifiers over time | Watch how several values change as you operate a switch, pedal, or charger |
1. Single read and bounded sweep#
A Single read asks one module for one value immediately. A Bounded sweep steps through a range of identifiers on one module within a request limit you choose, automatically pausing briefly if the bus is busy and recording which identifiers answered with data and which were unsupported.
2. All-module scan (three-phase vehicle snapshot)#
When you run a full all-module scan, Hanterill works through three organized stages so the car's network is never overwhelmed:
- Presence check: Confirms which control units are awake on the car and verifies the vehicle's VIN so a scan never mixes data from two cars.
- Catalogue and discovery reads: Reads all known catalogued values for every responding module, plus optional discovery ranges if you choose an extended sweep.
- Verification and scaling checks: Re-samples changing values to see whether they are static settings or live sensors, and checks whether modules report scaling hints for newly discovered values.
When exporting scan results, you can choose a privacy level: keep full details for your own records, mask your VIN and serial numbers for a support bundle, or strip all vehicle-identifying fields before sharing publicly.
3. Live watch (tracking changes over time)#
A Live watch repeatedly reads a small group of identifiers on one module at a steady interval (by default 30 samples spaced 10 seconds apart, or adjustable down to four times per second). Across the samples, Hanterill automatically highlights how each value behaves:
- Static values: Numbers that never change across the run (usually part numbers, configuration settings, or calibration constants).
- Counters: Values that step upward steadily over time (such as operating-hour timers or cycle counters).
- Dynamic sensor telemetry: Values that move up and down as the car's state changes (such as voltages, temperatures, pressures, or pedal positions).
If you stop a watch early, Hanterill still saves and summarizes all the rounds completed so far.
Next#
- ECU reference: the control units these readings come from.
- Firmware and inventory: how identity reads build a full software map of your car.
- Capabilities and gating: how Hanterill determines which features your car supports.