OBD-II diagnostics

What you can and cannot get from the OBD-II socket on the U5, worked out by probing it with a cheap USB-CAN adapter and cross-checking against the head unit's own readouts. Short version: you can read a great deal, but you cannot write anything without the manufacturer's secret key. See CAN bus for how this port differs from the internal buses.

• OBD-II pin 6 = CAN-H, pin 14 = CAN-L (ground on 4/5, permanent 12 V on 16). This is the only CAN pair on the connector — no second bus, no automotive Ethernet / DoIP.
• Passive listening is silent at every bitrate — nothing is broadcast here.
• Active requests are answered at 500 kbit/s, 11-bit (ISO 15765-4). 29-bit and other bitrates stay silent.
• The port sits on a dedicated diagnostic CAN that dead-ends at the central gateway. The gateway bridges the car's separate internal buses — powertrain, chassis, body/comfort, infotainment, telematics — and routes each request to the target ECU. So you can reach every ECU through it, but the connector never carries the live internal broadcasts. You can poll; you cannot sniff here. This is a genuine central-gateway firewall.

Standard emissions services work, addressed functionally to 0x7DF (responses on 0x7E8):

• Mode 09 — VIN (09 02) and calibration IDs.
• Mode 03 / 07 / 0A — stored / pending / permanent DTCs.
• Mode 01 — live PIDs. The primary powertrain endpoint (0x7E0) reports a supported-PID bitmask of BF FB FF F7 and, usefully on an EV, PID 0x5B (“hybrid/EV battery remaining charge”).
• Mode 04 — clear emissions DTCs (see Clearing fault codes below).

As on any EV, generic OBD exposes little — VIN, generic fault codes, a couple of values (mostly 0 while parked). Everything interesting — real SoC, pack voltage, cell data — lives in the manufacturer UDS layer below.

The gateway routes UDS requests to the internal ECUs. Enumerate them gently with a single functional TesterPresent (3E 00 → 0x7DF): it changes nothing, yet every reachable ECU answers from its own ID. On the U5 this finds 24 ECUs. Response ID = request ID + 8 (e.g. 0x701 → 0x709).

The internal ECUs reachable this way are the usual EV set: BMS, VCU, motor controller, on-board charger, gear selector (powertrain); BCM, A/C module, PTC/compressor, seat heaters, tailgate, low-speed warning (body); ESP, EPS, iBooster, airbag, steering-angle sensor, cameras/radars (chassis); head unit, instrument cluster (infotainment); T-Box (telematics). Exact address↔module mapping is only confirmed for 0x7E0/0x7E1; the rest is inferred from the data and address block.

In the default session (no session change) you can typically:

• 0x19 ReadDTCInformation — stored fault codes, decoded (19 02 FF = report by status mask).
• 0x22 ReadDataByIdentifier — read data by 16-bit DID.

The identification block (DIDs 0xF180–0xF1FF) returns, on most ECUs: a part number in an 8619xxxxx scheme, a supplier code (CS-000xxx), a programming date, and the VIN (0xF190). Example from one ECU: part 861923101B, supplier CS-000029, programmed 2021-11-10. Sweeping these across all 24 ECUs builds a full part-number / build map of the car — no public Aiways ECU list exists otherwise.

The BMS (0x7E1) carries a live measurement block around DIDs 0x8800–0x887F — roughly 120 aggregate battery values: pack voltage, current, cell voltages, SoC, temperatures, and status words. This is where the numbers the head unit does not expose (cell min/max, temperatures, state-of-health) should live.

A broad scan — sweeping many ECU addresses and forcing an extended session (10 03) — makes ECUs stop their normal CAN broadcasts. The instrument cluster then flags the “missing” modules with warning icons, and a downstream display can freeze on a substituted value (we saw the outside-temperature reading stick). It is read-only and reverts once probing stops, but:

• Never run a broad/aggressive scan while driving — an ECU dropping off the bus mid-drive is unsafe.
• Prefer the gentle method: functional discovery + default-session reads only (0x19 / 0x22), no session control. A single-ECU default-session read does not disturb the dash.

The last two hex digits of a DTC are the standardised failure-type byte: …88 = CAN Bus Off, …87 = missing message / timeout, …82/83 = rolling-counter / checksum. So a `U…87` / `U…88` code means “lost communication”, not a real hardware event.

A consequence: any bus or power interruption — including an aggressive scan — makes many modules log “lost communication” against each other at once. After a heavy scan expect a long list of U-codes (and contiguous B-/C-code ranges); these are artifacts, self-clearing over clean drive cycles. The codes worth attention are the powertrain P-codes, which point at real sensor / HV faults. Read them all with 0x19 first, then judge.

Manufacturer-specific codes (second character `1`, e.g. P110C00) turn out to be properly documented and genuinely EV-relevant — HV contactor voltage checks, BMS current-sensor faults, CAN gateway message timeouts, crash/airbag signalling. None of them are combustion-engine leftovers. The following battery-management codes have been identified and confirmed:

Every code here clears automatically if absent for 40 drive cycles, or via a diagnostic tool. The standard repair escalation is: cross-check codes on other modules → inspect harness/connector → check HV harness insulation resistance (target >1.5 MΩ, ≥120 MΩ for the PTC heater, at 500 V DC) → replace the battery pack assembly as a unit — there is no component-level BMS board repair path.

By contrast, the generic/SAE codes (second character `0`, e.g. the P02C1/P01C1 seen during live scans above) sit in ranges the standard defines for combustion-engine subsystems — P02xx is nominally “fuel injector circuit,” meaningless on this car. The ECU reporting them self-identifies over Mode 09 as HPCM-HybridPtCtrl (“Hybrid Powertrain Control Module”) — a real hint its diagnostic software is inherited from a hybrid/ICE platform, with some legacy generic checks never fully pruned for the pure-EV variant. Treat unexplained generic P0-range codes with suspicion; the manufacturer-specific P1xx range is the trustworthy one.

Charging-system codes have also turned up, though only as bare identifiers so far (no definitions found yet): P120019, P120119, P122000, P122100, P128A19, P128B98, P12A500. If anyone can pin down what these mean, please add it here.

Coverage note: a systematic search turned up fault-code documentation only for the battery-management codes above and this bare charging-system list — nothing yet for ESP, parking brake, brake booster, steering, HVAC, or body-electrics modules. If your car throws a code in one of those areas, this wiki doesn't have it documented — please add whatever you find.

There is no public scaling for the manufacturer DIDs, so raw values are decoded by correlation — read a DID while you know the true value from another source (the head unit's decoded readout is ideal), and find the field + scale that match. A field is only trustworthy once you can make it move: switch a big HV load (A/C compressor) on and off and watch which fields track.

Confirmed on the BMS (0x7E1) this way:

• Pack voltage = DID 0x8871 (raw = volts; read 407 vs head-unit 406.9 V).
• Pack current = DID 0x887b (rises with load; identified by the A/C on/off test).

State-of-charge and the 12 V system voltage have plausible candidates but are not yet nailed — near-constant signals need the car in different states (a drive, a charge) before their field and scale can be confirmed. The decoded numbers sanity-check against the known pack spec (≈268–417 V range, 24 modules, cell 2.8–4.35 V), so e.g. a 0x882d reading of ≈4.01 V is a real cell voltage. A logger that records reference values and DIDs together across normal driving is the clean way to finish the map.

Clearing DTCs is the one “write” normally allowed without Security Access (it is needed for repair):

• Generic — Mode 04 (ClearDiagnosticInformation): send 04 to 0x7DF / 0x7E0. Clears emissions DTCs and freeze frames.
• Manufacturer — UDS service 0x14: send 14 FF FF FF (“clear all groups”) to a specific ECU (e.g. 0x7E1). Clears that module's stored DTCs, usually in the default session.

Notes: clearing masks real faults (good and bad alike) — read the codes first. Permanent DTCs cannot be cleared by a tool; the ECU clears them itself after its readiness monitors pass. A 12 V battery disconnect resets volatile display state but does not clear stored DTCs (non-volatile) — for that you need a clear command.

Diagnostic requests on this port wake the gateway and addressed ECUs for diagnostics (that is how a scan tool works on a parked car). That is a diagnostic wake only — it does not power up the HV system, close the main contactors, or start climate. Those are actuation functions behind Security Access.

Everything that changes or actuates — writing configuration (0x2E), actuator tests (0x2F), routines (0x31), ECU reset (0x11), flashing (0x34/0x36/0x37) — sits behind Security Access (0x27). The gateway answers a seed request, but the key algorithm is an OEM secret that is not public for this car. So in practice OBD-II here is read-only: fault codes and data yes, control no.

The interesting exception: a dealer tool activates functions like HV power-up or preconditioning via a security-gated routine (0x31) over this same diagnostic CAN. So the diagnostic port is not architecturally a dead end for control — with the correct Security-Access key, remote preconditioning could in principle be commanded straight over OBD-II, no internal-bus tap required. The key is the missing piece (see roadmap).

Under the hood this is plain UDS (ISO 14229) over ISO-TP (ISO 15765-2) on 500 k / 11-bit CAN — nothing proprietary at the wire level. That means standard open tools work: a small ISO-TP + UDS client in Python, or off-the-shelf car-diagnostic tools, will talk to this car. What is not open is the data dictionary (which DID means what, with what scaling) and the Security-Access key — both live in the manufacturer's diagnostic database.

A CANable-class USB-CAN adapter (gs_usb) on 500 k / 11-bit, driven from Python (raw frames + a small ISO-TP layer for multi-frame UDS).

• Wire CAN-H → OBD pin 6, CAN-L → OBD pin 14, ground to pin 4/5. Getting this wrong looks exactly like a dead bus.
• Adapter DIPs: Boot OFF (run), R120 OFF (the OBD-II bus is already terminated 2×120 Ω). A DIP change only takes effect after a full unplug/replug.
• Confirm wiring by watching the adapter's TX and RX LEDs blink during an active probe.