Capacitive Touch Charger Noise: Correlate Raw Data with Power-Supply Conditions

Capacitive touch charger noise rarely looks like a power problem in the field report. The user says the screen jumps while charging, and the bench test with a battery passes. The raw touch data would show the baseline moving in step with the charger, but nobody captured it. This guide defines the raw-data signature, the power and grounding configurations that must be compared, and the counting method that turns a complaint into a reproducible result.

How does capacitive touch charger noise appear in raw data?

Charger noise appears as a baseline shift and false peaks.

Raw data shows a common-mode shift, increased channel noise or false contacts that correlate with charger switching, not with the finger.

A capacitive sensor measures a small change in capacitance against a baseline. When a charger introduces a common-mode voltage or a high-frequency disturbance, the baseline moves, the noise on each channel increases, or the controller reports contacts where there is no finger. The pattern often correlates with the charger’s switching frequency rather than with the user’s action.

The raw data is more useful than the final touch event. Most controllers expose per-channel counts, a baseline, a difference value and a status flag. Capture those at a fixed report rate while the charger is connected and disconnected, and compare the two records. A channel that moves in step with the charger is a coupling path; a channel that changes only when the user touches is a real contact.

A charger that switches at a frequency close to the sensor’s scan rate produces a slow beat that looks like a drifting baseline rather than random noise. The baseline is often tracked by the controller’s own algorithm, so the raw difference value may look normal while the baseline is being pushed. Record the controller settings, the report rate and the raw values. A final event log that says touch at coordinates may hide the baseline movement that caused it.

Which power and grounding configurations need comparison?

Compare battery, charger and earthed-adapter configurations.

Include battery only, the product charger, a different charger, a grounded adapter and a user touching the chassis, because each changes the return path.

The charger is not the only variable. The return path depends on whether the product is floating, connected to a charger, connected to a grounded adapter, held by a user or standing on a conductive surface. Each configuration changes the common-mode impedance and the path through which the disturbance reaches the sensor.

The matrix should include at least: battery only, the product’s charger, a second charger of a different design, a grounded laptop adapter, and the same cases with a user touching the enclosure. If the product has a metal chassis, include a case where the chassis is bonded to earth and one where it is floating.

The mains socket and the building wiring are part of the configuration; a test in one room may not reproduce in another if the earth path differs. Record whether the product is in a plastic or metal enclosure, because that changes the coupling to the user. Record the charger model, its input voltage and the cable. A charger that behaves differently in another location may be responding to the mains wiring, so the test location matters as well.

How should common-mode interference be measured?

Measure common-mode voltage between charger and earth.

A differential probe or current probe on the charger lead shows the common-mode disturbance, referenced to the same earth the user or fixture represents.

The disturbance can be measured as a voltage between the charger output and earth, or as a current in the charger cable. A differential probe across the relevant points, or a current probe around the cable, shows the waveform and its frequency. The measurement must be referenced to the same earth that the user or test fixture represents, because the interference depends on that path.

A current probe around the charger cable is often more informative than a voltage probe, because it shows the disturbance that actually flows toward the product. Record the probe type, the bandwidth and the earth reference. A measurement with a different earth arrangement can show a different amplitude and frequency, which is why the result must be tied to the configuration.

The Infineon CAPSENSE design guide describes the coupling and tuning principles for its controller family, and the Microchip capacitive touch design guide covers overlay and grounding considerations for its family.

When can scan-frequency changes improve immunity?

Frequency hopping can avoid charger harmonics.

If charger switching falls in the touch scan band, changing scan frequency or hopping can move the measurement away from the interference.

A capacitive controller scans at a frequency or a set of frequencies. If the charger’s switching harmonics fall near the scan band, the disturbance is more likely to appear as noise or false contacts. Changing the scan frequency, or using a hopping scheme that avoids the disturbed band, can improve immunity without changing the hardware.

The change is not a universal fix. A different charger may have a different switching frequency, and a hopping scheme that avoids one may land on another. The controller vendor’s tuning guide defines the available frequencies and the effect on scan time, power and response.

Hopping is most useful when the controller can spread its scan across several frequencies and average the results, rather than selecting one fixed frequency. Record the scan setting and the charger that was tested. A result that depends on one charger is a configuration finding, not a general immunity claim.

What trade-offs follow increased filtering?

More filtering costs latency and weakens weak touches.

A heavier filter reduces noise but slows response and can reject a gloved or light touch, so measure the trade-off against input requirements.

A digital filter can average the noise or reject a narrow band, but it also delays the response and may remove the small signal of a gloved or light touch. The user experiences a slower or less reliable interface, even though the false-contact count falls.

The filter should be evaluated with the same gesture set used for the product, because a slow swipe and a quick tap respond differently to the same delay. The trade-off should be measured at the same time as the noise. Record the filter setting, the response time and the touch results for bare finger, glove and light contact. A filter that passes the charger test but fails the glove test has moved the problem, not solved it.

The USB HID usage tables and the Linux multi-touch protocol define how the resulting contacts are reported; they do not define the filter, but they show what the host expects to receive.

Which user-contact conditions expose the worst case?

The worst case is a user coupled to earth through a charger.

A user holding a grounded appliance, standing on a conductive floor or touching a metal chassis changes the return path and can strengthen interference.

The charger’s common-mode disturbance needs a return path. A user who is insulated from earth may not complete it; a user holding a grounded appliance or standing on a conductive floor may complete it strongly. A metal chassis that is bonded to earth can make the path even more direct.

A user wearing insulating shoes on a dry floor is a different case from one standing on a concrete floor; both belong in the matrix. Test the product in the user conditions the application actually allows: hand-held, on a metal table, on an insulated surface, with and without a grounded appliance nearby. The worst case is often a combination, not a single condition.

Record the user condition and the charger configuration together. A result described only as “with charger” does not say which return path was present.

How should false touches and missed touches be counted?

Count false and missed touches per fixed exposure.

Record false contacts and missed deliberate touches over a fixed number of attempts and duration, so the result is a rate rather than an anecdote.

The idle observation is important because a false contact can appear without any user action. A single false touch is not a measurement. Define a test sequence: a fixed number of deliberate taps at defined targets, a fixed duration of idle observation, and a fixed number of swipes. Count the missed taps, the false contacts during idle and the extra contacts during gestures.

Run the same sequence for each charger and grounding configuration. The rate makes the configurations comparable, and the raw data explains the mechanism.

Record the sequence, the duration and the counts. If the test is repeated, the same sequence should be used, otherwise the rates are not comparable.

What evidence should be sent to the controller vendor?

Send the raw log, charger model and grounding setup.

The vendor needs raw channel data, charger make and model, grounding setup, firmware settings and touch counts to reproduce the issue.

The vendor cannot reproduce a report that says the touch is noisy. Provide the raw channel data with timestamps, the controller configuration, the charger model and its switching frequency if known, the grounding and user condition, and the counts of false and missed touches. Add the schematic or block diagram of the touch and power path.

A video of the screen is useful context, but it is not a substitute for the raw data. Keep the original files, not screenshots, because the timing detail is lost in an image. State what was changed and what was not: filter settings, scan frequency, firmware version and hardware revision. A clear record lets the vendor distinguish a tuning issue from a layout or grounding issue.

The table below is a template for the evidence. It is not a set of limits; the values come from the product and controller requirements.

Charger-noise test matrix

Touch condition	Glove, water or ground state	Controller configuration	Misses and false contacts	Approved scope
Battery only	Floating enclosure	Baseline settings	Reference counts	Reference configuration
Product charger	User holding enclosure	Baseline settings	False and missed counts	Approve only if within limit
Second charger	User holding enclosure	Baseline settings	False and missed counts	Compare model sensitivity
Grounded adapter	Chassis bonded to earth	Baseline settings	False and missed counts	Approve only if within limit
Filtered setting	Worst charger and user case	Filter and scan adjusted	Counts and response time	Approve if latency fits

The Linux I2C documentation is relevant when the controller’s raw data is read over I2C, and the TCA4307 datasheet documents a bus buffer that can affect the interface during a disturbance.