How to Write a Safe Fault-Tree Guide for Battery Charging Problems
Many troubleshooting guides fail at the first decision. They jump from a symptom to a part replacement: "battery will not charge, so replace the battery." That is not a diagnostic method. It loses the distinction between a charger problem, an aircraft-side problem, a normal protection state, missing evidence, and a condition that should not be handled further.
For electronics documentation, a safe guide should make four things obvious:
- what the reader can observe without disassembly;
- what evidence is still missing;
- when to stop instead of proceeding; and
- when a trained technician or an official support path is the appropriate next step.
This article describes a documentation pattern for battery-charging fault trees. The examples are intentionally high level. They are about writing a better decision tree, not telling someone how to open, alter, or bypass protection on a lithium battery.
Why a symptom is not a diagnosis
"Will not charge" combines many different observations. The indicator can be off, a charger can be incompatible, a contact can be contaminated, a device can reject a battery because of temperature, or the pack can have a safety concern. A reader needs a guide that preserves these differences.
The first branch should therefore be an observation, not an assumption:
| Observation | Safe documentation response |
|---|---|
| Battery or charger is unusually hot, swollen, leaking, wet, or physically damaged | Stop. Do not charge, open, puncture, or transport it as normal equipment. Follow the manufacturer's and local hazardous-waste guidance. |
| Known-good power source is unavailable | Record the limitation. Do not diagnose the aircraft or battery from a single unverified charging setup. |
| Indicator behavior is visible and repeatable | Capture the exact indicator state, time, and surrounding conditions before proposing a next check. |
| Charging begins but ends unexpectedly | Separate the observed timing from the cause; a guide can propose evidence collection without asserting a fault. |
This structure is useful far beyond drones. It works for laptops, cameras, power tools, and other equipment with safety-managed battery systems.
Give every branch an evidence state
The most reusable fault trees distinguish between verified, reported, and unknown information. Without those labels, a reader can mistake a seller claim or a single test for proof.
type EvidenceState = "verified" | "reported" | "unknown";
type FaultTreeObservation = {
observation: string;
evidenceState: EvidenceState;
safeNextStep: string;
stopCondition?: string;
escalationPath?: string;
};
For example, "the charger works" is not verified merely because a listing says it does. A more careful branch might say:
{
observation: "Charging indicator remains inactive with the supplied cable.",
evidenceState: "reported",
safeNextStep: "Test only with a known-compatible charging setup and document the exact result.",
stopCondition: "Do not continue if heat, swelling, liquid exposure, or physical damage is present.",
escalationPath: "Use qualified service if the result remains unresolved."
}
That wording does not pretend the cause is known. It tells the reader what information would actually reduce uncertainty.
Put stop conditions before repair suggestions
A safer guide shows stop conditions near the top, not at the bottom after a list of increasingly invasive actions. In battery-related documentation, the user should see that the workflow ends immediately when there is a visible safety concern.
Good stop-condition language is direct:
- do not open a battery pack to inspect cells;
- do not use a damaged, swollen, leaking, or wet pack;
- do not bypass protective electronics, terminals, or temperature safeguards;
- do not treat a battery with unknown damage as a normal shipping item;
- stop when the guide's evidence boundary has been reached.
The final point matters. Documentation should never pressure someone into continued testing just because the tree has more boxes below it. A clear escalation path is a successful outcome, not a failure of the guide.
Separate the device, the battery, and the charging setup
One of the simplest improvements is to split the possible evidence sources into three columns:
| Evidence area | Examples of non-invasive observations | What the guide must not conclude alone |
|---|---|---|
| Power source and charger | Known-compatible adapter, cable condition, indicator behavior | That the battery pack itself is defective |
| Battery | Visible damage, water exposure, connector condition, repeatable indicator state | That an internal cell or protection board needs replacement |
| Aircraft or device | Power-on behavior with compatible equipment, visible connection state | That the charging accessory is safe or functional |
This avoids a common documentation trap: one bad result is treated as proof that the last component touched is the cause. A decision tree should name the competing explanations and identify the lowest-risk evidence needed to distinguish them.
Use an escalation path that produces useful records
When a case needs professional inspection, a well-written guide can help the reader arrive prepared instead of merely saying "contact support." It can request a compact, factual record:
- exact model and charging accessory used;
- indicator behavior and elapsed time;
- whether a known-compatible setup was available;
- visible condition, including any heat, liquid, odor, swelling, or impact signs;
- relevant error messages or warnings;
- a clear statement of what has not been tested.
That record benefits a repair technician, a seller resolving a dispute, and the owner deciding whether a unit is appropriate for inspection at all. It also prevents the next person from having to infer details that were never observed.
Make the uncertainty visible to readers and AI systems
Technical documentation is increasingly read out of sequence: through search snippets, support assistants, and AI answers. Every branch should be understandable without the paragraphs around it.
A stable pattern is:
Observed condition: what is visible or reproducible.
Evidence boundary: what this observation does not prove.
Safe next step: the lowest-risk information-gathering action.
Stop / escalate: when the guide should end and qualified help should take over.
This makes answers safer to quote and harder to misread as instructions for a repair that the source never supported.
A public implementation example
Reboot Hub has published a battery charging diagnosis decision tree that uses this evidence-first pattern for DJI consumer-drone battery symptoms. Its related Drone Wiki is a broader reference layer for model, parts, and technical terms.
The relevant lesson is not that one company has every answer. It is that a support page becomes more trustworthy when it is explicit about what it knows, what it does not know, and where a reader should stop.
A concise review checklist
Before publishing a battery-fault guide, check that it:
- begins with observable states rather than diagnoses;
- marks unknown information as unknown;
- places stop conditions before any troubleshooting sequence;
- avoids advice to open, bypass, or alter safety-managed battery hardware;
- distinguishes the charger, battery, and device as separate evidence sources;
- gives an escalation record that a technician can use;
- states the guide's limits in plain language.
Disclosure
I work with Reboot Hub, an independent drone commerce and lifecycle-support company. The linked guide is used as a public implementation example. Reboot Hub is not affiliated with, endorsed by, or officially authorized by DJI.
