EC-13.6 Fault Diagnosis, Evidence and the Report

What this is and why it exists

Diagnosis is a method rather than a talent. The method is the same whether the fault is in a circuit, a program or a process.

This topic states it explicitly, and then attaches the evidence and reporting habits to it. That pairing is deliberate: a diagnosis nobody recorded is a diagnosis that will be made again next week by the same person.

It is the last stage of the sequence because it uses every instrument and every technique from the four before it.

The vocabulary

• Bisection — testing at the midpoint of a chain to halve the possibilities.
• Symptom — what you observed.
• Cause — the thing that, if fixed, stops the symptom recurring.
• Fault log — a running record of faults, how they were found and what fixed them.
• Limitation — a condition your result does not cover.

The mental model

Halve the problem instead of staring at it.

Find a point midway through the chain and establish whether the signal there is correct. That one test removes half the possibilities. Repeat, and a fault anywhere in a chain of a thousand steps is found in about ten measurements.

Staring at a schematic, by contrast, finds a fault when you happen to notice it. That is a process with no bound on how long it takes. The habit is to keep asking where the midpoint is rather than what is most likely broken.

Change one thing at a time, and put back what did not help.

Two changes at once make the result uninterpretable. If the fault goes away you do not know which change did it, and you have to undo one to find out. A change left in place after it failed to help becomes an undocumented feature of the setup. The next person to be confused by it will be you.

The fault log is the cheapest thing in this topic and the most underrated. Three lines per fault: what was wrong, how it was found, what fixed it.

A page of these accumulated over a course is the most reusable thing a laboratory produces, because the same faults recur. Most students discover the same six faults independently, six times each.

Evidence has one test: could a reader tell a correct result from a plausible one?

Captures with their settings visible, tables with units and uncertainties, photographs of the actual setup rather than of a similar one. A reader who has to take your word for it cannot check anything. Your result then carries only as much weight as their opinion of you.

The report answers the question you started with. Purpose, setup, method, results with uncertainty, and a conclusion that addresses the objective.

A report that describes what was done without answering the question has missed its own point. It is also the most common shape of a student laboratory report. The test is to read the objective and then the conclusion and see whether the second answers the first.

Finally, the part most often left out. Say what was not established.

The conditions you did not test. The range you did not cover. The assumption you had to make because you had no way to check it. Stating these strengthens a report rather than weakening it, and it is what separates an engineering result from an assertion.

An examiner or a colleague who finds a limitation you did not state will assume you did not know about it. That is worse than the limitation itself.

What you should now be able to explain or do

• Diagnose a fault by bisection and say why it beats inspection.
• Change one variable at a time and restore the state after each failed attempt.
• Keep a fault log and explain what makes it worth the effort.
• Produce evidence a reader could use to check your result independently.
• Write a report whose conclusion answers the objective it started with.
• State the limitations of a result before anyone else finds them.

Check yourself