Fault code analysis – putting multiple entries in the right order

The fault memory rarely holds a single code – it holds a list: four, seven, sometimes more than a dozen entries from several control units. Some of them are current, some come from an earlier situation, and at least one describes a consequence rather than a cause. Anyone who works through that list from top to bottom replaces parts in the order the scan tool happened to sort them – not in the order in which they are technically connected.

This is exactly where the MotorScope fault code analysis starts: your entries are not translated one by one, they are related to each other – status, freeze frame data, the control units involved and the described course of the symptoms all belong together. As a rule, within one hour of receiving complete data you get an analysis report with a comprehensible classification and a prioritisation of possible checks – around the clock, at night and at weekends too, independent of repair work and parts sales, with no ties to any workshop.

Have your diagnostic data reviewed →

Part of the MotorScope remote vehicle diagnostics.

When a fault code analysis is worthwhile

A single, unambiguous entry with a matching symptom rarely needs a second opinion. The analysis becomes useful when the list itself becomes the question:

• Several entries are stored at the same time, and the order in the printout says nothing about their ranking.

• Entries appear in several control units at once – for example in the engine, transmission and comfort control units.

• A part has already been replaced on the basis of a code, and the entry has come back since.

• The code that was read out does not match what you notice on the vehicle.

• You receive two different explanations for the same list and are expected to decide.

• The printout contains entries that nobody classifies because they "do not belong to the symptom".

• You do not know which of the entries come from an earlier workshop visit.

• Before approving a repair you want to know which entry justifies the job.

Safety first. If the engine warning light is flashing, if there is a severe loss of power, smoke, a smell of fuel, unusual noises or anything unusual about the brakes or steering, do not continue driving the vehicle. Have it checked on site first – a data analysis is no substitute for an inspection of the vehicle itself.

Several entries: which one is the trigger

A list with several entries is not a contradiction, and it is not a sign that several parts are defective at once. Such a list comes about in different ways, and those ways leave different traces in the data. How an individual code is structured and what its positions mean is the subject of the OBD diagnostics page – here it is about how the entries relate to each other.

One entry triggers follow-up entries in other control units

A control unit detects a deviation and reacts to it: it limits an actuating value, switches a function off or stops supplying a value. Control units that depend on that value or that function assess this as a deviation in turn and store entries of their own. The result is a chain in which only the first link describes the actual occasion.

How to recognise this in the data: the follow-up entries concern systems that depend on the value that dropped out, and their freeze frame data resemble one another – same engine speed, same coolant temperature, same load range. The triggering entry is often stored as static, the follow-up entries as sporadic. If several entries disappear together after a single measure, that also points to a chain.

A common cause produces several entries that act independently

Undervoltage, disturbed communication on the data bus or increased contact resistance at an earth connection do not affect one system but every system attached to it. Each control unit concerned notices something of its own and stores an entry that is technically correct but says little in isolation. The entries stand side by side rather than one after another – a connection only emerges through the common starting point.

How to recognise this in the data: the entries are spread across control units that have nothing to do with each other functionally, for example the engine management and a comfort system. The freeze frame data often show a starting procedure, a low on-board voltage or a short period in which everything occurred at once. If the moment coincides with a starting attempt, a weak battery or a drive after a longer standstill, that indicates a common cause rather than several defects.

Entries from different periods that have nothing to do with each other

A fault memory collects over the life of the vehicle. An entry from a one-off situation three years ago sits in the same printout as yesterday's entry and looks no different. Without a time reference the printout looks like a snapshot, even though it is a record covering several years.

How to recognise this in the data: what counts here is the fault status and – where the control unit keeps them – the counter of driving cycles since the last occurrence as well as a mileage reading or time stamp in the entry. An entry that has not occurred for many driving cycles very probably does not belong to the current symptom. Clearly deviating freeze frame data – a different season, a different outside temperature, a different operating state – also separate old entries from current ones.

Entries left over from an earlier workshop visit that were never cleared

After a repair the memory is not always cleared completely, and entries often remain in secondary control units because they do not even appear when the main system is read out. At the next read-out they show up again, look current and draw attention to a system that was worked on long ago. That is precisely why the question of what was done last belongs to the input data and not to the end of the analysis.

How to recognise this in the data: comparing with invoices and replaced parts is more informative here than any code table. An entry dating from before the last repair that has not occurred since describes a closed case. An entry that arose again after the repair describes something different – and that distinction cannot be made without knowing when the repair took place.

Entries created by the read-out itself or by disconnected plugs

Work on the vehicle leaves traces in the memory. A disconnected plug, a disconnected battery, a control unit without power during a measurement, an actuator test or switching the ignition on and off in connection with the read-out all create entries that correctly document a real interruption – except that this interruption was part of the work and not part of the problem. If that is not mentioned, the list grows by entries that say nothing about the vehicle.

How to recognise this in the data: such entries lie close together in time and coincide with the workshop appointment or the moment of the read-out. They frequently concern connections and communication paths rather than operating values, and their freeze frame data show standstill instead of driving – zero engine speed, no road speed, engine not at operating temperature. A note saying "plug was disconnected" or "battery was off" classifies them in a single sentence.

Which of these five constellations applies determines the order of the next steps. The levels on which a suspicion becomes a documented finding are described on the car fault diagnosis page.

The order matters

A list of codes is unordered; a technical sequence of events is not. As soon as it becomes clear which entry arose first and which came afterwards, the whole assessment shifts: several equally ranked suspects become a chain with a beginning. That is why the question of timing is often more productive than the question of what an individual code means.

What a control unit contributes here varies. Many systems keep a counter for each entry: how often the fault has occurred and how many driving cycles have passed since the last occurrence. Others additionally store a time stamp or a mileage reading. These details are not available on every vehicle and not in every control unit – where they are available, they separate current from closed entries far more clearly than any description of the code. An entry with a high cycle counter since its last occurrence is effectively archived, even if it appears first in the printout.

This is exactly the information a cleared fault memory destroys first. After clearing, the codes themselves are quickly back as soon as the problem occurs again – frequency, cycle counters, freeze frame data and the chronological sequence are not. What remains is a list without a history, in which trigger and follow-up entry look the same. If the memory was cleared before the data were sent, that note is itself an important piece of information: it explains why the data are thin and prevents an empty history from being read as "the fault occurs rarely".

One practical point follows from this: a read-out carried out after the symptom has occurred again is in many cases more informative than an older log from before. The fresh extract contains freeze frame data for a situation you can describe, and a status that matches the current condition. If you have both – the old log and the new extract – send both: the difference between two read-out states shows which entries have come back and which have not. How the behaviour can be narrowed down further while the vehicle is running is described under live data analysis.

How to recognise a weak code evaluation

An evaluation is not judged by how confident it sounds but by how verifiable it is. Five characteristics show that a result rests on a narrow basis:

The code has been copied from a table

A general code list reproduces the standardised wording. Whether the entry is assigned a manufacturer-specific meaning on this vehicle, and what the particular control unit is actually objecting to, is not stated there. An explanation that matches the wording of a freely available table word for word says nothing yet about the specific vehicle.

A part is named without being tested

An entry names a deviation in a signal or in a system. The route from the signal to the part runs through a measurement – supply, wiring, plug connection, signal behaviour under load. If that intermediate step is skipped, a code designation turns into a part number without anything in between being demonstrated.

The remaining entries in the list go unmentioned

If one of eight entries is explained and seven are left without comment, there is no statement about whether those seven are consequences, causes or old stock. A sound evaluation also classifies the entries that are not pursued further – with reasons for setting them aside.

No one asks what has already been replaced or done

Without knowing the work done so far, entries from an earlier workshop visit cannot be separated from current ones, and a recurring entry after a parts replacement cannot be recognised as such. That question is not a formality – it decides which lines of the printout belong to the current case at all.

The result cannot be checked by a measurement

A classification that does not say which measurement would confirm or refute it cannot be verified. You can accept it or reject it, but you cannot check it. A comprehensible result therefore ends with a concrete next test step whose outcome supports or discards the result.

These five points are not a verdict on people. They are a checklist for you: when you receive an explanation, you can work along it and establish at which point a piece of information is still missing. What to do when several attempts have produced no result is described on the workshop cannot find the fault page.

Which data make a fault code analysis reliable

Required

• Vehicle data: VIN (17 characters; the letters I, O and Q do not occur in it), model, engine, year of manufacture and mileage.

• Description of the symptom: when the behaviour occurs – right after starting, under load, on the motorway, with a cold engine or only after a longer drive. Since when, how often, under which conditions.

• Diagnostic data: scan tool export, fault memory printout or app export showing the control unit, fault code and fault status – with several entries, the complete list, not just the entry that looks most plausible.

Helpful if available

• Freeze frame data with engine speed, coolant temperature, engine load or road speed – for every entry if possible, not just the first.

• Counters and time details from the entry: frequency, driving cycles since the last occurrence, mileage reading or time stamp, as far as the control unit keeps them.

• Read-outs from all reachable control units, not only from the engine control unit.

• A second extract taken after the symptom occurred again, in addition to the older log.

• Live data and target/actual comparisons.

• Screenshots from an OBD app and photos of the warning lights.

• Invoices for work already carried out and a list of replaced parts, with dates.

• Any indication that the fault memory was cleared, that the battery was weak or that a plug connection was disconnected recently.

How to make your data usable Send the complete log wherever possible rather than a code typed out by hand. Screenshots only help if all values are legible and not just the top line of the screen is shown. Photos should be sharp and show the entry in full. A special diagnostic scan tool is not a prerequisite – existing printouts, photos or app exports are often enough if there is a meaningful description of the fault.

How the analysis works

1. Describe the problem — State the vehicle model, engine, year of manufacture and mileage – and describe when the symptom occurs.

2. Send the data — Upload fault codes, diagnostic logs, freeze frame data or screenshots using the form.

3. Assess the connections — MotorScope compares the data with the described symptoms and the work carried out so far.

4. Receive the analysis report — As a rule, within one hour of receiving complete data you get your analysis report with a comprehensible classification and a prioritisation of possible checks. The evaluation runs around the clock – at night and at weekends too.

What the analysis report contains

• Systematic evaluation of the fault memory and – where available – of live data and sensor values

• Plausibility check of the values and classification of technical connections

• Comparison with publicly available manufacturer specifications and reference values

• VIN-based check for publicly accessible recall and service campaigns

• Analysis report assessing the anomalies, with recommendations for how to proceed

What the online evaluation does – and what it does not

What the online evaluation does

• Relates fault memory, live data and symptoms to each other

• Shows which measurement is most likely to bring clarity next

• Makes a repair recommendation verifiable before you approve it

• Prepares the workshop visit with a clear question

• Is independent of repair orders and parts sales

What it does not do

• Repairs and parts sales

• Repair approval and assurance of roadworthiness

• A substitute for an inspection of the vehicle in person

• Replacing parts on suspicion, and guarantees of success

• A substitute for the roadworthiness test, emissions test or other legally required inspections

If the data do not give a clear picture, the report says so explicitly. Instead of settling on a cause prematurely, it shows which check is most likely to bring clarity next.

Frequently asked questions about fault code analysis

I have eight entries in the memory. Does that mean eight defects?

As a rule, no. Several entries frequently arise from a chain, from a common cause such as undervoltage or a communication fault, or from different periods. The analysis relates the entries to each other instead of translating them one by one.

Which entry is looked at first?

Not the first one in the printout. What counts are the status, the freeze frame data and – where available – the frequency and the driving cycles since the last occurrence. From these it follows which entry matches the described symptom and which can be set aside.

Should I send only the codes that match the symptom?

Send the complete list. It is often precisely the entries that appear not to belong that reveal the common starting point – for example when they concern control units that have nothing to do with the symptom.

The workshop cleared the fault memory. Is an evaluation still possible?

Yes, with limitations. The codes come back as soon as the problem occurs again; frequency, freeze frame data and the sequence are gone after clearing. A read-out taken after the symptom occurs again is then more informative than the old printout. Please tell us that the memory was cleared – that is information in itself.

How do I know whether an entry is old?

From the status and, if the control unit keeps it, from the counter of driving cycles since the last occurrence or a mileage reading in the entry. Freeze frame data belonging to a completely different operating situation also point to an older event.

Can entries be created by the workshop work itself?

Yes. Disconnected plug connections, a disconnected battery or actuator tests are correctly documented by the control unit as an interruption. Such entries coincide in time with the appointment and usually show standstill rather than driving in the freeze frame data.

What does the code itself mean – the first letter, for instance?

The structure and system behind the codes are described on the OBD diagnostics page. This page deals with how several entries relate to each other.

Does the report name a part at the end?

No. Approval to replace a part is expressly not part of the service. The report says which entry forms the starting point, which entries depend on it and which measurement will confirm or discard that assignment.

All questions and answers

Understand the data first. Then act with purpose.

Upload your diagnostic data and, as a rule, receive an independent classification within one hour – before you order the next part. Around the clock, at night and at weekends too.

Have your diagnostic data reviewed →