Capacitive Keypad Testing: A Production-Intent Checklist

Capacitive keypad testing should verify that every fixed key produces its specified input events, host actions, feedback, and recovery behavior on the production-intent assembly. Check deliberate touches and no-touch periods: detecting a finger is not the same as accepting a command.

This checklist addresses discrete touch keys, not PCAP coordinate accuracy, edge tracking, or touchscreen multi-point acceptance. Set acceptance limits from the project requirements before testing.

Identify the Production-Intent Assembly

Approve an identifiable configuration, not an unlabeled bench sample. “Production-intent” means the sample represents the planned construction and installed electronics; list every remaining prototype substitution.

The TI CapTIvate design guide explains how the cover, ink, adhesive, and air gaps influence sensing. Microchip’s driven-shield guidance also describes sensor loading from nearby ground-referenced conductors. Record these physical conditions rather than treating a different enclosure or shield arrangement as equivalent.

Assign separate owners for the cover and bonding, sensor and tail, controller hardware, touch firmware, display/lighting, and host software. Record test-instrument and debugger connections so the validation setup remains reproducible.

For procurement, use JASPER’s custom capacitive touch panels as the product-family starting point and define the included assembly and test responsibilities in the quotation. The custom capacitive touch panel design guide covers the wider design package; the evidence below focuses on fixed-key behavior.

Verify Every Key and Neighboring-Key Rule

Give every key an event contract before testing it. Map the visible legend to its electrode/channel, reported key ID, host function, permitted modes, and feedback.

Use DOWN and UP below as illustrative labels for transitions into and out of reported touch, not prescribed protocol fields. For a per-press command delivered through a level or bitmask interface, derive transitions rather than counting every status report as another press. Define whether activation occurs on touch, release, or a completed hold.

Exercise every target at its center and required boundary positions. Include touches between neighboring targets, sequential presses in both directions, and repeated operation with the specified release gaps. Define whether ambiguous contact selects one key, rejects both, or invokes another documented rule.

For permitted combinations, test both touch orders, overlapping holds, and both release orders. For forbidden combinations, verify the required rejection or priority behavior. TI’s dominant-button reporting selects the largest delta response for applications not requiring multi-touch; individual element status is separate information. Confirm that the chosen interface exposes the information your combination rules need.

Do not diagnose every missed tap as low sensitivity. TI’s debounce documentation distinguishes touch-entry and touch-exit filtering and explains the additional response delay. Test timing around the project’s tap, release, and repeat boundaries without changing tuning during the acceptance run.

Test Touch and No-Touch Conditions

Require evidence for intended inputs and unintended activation separately. An unattended interval is a test case, not the pause between button presses.

Before execution, define sample quantities, per-key attempts, contact durations, release gaps, observation periods, input objects, environmental setpoints, stabilization conditions, and acceptance limits. Record actual attempts and elapsed observation time alongside missed, extra, wrong-key, and stuck-state events. Do not turn “none observed” into an unlimited reliability claim.

Start with the agreed dry reference condition. Then exercise the specified gloves, wet states, cleaning conditions, and recovery transitions. Each condition needs an expected response: accept, reject, inhibit, or indicate a fault. Use the water and glove validation guide to define those conditions without replacing this fixed-key event checklist with a coordinate-screen test.

Repeat touch and no-touch cases across required display, backlight, supply, charging, and equipment-load modes. TI identifies digital and LED-drive signals as potential coupling sources near touch traces. Record both steady operation and switching transitions. Include accessible non-key areas, the bezel, and handling surfaces where unintended input must be rejected.

For investigation, preserve the failed configuration before changing one variable. Retain available raw counts, baseline, processed touch state, interface traffic, and host logs; identify unavailable measurements explicitly.

Check Host States, Feedback and Recovery

Validate the complete command path in ready, disabled, locked, busy, sleep, and fault states that the product actually implements. A correct key ID is insufficient when the host performs the wrong action.

Separate physical-contact-to-input latency, input-to-host-action latency, and host-action-to-feedback latency. Define timestamp references, measurement resolution, and limits before comparing results. For light, sound, or haptics, check the correct output, timing, and meaning for accepted and rejected commands. Do not let a detection indicator masquerade as confirmation of completed equipment action.

Test long holds below, at, and beyond each application boundary, then verify release and a fresh touch. Keep the application’s long-press or repeat logic separate from the controller’s sensor timeout. TI’s sensor-timeout documentation describes a reset after an extended detected state and notes that sample rate affects the elapsed timeout. An intended long hold must not be silently reinterpreted as a fresh press after that reset.

Test startup with clear keys and with a key already covered. TI’s negative-touch explanation describes how touching during startup calibration can affect the reference and subsequent removal response in that implementation. Verify the actual controller’s behavior rather than assuming it follows TI’s recovery method.

Where applicable, reset the controller and host separately while a key is held. Under an approved electrical procedure, test specified supply interruptions and communication failures. Record startup status, input inhibition, timeout handling, held-key cleanup, and the first accepted command after recovery. Define whether release and a new touch are required before operation resumes.

Record Acceptance, Deviations and Release Ownership

Release only against agreed requirements and retained evidence. Use the following capacitive keypad acceptance checklist as an illustrative template, not a completed test report or universal pass specification.

Replace each “specified” rule with an approved requirement reference. Expand “each key” into the actual key IDs and repeat relevant rows for each configuration and condition. Assign named people to the owner roles. The actual-result cells are intentionally blank; enter measurements, pass/fail/not-run status, and evidence references during execution.

Fixed-Key Acceptance Matrix

A keypad with level-only outputs may not expose explicit fault or reset messages. Specify the host’s detection and recovery mechanism instead of assuming unsupported diagnostics.

Deviation and Closure Record

Deviation ID / requirement reference / matrix row:
Sample ID / complete hardware, firmware, and installation revisions:
Starting state / stimulus / conditions / reproduction frequency:
Expected event and host response / observed difference:
Evidence files / timestamps / affected samples or configurations:
Containment / investigation owner / target closure date:
Suspected cause / confirmed cause and supporting evidence:
Corrective change / new controlled revision:
Retest of original failure / adjacent, no-touch, hold and recovery regression:
Disposition / residual limitations / supplier and OEM approvals / date:

Keep failed, not-run, and formally waived cases distinct; a waiver is not a passing result. After correction, retain the original failure evidence and link it to the retest configuration.

Freeze the approved drawings, firmware/configuration, host mapping, test procedure, evidence, and deviations. Name the supplier’s scope approver and the OEM’s system-release owner. Define routine production checks separately from engineering validation; this checklist does not establish environmental qualification, lifetime, EMC compliance, or a safety function. Do not use ordinary keypad acceptance as a substitute for safety-control validation.

Frequently Asked Questions

Plan Your Keypad Sample Validation

Start with a numbered key layout and an explicit event/state map. Provide controlled drawing links, cover/sensor and enclosure details, controller and firmware configuration, supply and host-interface information, required operating conditions, sample quantity, expected production volume, and acceptance responsibilities. Include existing event logs or the completed portions of the matrix so the request identifies what must be validated, not simply how the panel should look.

Plan My Keypad Sample Validation.