Touch Screen Calibration: Why It Matters and How It Works

A cursor that lands two millimetres left at the corner of a kiosk screen is usually reported as a touch screen calibration problem. Sometimes it is. Often the transform is correct and the controller is reporting a position that drifts when a charger is connected, when a water film sits on the glass, or when the panel is mounted in a metal bezel with a poor ground return. Re-running a five-point calibration then appears to help for a day. This guide separates the errors that a coordinate transform can remove from those that belong to controller tuning, and defines the raw-data log and acceptance record that make the difference visible.

Which touch screen calibration errors are geometric?

Offset, scale, rotation and skew are geometric errors.

Geometric errors are repeatable and can be fitted out; noise, missed touches and water failures cannot, because they are not functions of position.

A geometric error is reproducible: touch the same target ten times and the reported point lands in the same wrong place. Offset appears as a constant shift across the panel. Scale error grows with distance from the origin, so the centre is close and the corners are far. Rotation makes a horizontal swipe produce a diagonal path. Skew stretches one axis relative to the other when a panel is bonded slightly off-axis or the controller electrodes are not perpendicular.

These errors are correctable because they can be described by a small number of parameters. A two-point calibration can remove offset and independent scale on each axis, but it cannot describe rotation, skew or local compression near an edge. That is why a device can pass a quick two-point check and still feel wrong to a user who draws diagonal lines or reaches the corners. The first diagnostic step is therefore not to recalibrate but to decide whether the error is repeatable at a given position. If it is not, the problem is upstream of the transform.

How should raw and transformed coordinates be logged?

Log raw counts and transformed pixels with one timestamp.

A usable log pairs raw counts, timestamp, transformed coordinates, orientation and firmware build, so a shift can be traced to mapping, driver or app.

Most touch problems are argued about because only the final pointer position is visible. The controller’s raw counts, the driver’s transformed coordinates and the application’s logical position are three different numbers, and a fault that appears in one may be absent in another. A useful log records all three for each contact, together with a monotonic timestamp and the report rate. It should also record the display resolution and orientation that were active, because a transform validated in landscape is not valid after a rotation.

Keep a ring buffer of several seconds at the controller’s report rate; it can be dumped after a failed interaction without flooding storage. On I2C or SPI controllers, also record bus errors and interrupt counts; a missed interrupt and a missed touch look identical in the application. The Linux I2C documentation covers the bus and its error handling, which helps interpret those errors. The Linux multi-touch protocol documents the event stream that a driver should expose, which makes a userspace capture comparable across platforms. Include the firmware build identifier in the same record so a result can be tied to a specific release.

When is affine calibration appropriate?

Affine fitting suits linear panels with small rotation.

Affine calibration corrects offset, X and Y scale, rotation and shear with six parameters; it suits panels whose residuals stay flat and fails where edges compress.

An affine transform maps one plane to another with a two-by-three matrix: two scale terms, two shear or rotation terms and two translation terms. It is the natural model when the sensor is flat, the electrodes are uniform and the only defects are placement and orientation. Three non-collinear targets are the minimum to solve it; in practice, least-squares fitting over a larger grid is used so that a single noisy touch does not define the result.

The diagnostic value of an affine fit is its residual. Fit the transform to a full grid, then plot the remaining error at every point. If the residuals are small and unstructured, affine is sufficient. If they grow toward one edge or form a consistent curve, the panel is not linear in that region and a higher-order or piecewise model may be needed. Do not add terms until the curve disappears: too many parameters can absorb a real hardware defect.

Affine calibration assumes a stable position for a stationary finger. If ten touches at one target scatter by more than the target tolerance, the fit is averaging noise, and the controller configuration should be reviewed first.

Which edge and corner points reveal nonlinear error?

Corners and edge midpoints expose compression first.

Test four corners, four edge midpoints and the centre; a centre that passes while corners drift indicates nonlinearity that two-point calibration cannot remove.

Resistive panels and some projected-capacitive designs compress the reported coordinate near the edge of the active area. The effect is easy to miss because a centre-only check passes, and it is most visible to users who press buttons placed at the bezel. A grid that includes the four corners, the midpoint of each edge, the centre and a few interior points will show the pattern without turning the test into a full metrology exercise. Keep the targets a known distance inside the active area so the test does not land in a dead zone outside the sensor.

Record the residual at each point rather than a single pass or fail. A corner that is 1.5 mm off while the centre is 0.2 mm off describes a different problem from a uniform 1.5 mm offset, even though both might fail the same limit. The pattern also tells the supplier where to look: edge compression often follows the electrode pattern or bonding stack, while a single bad corner may indicate damage.

Repeat the grid with the normal mounting hardware in place. A bezel that presses on the front stack can change edge coupling, so a panel that passes on the bench may fail once assembled. That is a mechanical finding and should be recorded as such.

How do rotation and scaling change coordinate mapping?

Apply rotation and scaling once, in one layer.

If controller, OS driver and application each apply rotation or scale, errors multiply; assign one owner for the transform and verify it against native resolution.

A rotation is a coordinate transform, and every layer that applies one assumes it owns the mapping. When the controller reports in panel coordinates, the OS driver rotates to display coordinates and the application scales to a logical layout, a single physical touch passes through three transforms. If one of them uses the wrong resolution or the wrong origin, the error is not a constant offset but a combination of offset and scale that changes with position.

The USB HID usage tables define how a digitizer describes its logical and physical range, and that description is the natural place to declare the coordinate space once. For non-USB stacks, the same discipline applies: document the units and origin at each boundary. Bar-type and stretched displays make the problem worse because X and Y scale factors differ, so a transform copied from a standard 16:9 panel will stretch touch along the long axis.

Verify the mapping with a diagonal swipe and a circular gesture, not only taps. A centre tap can pass while rotation is wrong; a diagonal exposes axis swap and a circle exposes independent scaling. The touch controller firmware and OS integration page covers the driver boundary in more detail.

What does calibration fail to fix about noise and water?

Calibration cannot remove noise or reject water.

Charger noise, water films, thick gloves and floating grounds change the signal before coordinates exist, so controller tuning, shielding or enclosure design must fix them.

A coordinate transform operates on a position that the controller has already computed. If the controller’s raw signal is disturbed, the computed position is disturbed too, and no amount of fitting will make it stable. Charger noise is the classic example: a switching supply couples into the sensor or the ground return, the reported position jumps or the controller reports a false contact, and the fault disappears when the charger is removed. The Infineon CAPSENSE design guide describes the coupling paths and tuning levers for its own controller family; the principles transfer, but the register settings do not.

Water is a different mechanism. A film bridges neighbouring electrodes and changes the baseline, so the controller may report a large contact, reject all touches or drift slowly as the film evaporates. Glove thickness reduces the coupling change and can make a valid touch look like noise. A floating ground reference shifts the whole baseline and makes edge touches unreliable. The Microchip capacitive touch design guide treats overlay, electrode and moisture coupling as design variables for the same reason.

These conditions belong in the test matrix, not in the calibration coefficients. If the product must work with gloves or in rain, the acceptance test must reproduce those conditions and the controller must be tuned for them.

How should acceptance limits be specified by application?

Set limits in millimetres at defined test points.

Acceptance should state maximum error and repeatability in millimetres at named points under defined glove, water and grounding conditions, not one percentage.

A percentage of screen width hides where the error occurs. On a 10-inch panel, 1 percent is roughly 2 mm, acceptable at the centre and marginal on a small edge key. Write the limit as a maximum radial error at named points, add a repeatability figure for repeated touches at the same point, and state the test conditions: finger or glove, dry or wet, charger connected or battery only, and the grounding arrangement of the enclosure.

Different applications justify different limits. A medical panel used for numeric entry needs tight repeatability and a documented glove condition. An industrial HMI operated with a gloved hand may accept a larger error but must reject false contacts from water or debris. A consumer kiosk may prioritise edge accuracy for large buttons. The limit belongs to the product requirement, not to the controller datasheet.

The table below shows how to structure the acceptance record so that each condition has its own scope. It is a template, not a set of limits; the values must come from the product requirement and the panel drawing.

Acceptance matrix for touch calibration and controller behaviour

Touch condition	Glove, water or ground state	Controller configuration	Misses and false contacts	Approved scope
Bare finger, dry, centre	Floating enclosure	Baseline configuration	Record count over 100 touches	General HMI use
Bare finger, dry, corners	Earthed enclosure	Baseline configuration	Record radial error per corner	Edge-key operation
Thin glove	Dry, battery powered	Increased sensitivity	Record misses and jitter	Industrial handling
Water film	Wet glass, charger connected	Water-rejection mode	Record false contacts and recovery time	Outdoor or wash-down use
Charger connected	Dry, earthed enclosure	Baseline with filtering	Record position jumps	Mains-powered product

Keep the raw log for any failing row; without it, no one can tell whether the failure is mapping, tuning or assembly.

What calibration record should survive a firmware update?

Version the calibration file and revalidate after updates.

Store the point set, residuals, serial, firmware and orientation with the calibration; an update that changes scaling or resolution must trigger revalidation.

A calibration record is only useful if it can be matched to the condition under which it was produced. Store the calibration date, the tool and firmware versions, the target layout and the residuals at every point. Add the panel part number and serial where the module carries one, because two panels from different lots can have slightly different edge behaviour. Store a checksum with the coefficients so a corrupted record is detected rather than applied.

The record should also state which layer owns the transform and what will invalidate it. A firmware update that changes the report rate, the coordinate resolution or the orientation handling invalidates the old coefficients even if the panel is unchanged. A hardware change to the cover glass, the bonding or the bezel can shift the baseline and requires a fresh acceptance run, not just a coefficient check. Build the invalidation rule into the update process so a stale file cannot be silently reused.

Finally, keep the raw log from the acceptance run with the signed record. When a field return is compared with the production record, the original residuals show whether the unit was marginal at shipment or whether something changed later. CDTech integrates display, touch panel and optical bonding in one production flow, which makes that comparison practical when the touch stack and the display are supplied as one module.