Sample diagnostic report

The shape of the written report a diagnostic week produces: one finding worked all the way through with its evidence, the root cause, an options table with costs and time, and a fixed price for the fix. An illustrative example, not a client job.

This is an illustrative example, not a client job. The product, the company and every number in it are invented, so that the shape of the report can be shown without redacting the parts that matter. Real reports are confidential and are never published in any form, redacted or otherwise (terms). What is real here is the structure, the level of evidence, and the fact that the options table carries prices you can act on with or without me.

A diagnostic week produces one document, usually 8–15 pages. This is a shortened version of one: the summary, one finding worked all the way through, the root cause, the options and the price. A real report carries every finding at this depth, plus the appendices.


Report D-0000 · Intermittent field resets, SNS-3 sensor node

Prepared for (client)
Product SNS-3 four-channel sensor node, 24 V AC/DC powered, RS-485 / Modbus RTU
Population ~4,100 installed across 60-odd commercial sites
Material received 3 returned units, 1 known-good unit, schematics rev C, layout, firmware source at tag v2.8.1, 14 months of RMA records
Bench days 4, across 10 business days
Prepared by Pratheepan Emil Patrick · Registered Professional Engineer, Victoria (electrical engineering), reg. no. PE0011615

1. The ten-second version

The nodes are not faulty. On sites where a contactor shares the 24 V supply, its inrush pulls the rail down to about 16 V for 40 ms. That is below the minimum input of the isolated supply feeding the RS-485 transceiver, but nowhere near the processor’s brown-out level — so the communications side loses power, the processor stays up, the bus transaction fails, and the node’s own watchdog reboots it. Every returned unit tests good because no bench has a contactor on it.

The cheapest fix is firmware only and can go out over the air: hold the transceiver in a known state through the sag and retry, instead of letting the watchdog fire. AUD 9,500, about three weeks. The hardware change is worth doing at the next scheduled revision, not now.

2. What I was asked

“Units come back from the field with no fault found. It’s about 2% a year, it’s getting worse, and we can’t tell the customer why.”

Specifically: whether the returns share a cause, whether it is a design fault or an installation one, and what it would cost to stop it.

3. What I did

4. Finding 1 — the rail goes under the isolated supply, not under the processor

The 24 V bus rail during a nearby contactor's inrush The rail sits at 32 volts, drops to about 16 volts when a contactor on the same supply pulls in, and recovers over roughly 40 milliseconds. For 37 milliseconds it is below 21.6 volts, the minimum input of the isolated supply feeding the RS-485 transceiver, but it never comes close to 9 volts, where the processor's buck regulator would drop out. The communications side loses power while the processor keeps running. 21.6 V · isolated RS-485 supply minimum 9.0 V · processor buck dropout, never reached 32 V nominal 37 ms 0 20 40 60 80 100 120 milliseconds from the contactor pulling in

Swipe the diagram sideways to see all of it.

For 37 ms the rail is below the minimum input of the isolated supply that feeds the RS-485 transceiver, and nowhere near the level that would reset the processor. The communications side goes dark while the processor keeps running, so the node never records a power-related reset — it records a watchdog. None of this happens on a bench without the contactor, which is why every returned unit tested good.

Evidence. Rail captured at the node’s terminals, 20 captures across three contactor types. Worst case 15.6 V, best case 22.4 V; the two sites with the highest return rates both use the larger contactor. The processor’s reset-cause register reads WDT on every event and never BOR — which is exactly what this mechanism predicts, and is also why the firmware team reasonably concluded it was a software hang.

Why it never showed up. The design verification plan tests the rail from 18 V to 30 V steady state and includes a 10 ms interruption test. Both pass. Neither covers a 40 ms sag to 16 V, and the isolated supply’s 21.6 V minimum sits inside the tested range — so nothing in the plan was wrong. It was incomplete in a way only a site can show.

Repeatability. 20 of 20 captures reproduce the sag. 17 of 20 produced a node reset; the three that did not fell inside an idle window in the master’s poll cycle, which fits the mechanism rather than contradicting it.

(Findings 2 and 3 — a return-path routing choice that raises surge exposure, and two Modbus registers that do not match the published map — are carried at this same depth in the full report.)

5. Root cause

The isolated supply feeding the RS-485 transceiver has a narrower input range than the rest of the board. Nothing in the specification, the verification plan or the installation guide says the 24 V supply must not be shared with inductive loads, and in the field it is shared. The node then reports a supply event as a firmware fault, because a failed bus transaction is the only evidence it can see.

This is a design margin problem, not a manufacturing or installation one. The units are correctly built and the installers followed the guide.

6. Your options

What it does Cost Time What it does not do
A. Firmware only Detect the sag, hold the transceiver off and retry the transaction instead of letting the watchdog fire. Log the event so the fleet reports it. AUD 9,500 ~3 weeks Does not widen the hardware margin — a sag longer than tested would still reset
B. A, plus a capacitor at the terminals Adds bulk capacitance during a service visit, so the margin covers the worst site measured AUD 9,500 + ~AUD 14 a unit + labour 3 weeks, then your service cycle Means touching 4,100 units; only earns its cost if you are visiting anyway
C. Power stage revision Wide-input isolated supply at the next board revision, margin restored properly AUD 22,000–31,000 10–14 weeks incl. re-verification Nothing for the units already in the field
D. Document it Installation guide forbids sharing the supply with inductive loads ~nil days Puts a fault the design owns onto the installer. Not recommended

7. What I would do

A now; C at the next revision you are doing anyway. A removes the symptom across the whole installed fleet without touching a single unit, and the logging it adds tells you within a month whether any site still has events. B only earns its cost if a service visit is already scheduled. D would work commercially and I would not do it — the margin is the design’s to carry, and it will come back at the next contactor.

Update the verification plan either way. A sag profile taken from a real site belongs in it, and it is the cheapest item on this page.

8. Fixed price for the fix

Option A: AUD 9,500, fixed, half on start and half on acceptance. Six weeks of support after release for anything traceable to the change. Acceptance is the reproduction rig from §3 running the event 200 times with no reset and every event logged — the same test that found it, which your team can run themselves afterwards.

The AUD 6,000 for this week comes off that, as it does for any follow-on work over AUD 20,000 starting within 90 days.

9. What I did not test

Appendices (in the full report)

A. All 20 rail captures, with contactor type and cable length. B. Reset-cause register log, four units, seven days. C. RMA records mapped to site, install date and contactor type. D. The reproduction rig: parts, settings and procedure, so your team can run it. E. Firmware change list for Option A, down to the files and functions.


The structure is the point of this page, not the product. If you are weighing a diagnostic week, this is what lands in your inbox at the end of it — and the 45-minute call the week after is to walk through it with you.