Vehicle identity

Hanterill identifies the car before saving readings from it. The Vehicle screen shows the vehicle identification number, mileage and other details reported by its control units. This guide explains where those details come from and what to do if they disagree.

How Hanterill finds and verifies the VIN#

A valid VIN is always a 17-character alphanumeric code following the international ISO 3779 standard. When you connect, Hanterill checks for the VIN in order of reliability and stops as soon as it receives a valid 17-character answer:

1. Gateway discovery announcement

Reads the VIN broadcast by the Vehicle Gateway Module when the Ethernet link first comes up, requiring zero extra diagnostic traffic.

2. Direct gateway identity read

Asks the primary gateway module directly for its stored VIN.

3. Broadcast identity read

Asks all awake modules on the bus to report the vehicle VIN.

4. Active module sweep

Checks individual responding control units until a valid 17-character VIN is confirmed.

Alongside the VIN, Hanterill reads the Central Electronic Module's hardware and diagnostic identity block so the car's core configuration is available immediately.

What you see on the Vehicle screen#

The Vehicle screen brings together the car's core identity and cross-module consistency checks in one place:

• Full VIN with one-click privacy masking: The full 17-character VIN is shown clearly on the Vehicle screen and in Inspection Reports so you can verify the car against its registration documents and chassis plate. Whenever you want to take a screenshot or share a report, a single click masks the identifying characters.
• Cross-module odometer check (up to 29 modules): Modern cars store mileage in many control units besides the dashboard display. Hanterill reads and compares odometer values across up to 29 modules so you can see whether all modules agree or whether a module was replaced or tampered with.
• Paired keys, live transponder and locking history: Displays how many keys are currently paired to the immobilizer (flagged when a car carries more than the two it is sold with) and shows live recognition when a key fob or transponder is detected inside the cabin. A dated history of recent locks, unlocks and key-button presses (each with its odometer reading) shows how the car has actually been used. This is especially useful when buying a used car to verify that no unaccounted keys remain registered.
• Tyre-pressure sensors: Shows whether the wheels have tyre-pressure sensors learnt in. When the test car has none, the card says so and explains that the app watches wheel speeds instead: a reading that names its own limitation rather than showing a blank.
• Vehicle operating mode: Shows whether the car is in normal customer driving mode or left in workshop, factory, or transport mode.

How the vehicle platform is detected#

Hanterill never guesses your car's platform from a single clue. Instead, it combines multiple pieces of live evidence (the VIN prefix and manufacturer code, the gateway's identity signature, and the exact control units that answer on the network) to confirm whether the car is built on CMA, SPA, SEA1, or one of the newer Geely architectures such as SEA2/PMA2 that the app recognizes at research grade.

Platform detection requires agreement across at least two independent checks (for example, both the vehicle identity and the responding controller signatures). If a car is only partially awake and does not provide enough evidence yet, Hanterill marks the platform as a provisional candidate rather than locking in a guess.

What a resolved vehicle profile includes#

Once Hanterill identifies your car, it builds a session profile containing:

• Platform architecture (CMA, SPA, or SEA1) and how confidently it was matched
• Make, model, and model year (read from the vehicle's configuration records)
• Powertrain type (pure battery-electric, plug-in hybrid, mild hybrid, or combustion)
• High-voltage battery cell layout (such as 108 cells across 27 modules on standard CMA packs, verified against the actual number of cell sensors that answer)

The identity guard (preventing mixed-car sessions)#

If you work on more than one vehicle in a garage or reconnect after a pause, Hanterill's identity guard makes sure data from two different cars is never combined into one session or report.

When you first connect, Hanterill records the car's 17-character VIN. Before starting a multi-phase scan or resuming an interrupted fault-code sweep, it re-checks the live VIN from the car:

Matching VIN

The same vehicle is connected; the scan or resume continues normally.

Module temporarily silent

If a module is briefly busy, Hanterill does not falsely trigger a mismatch.

Different VIN detected

A different vehicle is on the cable; Hanterill stops immediately and keeps the existing session clean.

The same protection applies when comparing two saved sessions on your computer: if the two sessions carry different VINs, Hanterill blocks the side-by-side diff so you never accidentally compare firmware or battery health between two different cars.

How module addresses are matched to your platform#

Every platform uses its own address book:

• CMA vehicles use the 49-module CMA registry.
• SPA vehicles use the 41-module SPA registry.
• SEA1 vehicles use the 25-module SEA1 registry.

If a feature asks for a control unit that does not exist on the connected platform, Hanterill cleanly skips that read and marks it as not applicable rather than sending messages to an unknown address.

Next#

• Supported vehicles: see which models belong to CMA, SPA, and SEA1.
• ECU reference: explore the modules that report identity and mileage.
• Vehicle configuration: inspect your car's factory build options and equipment list.