Last time we described using AI to write OBD capture software and keeping the responses returned by the vehicle. This time we read the first log from a 2009 Mercedes-Benz W204 C63 AMG. Standard OBD stored and pending fault codes were zero. Even so, the cause of the starting problem has not been determined.

When you look at a fault-code count, you also need to check what range the query covered. Here we set out what this one capture told us and what was left for the next measurement.

DTC stands for Diagnostic Trouble Code — the fault codes read during diagnosis.

Data captured with the key on #

The measurement date was 13 October 2026. An OBDLink EX was connected to the vehicle's OBD connector and a Windows PC, and data was captured with the key on and the engine off. Communication was set to ISO 15765, 11-bit, 500 kbit/s, and during the capture of about 4.4 seconds two response addresses answered. This is a record of communication confirmed with those settings, not the result of automatic detection.

7E8 and 7E9 are the addresses the answers came from. We have not yet matched them to specific Mercedes control-unit names. The VIN (vehicle identification number) was also obtained, but no information that identifies the individual car is published in this article.

With the engine stopped, 0 rpm is consistent with the measurement conditions. On the other hand, an absolute throttle position of 16.08 % does not mean the pedal was pressed that far. Recording item names correctly reduces the risk of misreading a bare number.

Separating zero from not acquired #

Standard OBD has a service for each purpose: Mode 03 reads stored DTCs, Mode 07 reads pending DTCs, Mode 0A reads permanent DTCs, and so on. Reading the results starts with keeping these categories apart. (OBD Solutions: OBD services)

For the stored-DTC request this time, we recorded the following responses.

Request  03
Response 7E9 02 43 00
Response 7E8 02 43 00

From these two answers we interpret the stored standard OBD DTCs as zero. Pending DTCs were also zero. However, this software did not query manufacturer-specific fault memories such as SAM, EIS or ESP. A standard OBD zero cannot be stretched into "no errors in any system of the vehicle".

For permanent DTCs, the vehicle returned NO DATA. In the analysis we did not record this as zero but as "not acquired". The absence of a response alone cannot tell you whether there are no codes or whether there is a support or communication issue. If you turn every blank into a zero when building a summary table, the meaning changes right here.

We do have AI summarise the results, but the input always carries the service number, the response address, the raw reply and the parse status. Being able to return to the original response whenever a conclusion looked doubtful turned out to be more useful than a prose explanation alone.

Setting the symptoms beside the conditions #

Earlier there had been reports of the cooling fan running fast straight after a cold start. This time, with the key on and the engine off, it did not. We also got a coolant temperature of 21 °C, but conditions after starting and with the engine stopped are different. We have not concluded from this result alone that the fan problem is resolved.

As for cranking, the starter was reported to turn the engine over briefly and then stop. This is recorded separately from the earlier state of no response at all. This log did not measure that moment, so 0 rpm and 11.6 V cannot be used as data from cranking.

The OBD connector read 11.9 V with the key off and 11.6 V in the first key-on capture. These are values read by the adapter, not direct measurements of the battery's resting voltage at its terminals or of the voltage drop during cranking. Next we plan to arrange conditions in which the battery can be charged and measured, and to check the battery and the main power supply. The current values alone are not enough to decide on a battery replacement.

Preparing what we hand to AI #

What this capture confirmed is that standard OBD answered under the specified conditions and that we could save a number of values. Start authorisation, CAN communication across the whole vehicle and the health of each module are still unknown.

When diagnosing together with AI, handing over what was acquired, what was not acquired and what a person observed as separate items makes it easier to decide what to check next.

We decided to prioritise checking the power supply and then move on to manufacturer-specific diagnostics. Next time we describe what we researched, and how far we prepared the software, to attempt those diagnostics with the OBDLink EX we already had.