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. Short version: you can read a lot, you cannot write anything. 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.
• 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, body, chassis, infotainment, telematics) and routes each UDS request to the target ECU — so you can reach every ECU through it, but the connector never carries the live body/HVAC/battery broadcasts. You can poll through the gateway; you cannot sniff the internal traffic 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 ECU (0x7E0) reports a supported-PID bitmask of BF FB FF F7 and, usefully on an EV, PID 0x5B (“hybrid/EV battery remaining charge”).

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

The gateway routes UDS requests to the internal ECUs. You can 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.

Roles above are our inferences from each ECU's data and address block, not official.

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

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

The identification block (DIDs 0xF180–0xF1FF) returns, on most ECUs: part numbers (an 8619xxxxx scheme), a supplier code, a programming date, and the VIN (0xF190). Example from one ECU: part 861923101B, supplier CS-000029, programmed 2021-11-10.

The BMS (0x7E1) carries a live measurement block around DIDs 0x8800–0x887F — roughly 120 aggregate battery values (pack voltage, current, cell voltages, SoC, temperatures, status).

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 downstream displays 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.
• It also floods every ECU with “lost communication” fault codes against each other — harmless, self-clearing, but expect a long DTC list afterwards.

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, and find the field + scale that match. Confirmed on the BMS this way:

• Pack voltage = DID 0x8871 (raw = volts).
• Pack current = DID 0x887b (rises with load; identified by switching a big HV load on/off).

State-of-charge and the 12 V system voltage have plausible candidates but are not yet nailed — near-constant signals need the vehicle in different states (a drive, a charge) before their field and scale can be confirmed. 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” that is normally allowed without Security Access (it is needed for repair). Two ways:

• Generic — Mode 04 (ClearDiagnosticInformation): send service 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), so 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 (they are in non-volatile memory) — 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 (below).

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.

A CANable-class USB-CAN adapter (gs_usb) on 500 k / 11-bit, driven from Python (python-can style: raw frames + a small ISO-TP layer for multi-frame UDS). Set the adapter to Boot OFF, R120 OFF (the OBD-II bus is already terminated). Confirm wiring by watching the TX and RX LEDs blink during an active probe.