Support & Learning / Module 8 branch
Symptoms, Evidence and Diagnosis
Before this lesson: Preserve the exact symptom and stop when structure, battery, liquid or powered hardware may be unsafe.
What you will understand
- Separate the visible symptom from the functional domains that can produce it.
- Use model- and board-bounded repair experience without turning one case into a universal claim.
- Move from the customer's concern to written findings, approval and staged acceptance evidence.
Mavic 3 Classic board-bounded diagnosis
The Mavic 3 Classic uses a single 4/3 Hasselblad camera, not the dual-camera Mavic 3 or triple-camera Mavic 3 Pro cluster. That visible distinction must stay attached to every camera, gimbal and parts decision. Its repair architecture also provides unusually useful board-level boundaries: training material identifies ICM40609D for IMU, UBX-M8030 for GPS, OPT3101 in the downward TOF path, SPD1178D devices and AON7544 power devices in the ESC design. Those names are valuable only when tied to the documented board revision and case-level evidence.
Quick answer
Use exact board domains to narrow the fault without turning one component into a universal answer
Confirm the single-camera Classic, board revision, controller, battery, event history and exact warning. Separate E2 camera/gimbal control, E1E flight-control and sensing, P1 image transmission, power management, storage, GPS/IMU/TOF, ESC and external structure. Reboot Hub can publish a confirmed chip or component finding, but the customer receives the known and unknown evidence, proposed scope and acceptance plan in writing.
What evidence should be captured before the customer acts?
How does repair-bench experience map the fault domains?
How do you identify the Mavic 3 Classic correctly?
Start with the product label and the nose. The Classic has one 4/3 Hasselblad camera, whereas other Mavic 3 variants use different multi-camera arrangements. Photograph the aircraft, camera-gimbal assembly, controller, battery, identifiers and visible condition before work. Do not describe a camera or gimbal part as Mavic 3 compatible without confirming the exact variant and revision.
Variant evidence prevents scope drift. The customer should see Classic in the intake, quote, parts line and acceptance plan. When a board or chip observation is used, record the physical board revision and case evidence. A component that appears on one training board map should not be promised across every production revision without confirmation.
What do E2, E1E and P1 mean in diagnosis?
The reviewed Classic board architecture assigns E2 to gimbal control, camera functions and Wi-Fi; E1E to flight control including vision avoidance, height, TOF, GPS, ADS-B, fill light and fan; and P1 to image transmission. PMIC manages module power, DDR supports runtime and data cache, and EMMC stores module firmware. These are functional boundaries, not a shortcut to replacing the whole core board.
A useful diagnosis asks which domain is actually failing. A healthy live image with unstable flight evidence points differently from a stable aircraft with no image transmission, and both differ from no power. The written finding should state the reproduced symptom, supporting observations and remaining cross-domain uncertainty before a board-level proposal.
When can ICM40609D, UBX-M8030 and OPT3101 be named publicly?
The Classic repair documentation identifies ICM40609D in the IMU path, UBX-M8030 in the GPS path and OPT3101 in the downward TOF path for the documented board design. Those exact names can help an experienced reader understand the architecture. They become a repair conclusion only when the same model and board revision are confirmed and measurements or substitutions establish the case-level evidence.
An IMU warning does not prove ICM40609D itself failed. A GPS delay does not prove UBX-M8030 is defective. A height or TOF warning does not prove OPT3101 is the cause. Connections, supply, surrounding components, contamination, alignment, environment and processing can produce overlapping symptoms. Reboot Hub publishes the confirmed boundary and separately marks hypotheses.
How should charging and no-power concerns be divided?
Record battery identity, latch, terminals, charger, cable, source, LED and app behaviour, USB response and abnormal heat. The architecture includes PD/PPS charging control, a USB switch, PMIC-managed power domains, DDR and EMMC. A port that is mechanically damaged, a battery communication concern, no charge and no aircraft startup are different branches even if the customer noticed them together.
Stop on swelling, liquid evidence, burnt odor, deformation or abnormal heat. Bench findings should state whether the evidence is battery-side, input or connector-side, charging-control, regulated-power or downstream-domain. Publishing the board architecture is useful; publishing a universal chip replacement from one no-power symptom would not be.
What does an IMU, GPS or TOF warning require?
Preserve the exact warning, logs, impact history, environment, lighting, surface and whether the concern repeats under suitable conditions. The Classic links IMU, GPS, forward sensing, downward TOF and other flight-control functions through E1E, but each sensor path and connection still needs its own evidence. Inspect exterior windows and structure without probing openings or forcing calibration as a cure-all.
A completed supported calibration can be one test result, not proof that every sensor and the core board are healthy. The report should distinguish environmental limitation, contamination, alignment, connector, module, supply and processing hypotheses. Acceptance must reproduce the customer's positioning and sensing requirement under documented conditions.
How should SPD1178D and AON7544 ESC evidence be used?
The documented Classic ESC board map identifies two SPD1178D devices and twenty-four AON7544 power devices in that revision. That architecture explains why propulsion evidence spans control, power stages, motors, harnesses and structure. Record the affected corner, warning, propeller, motor feel, arm geometry, impact path, abnormal heat and whether the concern follows a particular channel.
Do not infer that one AON7544 or SPD1178D failed because a motor stopped. Case-level measurements and the exact board revision must support that conclusion. The customer-facing report can name the confirmed device when appropriate, while also describing adjacent risk and the post-repair propulsion tests. Public content should never become an unsafe component-replacement procedure.
How are the single camera, gimbal and image link separated?
Preserve an original file and record live image, focus, artifacts, recording, gimbal initialization, axis movement, horizon and P1 transmission behaviour. A black image, poor focus, unstable gimbal, corrupted recording and link breakup cross different camera, control, storage and transmission layers. The single-camera Classic must not inherit a Pro triple-camera test or replacement assumption.
The written finding states whether evidence supports camera output, gimbal mechanics or feedback, connection, E2 control, storage, P1 transmission or controller context. If the fault cannot be reproduced, that limitation remains visible. Acceptance covers image, recording, stabilization and link as separate outcomes.
What changes after impact or liquid exposure?
Impact can load the camera-gimbal assembly, arms, motors, sensors, GPS/IMU paths, TOF and internal connections in one event. Liquid can reach battery terminals, USB, connectors and board areas beyond the visible entry. Preserve photos, logs and event sequence, then stop repeated power cycles when moisture, deformation, burnt odor or abnormal heat is present.
The repair plan separates confirmed damage, credible adjacent risk and inaccessible areas. A bounded repair may be appropriate where structure and evidence are strong. Multi-domain damage, corrosion, major structure or uncertain camera and core-board exposure may favor a wider assembly or documented replacement decision. The customer sees the tradeoff before approval.
How does Reboot Hub turn board evidence into a buying or repair decision?
We begin from the customer's concern and remove each reasonable doubt: exact variant, board revision, symptom, event history, known and unknown items, proposed work, parts provenance, timing, tests and written terms. A chip name is not used as a badge of expertise; it is included only when it improves the exact-unit decision and the evidence is bounded.
If repair is stronger, the quote explains why the scope and acceptance plan support it. If replacement is stronger, the comparison identifies a documented exact unit and kit rather than an anonymous platform listing. This keeps the technical learning connected to a transparent Reboot Hub action path.
What should a Mavic 3 Classic acceptance gate prove?
Match aircraft, controller, batteries and accessories to intake. Address the original concern, then verify single-camera image and recording, gimbal initialization and stabilization, E2 camera functions, P1 link, controls, E1E flight-control functions, IMU/GPS/compass, vision and TOF, charging, propulsion and a staged controlled flight. Add adjacent tests where access or impact could affect them.
The handover lists written findings, known and unknown items, parts provenance, tests and remaining observations. It separates 1-3 business days after quote approval from transit and the 30-day repair warranty from the separate 180-day product warranty. The customer receives evidence for the actual Classic, not a generic Mavic conclusion.
How does Reboot Hub remove the customer's concerns before approval?
Reboot Hub starts with the customer's concern, the exact aircraft and every reasonable question that can affect the decision. We preserve the reported symptom, event history, supplied kit and visible condition; separate confirmed findings from repair-bench hypotheses; name the known and unknown items; and return written findings before asking for approval. Where a board revision and measured repair evidence identify a particular chip or component, that case-level experience can be stated directly. It is not silently expanded into a claim that every aircraft with a similar warning has the same fault.
Repair work normally takes 1-3 business days after quote approval. That workshop period is separate from inbound transit, parts availability, customs handling where relevant and return transit. A diagnostic fee applies to the inspection and written findings. When an eligible repair is approved, that diagnostic fee is credited toward labor or eligible service charges under the written quote. If the customer declines, the diagnosis still explains what was found and what remains unknown.
Eligible completed repair work has a 30-day repair warranty under the written terms. That is separate from the 180-day product warranty for qualifying complete pre-owned products. Neither term is a promise about unrelated later impact, liquid exposure, consumable wear, misuse or work outside the approved scope. The repair record should identify the exact work and acceptance evidence to which the repair term applies.
This is the commercial difference between a generic marketplace instruction and a Reboot Hub path. The customer sees the exact-unit evidence, the concern-by-concern response, the proposed scope, the parts path, the testing and the written terms before commitment. If replacement is stronger, the comparison uses a documented unit and kit rather than an anonymous headline listing. The purpose is not merely to share repair information; it is to turn technical uncertainty into a transparent decision the customer can trust.
Keep exploring
Further reading
From The Reboot Hub Chronicle
From Drone Guides
