BESTNET TECH BLOG
Using a W204 C63 AMG that will not start, we show how work is split between people and AI, and how raw logs are kept with their conditions
The engine will not start. In the past, the cooling fan ran at high speed straight after a cold start. Faced with symptoms like these, the urge is to jump straight to a cause or a replacement part. Our subject is a 2009 Mercedes-Benz W204 C63 AMG. In bringing AI into the diagnosis, the first thing we did was save what the vehicle returned, together with the conditions it was returned under.
In this series we describe the process while keeping what we have confirmed on the car separate from what we have not. The cause of the no-start and the fan behaviour has not been determined. What the first session achieved was an original record that the next diagnosis can use, and a clear list of what to examine.
What OBD can read #
OBD stands for On-Board Diagnostics. It lets you communicate with the vehicle's electronic control units (ECUs) and read fault codes, temperatures, engine speed and so on. However, what standard OBD covers and what manufacturer-specific diagnostics cover have to be kept apart. Fault codes, live values and vehicle information each use a different read service, and the range supported varies from vehicle to vehicle. (OBD Solutions: OBD services)
The PC was connected to the vehicle with a USB OBDLink EX. After connecting, we read the device's model name and firmware response and confirmed that the unit really was an OBDLink EX.
How the work was split #
| Who | What they did |
|---|---|
| AI | Checking public documentation, writing the communication software, organising the logs that came back |
| People | Plugging in the connector, turning the key, listening to the fan and watching how the starter behaved |
The AI never stood in front of the car. Values returned by the device and symptoms that a person saw, heard and reported were kept separate in the records as well.
"Key on, engine off", for example, is an important condition when reading temperatures and engine speed. Rather than guessing the key position and starting to communicate, we waited for confirmation from the person at the car. If you have not measured the moment of cranking, you also cannot treat a voltage taken while the engine was stopped as a cranking voltage. Differences in conditions like this decide how the data can later be interpreted.
Deciding what the first capture covers #
We fixed the scope of the software in advance. The first capture was limited to identifying the adapter, checking voltage, and then reading standard OBD. No fault codes were cleared. There was no ECU reset, actuator test, coding or flash write either. To examine the fault, the policy was to keep the responses from before anything was cleared.
The word "read" needs care. In this standard OBD read, we sent request frames to the vehicle and received its responses. That is a different procedure from passively observing CAN traffic without transmitting.
The official OBDLink manual also separates commands for the adapter itself from OBD requests sent to the vehicle. The implementation was built to send only requests on an allow-list. (OBDLink Family Reference and Programming Manual)
Keeping raw logs and results #
We did not save only tidied-up numbers. We kept the commands sent, the strings and original bytes received, the time, the device and the key position, and produced the decoded results separately afterwards. That way, if the decoding is corrected later, we can go back to the original capture and check. Showing "coolant 21 °C" on screen and saving the response that produced that value serve different purposes.
We also decided never to fill items that returned no response with normal-looking values.
| State | Meaning |
|---|---|
| Zero | The query was answered normally and nothing matched |
| Not acquired | No response was obtained. Cannot be called either zero or a fault |
| Comm. failure | Communication itself could not be established |
We also avoid treating a partially received response as a complete list. The more analysis you hand to AI, the more you need records that keep these states distinct.
First results, and the next measurement #
In the short first capture, standard OBD answered normally and we confirmed a coolant temperature of 21 °C, an engine speed of 0 rpm and other values. Stored and pending fault codes were zero within the range that answered. Permanent fault codes, on the other hand, were not obtained. Standard OBD results alone cannot tell you whether the whole vehicle — including start authorisation, lighting and so on — is healthy.
The adapter read 11.9 V with the key off and 11.6 V with the key on. These are values at the OBD connector. We did not measure at the battery terminals, nor during cranking. They are material for checking the power supply next, but not enough on their own to judge the battery's life or whether it needs replacing.
The reported symptoms changed too. This time, turning the key on did not make the fan run fast, and when cranking was attempted the starter was reported to turn briefly. The earlier report of "no response at all" is kept as history from that time. Nor have we concluded, from this engine-off observation, that the fan problem after a cold start has gone away.
At this point work on the car was paused, and we decided to continue after the power supply had been put in order. We also prepared software for manufacturer-specific diagnostics, but tests against simulated responses are kept separate from captures on the real car. Passing those tests is not evidence that we could communicate with each control unit in this vehicle.
AI makes it easier to organise documentation, implement communication handling and compare logs. What supports the judgements is the conditions confirmed at the car and the unprocessed responses.
Next time we look at how the first log was read: what it told us, and what it still does not.
