GPADLAB Testing Standards
The Controller Health Score combines six diagnostic stages — stick drift, button response, trigger range, deadzone, latency, and connection stability — into a single 0-1000 composite. Each stage has a fixed maximum point value; each result maps to healthy, partial, mild, or faulty severity, and grades range from S at 950+ down to F below 400.
What GPADLAB Testing Standards means
The six-stage scoring pipeline
Every constant below is verified against src/lib/scoring/index.ts. The point weights, severity ratios, and grade bands are the shipped values — not aspirational targets. If the scoring library changes, this page updates.
- 01
Six stages, each with its own measurement
Stick drift measures max radial magnitude at rest across both sticks. Buttons measures the fraction of face and shoulder buttons that register. Triggers measures the analog range covered. Deadzone measures the ratio of usable stick surface after accounting for center noise. Latency measures polling-loop input timing. Connection stability measures dropout frequency across the session.
- 02
Fixed per-stage point weights (total 1000)
The maximum points per stage are hardcoded: Stick Drift 250, Buttons 200, Triggers 150, Deadzone 150, Latency 150, Connection 100. Total 1000. Stick drift is the heaviest because it's the most common failure mode and the hardest to work around; connection is lightest because occasional dropouts are a symptom, not the root problem.
- 03
Severity buckets per stage
Each stage result maps to one of four severity buckets before scaling: healthy (100% of max points), partial (67%), mild (33%), or faulty (0%). The bucket boundaries come from stage-specific thresholds — for drift under 0.05 is healthy, under 0.10 is partial, under 0.15 is mild, over 0.15 is faulty. Every stage documents its own bucket cutoffs.
- 04
Weighted sum → 0-1000 composite
Points from each stage sum to a total between 0 and 1000. There's no rescaling and no post-processing — the score is exactly what the six stages produce. A controller scoring 850 got 850 out of 1000 possible severity-adjusted stage points.
- 05
Grade band assignment
Grades map from the composite score: S (950+), A+ (900-949), A (850-899), B (750-849), C (600-749), D (400-599), F (under 400). Grade bands are wider at the middle and tighter at the edges — a shift from 950 to 970 is meaningful (S band), while a shift from 700 to 720 is not (both C).
GPADLAB Testing Standards grade bands
The seven-band letter grade scale is designed to be intuitive at a glance. S is tournament-grade; A is competitive; B is casual-fine; C is functional but showing wear; D is problematic; F is faulty. Grade thresholds match GRADE_S=950, A_PLUS=900, A=850, B=750, C=600, D=400 in the scoring library.
| Composite score | Verdict | Meaning |
|---|---|---|
| 950 – 1000 | S — Tournament grade | Zero significant issues across all six stages. This is what a new controller in perfect condition should score. Suitable for competitive play at any level. |
| 900 – 949 | A+ — Excellent | One or two stages showing minor imperfection, none severe. Still competitive-grade. Very common on 6-12 month old controllers with light use. |
| 850 – 899 | A — Good | Small drift or latency issues, or one stage significantly below optimal. Fine for casual competitive play. Consider recalibration. |
| 750 – 849 | B — Functional | Multiple minor issues or one moderate issue. Fully usable for non-competitive play. Serious FPS or fighting-game players should investigate. |
| 600 – 749 | C — Fair | Real problems present. Casual gameplay still works but requires deadzone compensation or workarounds. Repair or replacement worth considering. |
| 400 – 599 | D — Problematic | Multiple major issues or one severe failure. Gameplay affected in most titles. Repair or replacement strongly recommended. |
| < 400 | F — Faulty | Multiple failed stages. Controller not fit for reliable use. Replace or retire. |
Grade thresholds correspond to GRADE_S=950, A_PLUS=900, A=850, B=750, C=600, D=400 in src/lib/scoring/index.ts. The seven-band scale is what the /tools/controller-benchmark result panel displays.
Test for GPADLAB Testing Standards
Fix GPADLAB Testing Standards issues
Related glossary terms
GPADLAB Testing Standards questions
Because stick drift is the most common and least workaroundable failure mode. A drifting stick affects every second of gameplay in the affected game. An occasional connection dropout is annoying but rare, and typically fixable via battery, distance, or wireless mode changes. The weighting reflects real-world impact per user hour, not academic parity between hardware subsystems.
Because linear averaging punishes borderline cases and rewards mediocrity. A controller with all six stages at 60% would score identically to one with five stages at 100% and one at 10%. The four-bucket severity mapping (healthy, partial, mild, faulty) intentionally coarse-grains within stages so the composite score reflects usability tiers rather than raw sensor arithmetic. A controller with five healthy stages and one faulty stage is a broken controller; the composite should reflect that.
Because on any real controller, even a new one, at least one stage will land at the 900-949 band due to natural variance — Gamepad API noise floors, minor deadzone quirks, the ~1ms of polling-loop overhead. A perfect 1000 is theoretically possible but practically unattainable. Setting S at 950 rewards controllers in excellent working order without requiring impossible-to-achieve idealism.
Grade bands are tighter at the top (S is only 50 points wide, A+ 50, A 50) and wider at the bottom (B is 100, C is 150, D is 200). This reflects meaningfulness of difference — the gap between a 970 and a 990 controller is real and worth signaling; the gap between a 500 and a 550 controller is both broken. The band widths correspond to GRADE_S, A_PLUS, A, B, C, D constants in the scoring library.
Everything runs on the Gamepad API (navigator.getGamepads) sampled inside requestAnimationFrame with performance.now() timestamps. No Web Bluetooth, no WebHID, no browser plugins. That means the tests work in any modern browser (Chrome, Firefox, Safari, Edge) with no installation, but they inherit the Gamepad API's own quirks — polling granularity, browser tab throttling, occasional axis noise floor above true zero.
The individual tests give per-stage measurements with their own thresholds and verdicts. The composite Controller Health Score puts them all on one screen with weighted point contributions, so you get a single number and a grade instead of six separate readouts. Both are valid — the individual tools are better for diagnosing a specific issue, the composite is better for a quick overall assessment or before-and-after comparisons.
Yes, and this matters. A test run on a laptop tab in the background (throttled requestAnimationFrame) will show inflated latency. A drift test on a controller held in your lap will show inflated drift. Bluetooth range tests near a busy Wi-Fi router will show inflated dropouts. The methodology assumes best-effort test conditions — foreground tab, controller on a flat surface for drift measurement, standard room for connection stability. A score is only meaningful if the test conditions match what the methodology specifies.
Almost always yes, but with one caveat — the same controller tested twice can vary by 20-40 points due to Gamepad API noise floor variance and minor sample-window differences. A run-to-run score difference under 50 points isn't meaningful. Score differences over 100 points reliably reflect real controller condition changes. When comparing controllers or tracking one controller over time, run the composite two or three times and use the median.
Further reading
- Gamepad API — MDN Web Docs · MDN Web Docs
- Performance.now() — high-resolution timestamps · MDN Web Docs