PASS, UNSURE, and Timeout Explained: How to Read DJI Air 3 Gimbal Calibration Results

Short Answers

Table of Contents

1. Core technical guide
2. Deep technical foundation
3. Evidence hierarchy
4. Failure modes
5. Technician scenarios
6. Technician worksheet
7. Related Air 3 tutorials
8. What is Ares Acres?
9. Ares Software CTA

Deep Technical Foundation: Reading Software Evidence Without Turning Uncertainty Into Success

The most dangerous result-handling mistake is collapsing every non-crash outcome into 'success.' A repair utility may launch correctly, receive output, and exit normally while still lacking a recognized completion result. Ares normalizes those states so the technician can stop at the correct point.

1. PASS is intentionally narrow

PASS means the engine returned the final summary pattern Ares recognizes for the selected operation and no higher-priority error condition replaced it.

It does not automatically mean the customer complaint is resolved.

2. UNSURE is valuable evidence

An inconclusive result is not useless. It tells the technician that the engine reached a state it was willing to report, but not one Ares can call confirmed completion.

Preserving that distinction is better than optimistic guessing.

3. Timeout describes monitoring, not device physics

The adapter timeout occurs when the wrapper stops waiting. The physical device may have stopped, continued, or completed outside the observed window.

That is why an immediate automatic retry would be a poor default.

4. Known exit codes help classify failure layers

Invocation and engine errors are mapped separately from generic process errors. This helps support distinguish a rejected command from an engine operational problem or another execution failure.

The classification is useful even when the physical aircraft is not the cause.

5. Unrecognized output prevents false positives

A process can exit without producing the summary pattern. Ares reports OUTPUT_UNRECOGNIZED instead of treating a clean exit as calibration success.

This is one of the strongest integrity controls in the current wrapper.

6. Result state should change technician behavior

A confirmed first-stage PASS enables the second stage; uncertainty or error blocks it. The UI therefore turns result interpretation into a workflow control rather than merely a status label.

That design reduces accidental progression after ambiguous evidence.

Why this matters for a repair bench

Result integrity lets a repair business train technicians on consistent decision rules. Instead of each person deciding what 'probably worked' means, the shop can standardize around explicit software states and require logs before uncertain retries.

A consistent service process separates observation, application state, engine result, physical behavior, and customer-facing outcome. Those layers can support each other, but none should silently replace another. The purpose of a structured tool is to make those distinctions easier to preserve when the repair becomes complicated.

Evidence Hierarchy

Failure Modes and Diagnostic Branches

When a result is not PASS, first classify whether the issue is evidence, execution, monitoring, engine behavior, or physical outcome.

Technician Scenarios

These are reasoning examples rather than invented customer repair claims.

Scenario 1: Exit code zero, no summary

Situation. The engine process exits cleanly but Ares cannot parse PASS or UNSURE.

Reasoning. The OS-level process result and service result disagree.

Best next action. Treat it as unrecognized output, preserve stdout, and do not progress.

Scenario 2: Joint Coarse UNSURE

Situation. Stage one returns a recognized inconclusive summary.

Reasoning. The workflow has evidence but not the prerequisite required for stage two.

Best next action. Keep Linear Hall blocked and investigate before another attempt.

Scenario 3: Joint Coarse timeout after motion

Situation. The gimbal moved but no accepted final result arrived before the wrapper timeout.

Reasoning. Physical motion is not equivalent to confirmed completion.

Best next action. Preserve the log and determine the actual state rather than repeating automatically.

Scenario 4: Linear Hall PASS but physical tilt remains

Situation. Software completion and physical outcome disagree.

Reasoning. The result is valid for the service stage but insufficient for the repair claim.

Best next action. Continue diagnosis and document the discrepancy.

Scenario 5: Dry-test PASS followed by live engine error

Situation. Simulation proves software path; live mode reports an engine error.

Reasoning. The new failure belongs to the live context, not the previously qualified simulator path.

Best next action. Keep the baseline and troubleshoot live-specific evidence.

Technician Worksheet

• Always record operation name with the result.
• Record whether the session is dry-test or live.
• Record process exit code and normalized Ares result separately.
• Record elapsed time and report count when available.
• Preserve stdout/stderr after non-PASS outcomes.
• Do not unlock or manually bypass stage progression after first-stage uncertainty.
• Do not automatically retry after timeout.
• Verify the original physical symptom after PASS.

Minimum support record

1. DJI Air 3 identification and relevant observed software/firmware context.
2. Original symptom and controlled reproduction steps.
3. Physical inspection findings.
4. DJI Fly result if used.
5. Ares mode: dry-test or live.
6. Setup/engine state.
7. Joint Coarse and Linear Hall results separately where applicable.
8. Process exit code and output when relevant.
9. Exported support log.
10. Final physical outcome and next decision.

Air 3 Gimbal Service Learning Path

This article belongs to a ten-part Air 3 service cluster. Use the internal links below to move between software setup, simulation, result interpretation, USB diagnosis, calibration-stage theory, logs, and final post-repair verification.

Also browse DJI Software, DJI Parts, DJI Accessories, and the full DJI Agriculture Tutorials hub.

Advanced Technician Deep Dive: Building a Result-Integrity Discipline Around PASS, UNSURE, and Timeout

The difference between a repair tool and a button launcher is result integrity.

This article’s central lens is epistemic discipline: what does the software actually know after each outcome, and what must remain unknown until more evidence exists?

A four-layer model for interpreting the workflow

For advanced troubleshooting, treat the Air 3 service process as four interacting but separate layers. The application layer controls the UI and workflow state. The engine layer constructs and executes the service command and returns output, exit code, reports, and summaries. The connection/device layer determines whether live communication is actually established. The physical gimbal layer contains the motors, joints, camera assembly, cabling, mounts, and the customer-visible behavior.

A failure can occur at one layer while the others remain healthy. The application can launch while live communication is unresolved. The engine can report PASS while the physical symptom remains. A physically normal-looking gimbal can coexist with a local software setup problem. Advanced diagnosis becomes faster when the technician asks which layer generated each piece of evidence before deciding what to change.

Result words are generated at the software/engine boundary. They become useful repair evidence only after the technician correlates them with session mode, physical behavior, and the original complaint.

The evidence chain from complaint to closure

A strong repair record should be chronological: complaint, controlled reproduction, physical inspection, official DJI behavior, Ares package/workflow state, engine result, and final post-service comparison. If the chain contains a gap, the conclusion should acknowledge the gap instead of filling it with assumption.

This matters because software-assisted repair can create false confidence when a clean software result is treated as a universal hardware verdict. A useful service record keeps every layer visible.

Advanced Bench Protocol

1. Identify DJI Air 3 precisely. Do not infer Air 3S compatibility.
2. Write the complaint as an observable symptom.
3. Record trigger history. Impact, shipping, disassembly, repair, software change, storage, or unknown onset.
4. Create a controlled test setup.
5. Observe before changing state.
6. Inspect the physical assembly.
7. Record DJI Fly behavior and warnings.
8. Decide whether the case belongs in software yet.
9. Verify the Ares package baseline.
10. Record simulation versus live mode explicitly.
11. Run only the stage whose prerequisites are satisfied.
12. Record normalized result and process evidence.
13. Stop on ambiguity.
14. Export the support log before changing conditions.
15. Repeat the original physical test.
16. Compare evidence layers.
17. Choose the next branch based on new evidence.
18. Write the conclusion narrowly.
19. Preserve the record.
20. Only then close or escalate the case.

For non-PASS outcomes, the most important step is to preserve the current evidence before another action changes the system.

Common Misdiagnoses and Why They Happen

Service-Case Patterns

These are structured reasoning examples, not invented customer success claims.

Pattern 1: Clean recognized PASS

Process outcome is acceptable and the final summary parses as PASS.

Interpretation: The service stage has confirmed engine completion evidence.

Action: Proceed according to workflow, then verify physical outcome.

Pattern 2: Recognized UNSURE

The summary explicitly says UNSURE.

Interpretation: The engine is communicating but completion is not confirmed.

Action: Stop, log, and diagnose.

Pattern 3: Timeout with partial output

Some reports arrive before monitoring ends.

Interpretation: There is partial evidence without a final accepted result.

Action: Preserve output and current state before deciding on retry.

Pattern 4: Exit zero, no summary

The process ends cleanly without accepted result text.

Interpretation: Operating-system success is not service success.

Action: Classify as unrecognized output and inspect stdout.

Pattern 5: PASS plus unresolved symptom

Software state and physical outcome disagree.

Interpretation: The stage completed but repair did not fully resolve the complaint.

Action: Continue diagnosis and document both facts.

Advanced Decision Rules

• Rule 1: PASS should remain narrow and stage-specific.
• Rule 2: UNSURE should never be upgraded by optimism.
• Rule 3: Timeout should be described as loss of monitoring, not proven device stop.
• Rule 4: Exit code and normalized result are separate fields.
• Rule 5: Raw output matters after abnormal results.
• Rule 6: Do not automatically retry ambiguous modifying operations.
• Rule 7: Session mode must accompany every result.
• Rule 8: Physical post-check is required after PASS.

These rules create consistency across technicians. They also make support records easier to compare because the same result vocabulary means the same thing on every ticket.

Advanced Technician FAQ

Can PASS ever coexist with a failed repair?

Yes. The selected service stage can pass while the customer-visible root cause remains.

Can UNSURE coexist with a physically normal gimbal?

Yes. Physical observation and software evidence can disagree; document both.

Why not treat timeout as UNSURE?

A timeout describes a different reason for incomplete evidence: monitoring ended rather than the engine explicitly returning UNSURE.

Can an engine error come from the workstation?

Potentially. The category describes what the engine reported, not a guaranteed hardware diagnosis.

Why preserve exit code if Ares already normalizes the result?

It adds process-level context useful for support and comparison.

Why is output-unrecognized important?

It prevents a clean process exit from becoming a false success.

What is the safest action after timeout?

Preserve evidence, establish device/software state, then decide deliberately.

Can a result change if I rerun?

Yes, which is exactly why the first result should be preserved rather than overwritten in memory.

Should result history be kept after a later PASS?

Yes. Earlier ambiguity can explain intermittent issues and is part of the service record.

What should a customer-facing report say?

Use narrow wording: which stage ran, what it reported, and whether the original symptom was resolved.

Search-Intent and Internal-Link Map

Once the technical intent is satisfied, readers can move naturally to the DJI Software collection or the Ares Air 3 Gimbal Calibration Utility.

Expert Reference Appendix: Result Acceptance, Retry Policy, and Escalation Criteria

A result-handling policy should tell a technician not only what a label means but what to do next. PASS, UNSURE, timeout, engine error, process error, and unrecognized output each represent a different evidence condition. A mature repair workflow changes behavior based on that condition instead of treating every non-PASS as the same kind of failure.

This appendix is written for repair technicians and service departments that need a repeatable reasoning process rather than a one-line fix. The questions, acceptance criteria, and documentation examples below are designed to make the article useful as a bench reference as well as an SEO/tutorial page.

Pre-Service Questions a Technician Should Answer

1. Which operation produced the result?

Always tie PASS/UNSURE/error to Joint Coarse or Linear Hall. A result without an operation name is incomplete.

2. Was the run simulated or live?

Mode changes the meaning of the same result word and must be preserved.

3. Was setup Ready before the run?

A stage result should be interpreted in the context of a valid engine setup.

4. Did the engine produce a recognized summary?

A recognized summary supports PASS or UNSURE; absence of a summary can lead to unrecognized output even if the process exits normally.

5. What was the process exit code?

Exit code adds execution context and helps distinguish invocation, engine, and other process failures.

6. Did the wrapper time out?

Timeout takes priority because it means the application stopped waiting before normal completion evidence was obtained.

7. Was stdout/stderr saved?

Raw output is especially important for engine errors, process errors, and unrecognized output.

8. Did the UI change to the expected state?

The presentation state should match the normalized result. A mismatch may be a software defect.

9. Was an automatic retry avoided?

Ares is intentionally designed without hidden automatic retry. Technician action after ambiguity should be deliberate.

10. What happened physically during the run?

Visible movement, abnormal noise, or loss of connection can add context but should not be mistaken for the engine’s final result.

11. Did the result change the stage gate?

After Joint Coarse, only confirmed PASS should enable Linear Hall.

12. What evidence is needed before another attempt?

At minimum, preserve the current log/output and understand whether the previous operation may still have affected the device.

Acceptance Criteria Matrix

Use the matrix below as a retry/escalation policy rather than a simple status legend.

How to Write Better Service Documentation

Precise work-order language preserves technical state and improves support quality. The examples below show how to replace vague notes with evidence-based records.

Documentation example 1

Weak note: “Failed.”

Better note: “Linear Hall returned UNSURE after valid Joint Coarse PASS. No automatic retry. Second-stage completion unconfirmed; support log attached.”

The improved note names the exact evidence condition.

Documentation example 2

Weak note: “Timed out.”

Better note: “Joint Coarse reached Ares 45-second monitoring timeout. Partial output preserved; device-side completion unknown.”

This avoids implying that timeout proves hardware stopped.

Documentation example 3

Weak note: “Exit 0, so it passed.”

Better note: “Process exit code 0 but no recognized PASS/UNSURE summary; Ares classified OUTPUT_UNRECOGNIZED.”

The correct note respects result normalization.

Documentation example 4

Weak note: “Engine error means bad gimbal.”

Better note: “Engine returned operational error category; hardware cause not identified. stdout/stderr retained for analysis.”

The note avoids an unsupported component diagnosis.

Documentation example 5

Weak note: “Passed, still not fixed.”

Better note: “Linear Hall PASS; original stationary horizon skew unchanged. Service-stage success did not resolve physical complaint.”

This is a valuable, precise discrepancy.

Answer-Engine Reference: Detailed Questions Technicians Actually Ask

Why does timeout override a possible partial summary?

The adapter treats the monitoring timeout as the primary evidence condition because the normal process did not finish within the expected wrapper window.

Why distinguish engine error from process error?

They imply different failure layers and can guide support toward the engine’s own reported condition versus a broader execution problem.

Can a later PASS erase an earlier timeout?

No. The later run is new evidence; the earlier timeout remains part of the history.

Should a shop define a retry limit?

A formal policy can be useful, but the important principle is that retries should follow diagnosis, not happen automatically.

What if the user closes the app during a run?

That should be documented as an interrupted session; do not infer a normal calibration outcome from an interrupted process.

What if the physical gimbal looks normal after UNSURE?

Record the normal observation, but do not relabel the software result as PASS.

What if the physical gimbal looks abnormal after PASS?

The abnormal physical evidence keeps the repair unresolved.

Can result interpretation be automated further?

Potentially, but any automation should preserve rather than hide ambiguity and should be supported by validated evidence.

Why does result language matter for customers?

Precise language avoids promising a repair that the software did not actually prove.

What is the safest universal rule?

Never claim more than the narrowest result supported by the software evidence and physical post-check together.

Authority Cross-Links for the Air 3 Service Cluster

• Gimbal Calibration Explained — calibration theory and limits.
• Tilted or Crooked Diagnostic Guide — symptom-first diagnosis.
• Joint Coarse Guide — first service stage.
• Linear Hall Guide — second service stage.
• Windows x64 Installation — package/workstation setup.
• Dry-Test Walkthrough — software qualification without hardware.
• PASS, UNSURE & Timeout — result interpretation.
• USB and libusb0.dll — connection stack diagnosis.
• Diagnostic Logs — evidence export and support records.
• Post-Repair Checklist — final verification and closure.

After the technical question is answered, the commercial path is intentionally simple: DJI Software collection → Ares Air 3 Gimbal Calibration Utility.

Technician Reference Card: Result-Integrity Decisions

Use this card after any Ares stage returns PASS, UNSURE, timeout, or an error so the next action is based on the exact evidence condition rather than on impatience or guesswork.

Proceed when these conditions are true

• A recognized PASS exists for the selected stage.
• Session mode and operation are known.
• Process evidence is consistent with the normalized result.
• No new mechanical abnormality appeared.
• The workflow prerequisite for the next stage is actually satisfied.

Stop or change diagnostic branch when these conditions appear

• UNSURE, timeout, invocation error, engine error, process error, or unrecognized output occurs.
• Raw output has not yet been preserved.
• The device-side state is unknown after timeout.
• The operator is about to retry only because the result is inconvenient.
• PASS conflicts with an unresolved physical symptom.

Evidence that should exist before the work order advances

1. DJI Air 3 is explicitly identified.
2. The original complaint is written as an observable condition.
3. Repeatability or intermittency is documented.
4. Mechanical obstruction/damage has been considered before repeated calibration.
5. Relevant DJI Fly behavior is recorded.
6. Ares build and mode are known when the software is used.
7. Engine setup state is recorded.
8. Joint Coarse and Linear Hall are documented separately.
9. Non-PASS outcomes preserve their exact category.
10. Timeout is recorded as incomplete monitoring evidence.
11. Process output is retained when it explains the result.
12. The support log is exported before an uncertain state is overwritten.
13. Simulation is never represented as physical-aircraft evidence.
14. The same physical symptom is checked again after service.
15. The final conclusion has a clear disposition.

Go / Hold / Escalate matrix

Five questions before the technician clicks again

1. What exact result category am I responding to?
2. Have I preserved stdout/stderr and the support log?
3. Does the next stage genuinely satisfy its prerequisite?
4. What would an immediate retry risk obscuring?
5. What physical observation will confirm whether a PASS mattered to the repair?

The purpose of this card is to make each additional action intentional. Change one variable at a time, preserve the evidence created by that change, and know what observation would justify the next branch. With service software, a button can be easy to click even when the diagnostic question has not been answered.

Use the internal Air 3 cluster to move to the article that matches the next question. The DJI Software collection is the commercial hub; the tutorial cluster is the technical decision layer that should lead there only after the workflow is understood.

What Is Ares Acres?

Ares Acres is an aerial-robotics and DJI technical-support business focused on simplifying complex drone maintenance, parts sourcing, diagnostics, and software workflows for operators and repair professionals. Its broader ecosystem includes agricultural-drone parts, DJI component catalogs, technical tutorials, diagnostic resources, and the expanding Ares Software product line.

Ares Software is designed around a simple idea: difficult technician workflows can be made more usable without hiding the evidence. The interface should show prerequisites, stage order, results, uncertainty, and support information clearly enough that a repair shop can build a repeatable process around it.

Explore DJI Software, DJI Parts, the full product catalog, or the technical tutorial library.