Membrane Switch Matrix Ghosting: Define Multi-Key Inputs

Name the scan method before counting simultaneous keys

In a passive matrix, a closed key connects its assigned row and column. The controller must interpret those connections. Microchip's AN3407 distinguishes a simple whole-axis scan from reading one driven line at a time; its whole-axis example can confuse two concurrent presses. Therefore, a statement that ghosting starts only with three keys is not a safe specification for every scanner.

Keep two documents aligned: the switch connection map and the receiver's observation rule. A drawing showing four keys in a rectangle does not tell you whether the firmware records individual row samples, only summarizes active rows and columns, or uses a dedicated controller with its own suppression rules. The same contact map can produce different reported events under those methods.

Worked example: identical key maps, different observations

This hypothetical example is HYR editorial synthesis, not a customer circuit or measured specimen. Define A at R1–C1, B at R1–C2, C at R2–C1 and D at R2–C2. Assume ideal passive contacts without isolation diodes. All keys remain stable throughout each scan; resistance, leakage, settling and contact bounce are outside this logical model.

Model S keeps only the set of active rows and the set of active columns, then treats every intersection of those sets as pressed. With only A and D closed, both rows and both columns are present. This rule produces A, B, C and D even though only two contacts are closed. The ambiguity comes from losing the pairing information.

Model R drives one row low at a time, leaves the other row high impedance and reads pulled-up columns. With A and D closed, the separate row samples identify those two positions. But with A, B and C closed, driving R2 low creates a path through C, A and B to C2. The raw sample therefore also indicates D, which was not pressed.

Under Model R, those three closures and all four closures produce the same stable raw result. The comparison table turns that observation into a purchasing decision: the required command must not depend on guessing which physical state occurred. These outputs apply only to the defined ideal models; an actual controller may suppress, filter or otherwise report them differently.

Anti-ghosting can reject a real key instead of recognizing it

Analog Devices' MAX7360 data sheet provides a concrete distinction: its ghost-key handling can withhold the additional key that creates an ambiguous rectangle. That prevents a ghost event but does not promise acceptance of every three-key combination. This is a documented behavior of that component, not a statement that HYR uses it or that its ratings apply to a membrane panel.

Translate terms such as anti-ghosting or multi-key support into an event requirement. For a required chord, state exactly which keys must be reported while held together. For a prohibited overlap, state whether the application ignores the extra input, inhibits a command or waits for release. The equipment owner must choose the response; the supplier should not infer it from marketing terminology.

Debounce addresses changes over time. Taking more samples of the same ambiguous stable observation does not, by itself, recover the missing physical distinction in the example. History-based firmware can enforce a rejection policy, but that is different from proving arbitrary concurrent-key recognition. Validate the policy with both press order and release order.

Convert the required chord into an acceptance record

For the hypothetical A–D panel, suppose A and D must work together but any three-key overlap must be rejected. Model S already misses the required two-key distinction. Model R passes that ideal static pair check, but its raw three-key result still needs a controlled rejection rule. Neither statement approves a complete design: first choose a circuit and receiver that can meet the required behavior, then verify the actual implementation.

Write each test row as an ordered sequence: initial released state; keys applied and their order; held state; keys released and their order; final recovery. Record the intended application command alongside the observed raw scanner state and accepted events. For near-simultaneous inputs, define the test timing relative to the real scan and debounce settings rather than assuming both contacts close at the same instant.

Include startup with a held key, an extra held key during a required chord, and recovery after the rejected combination is removed when those conditions are relevant to the equipment. Decide whether recovery requires all keys released or another explicit action. These are proposed acceptance fields, not a universal safety procedure or a prescribed timing limit.

Keep circuit resistance and voltage margin in a separate but linked record. Correct logical mapping cannot compensate for an input that never reaches a valid level. Conversely, valid voltage on every tested pin does not prove that the application interprets concurrent states correctly.

Five acceptance gaps that a single-key test can miss

Use these review scenarios to locate the missing requirement. They are not reported HYR failures.

• Wrong observation model: a quote assumes individual-row scanning while the host software keeps only active row and column sets.
• Required key suppressed: the controller avoids a ghost event but drops a real key needed for the intended command.
• Order-dependent acceptance: the demonstration passes in one press order, while a different order or release sequence produces another event.
• Recovery left undefined: a rejected overlap clears, but the equipment accepts a remaining held key as an unintended new action.
• Uncontrolled substitution: a pin-map, receiver or firmware change alters combination behavior even though each individual contact still passes inspection.

Release a testable RFQ, not a universal rollover claim

Issue one controlled package linking the named keys, matrix coordinates, tail contacts and mating connector view to the allowed-combination list. Add the host circuit and scan description, event acceptance record and responsibility for assembled testing. When comparing quotations, flag any supplier assumption that changes this interface or moves controller validation outside the quoted scope.

A useful supplier response identifies the circuit revision, continuity and isolation checks included, any supplied electronics, and exclusions. The OEM's system record should identify firmware, configuration, test sequences and accepted application actions. Retain a representative approved assembly and its configuration so later changes can be compared against the same behavior.

For an HYR engineering review, send the controlled matrix and combination requirements through the secure RFQ. Identify unresolved cases before fixing artwork and connector allocation. If a required state cannot be distinguished with the proposed interface, return the architecture decision to the electronics owner instead of relaxing the inspection wording.