Adding a pressure-sensitive control: start with the pad at rest

If you are adding a squeeze or press control to an interactive object, the hard part may begin after the sensor starts responding. The cover, the adhesive and the support can all become part of what presses on the pad. You need a useful difference between "someone pressed it" and "the assembled object is just sitting there".

An Arduino forum discussion about a pressure pad from October 2012 starts with a simple goal: detect whether someone is still in bed. The pad proposed there is very different from the one below, but the distinction carries over: recognizing a state does not necessarily require displaying an exact pressure. Tekscan's guidance on testing force sensors for OEM applications gives an example of an adhesive change affecting a force-sensing prototype, which is why the surrounding assembly belongs in the test.

On our bench we connected a Mysentech MFYM-1S-9-9 pressure sensor to a Raspberry Pi Pico (RP2040) on a GraftPort carrier. The program starts with an unloaded pad, establishes a baseline, and prints both the raw signal and a converted pressure value. That sequence is worth keeping before designing the outer surface.

Understand where the force and the wires will go

The module is a narrow board with a small sensing area at one end. A cover has to transmit the intended press to that area, while the rest of the assembly supports the module without loading it.

The board also carries more than one group of pads. A group of four marked VCC, DIO, CLK and GND is a programming port. The serial interface used by our example is marked UTX and URX elsewhere on the board. Four pads in a row are not enough to identify a cable connection; read the labels before soldering.

Our program configured UART0 at 115200 baud on GPIO16 and GPIO17 and passed it to our MFYM driver.

Give "no press" a recorded starting value

Before the measurement loop, the program tells the operator to leave the sensing area unloaded. It discards five startup frames and takes the median of the next seven as the zero baseline. The median is the middle value of the sorted samples, which limits the influence of one unusual sample. In the loop, the program reads a sample, extracts the raw value and converts it to kilopascals.

This matters for the product. If a cover is already pressing on the pad during zeroing, that load becomes the starting value. Whether that is acceptable depends on the intended control and on how reliably the assembly returns to rest. Record the condition at zeroing instead of treating every startup as equivalent, and decide when the product is allowed to re-zero: at every power-up, only on request, or never once assembled.

Our run recorded a baseline of 1048. The output started at 0.000 kPa, reached 3.841 kPa during a press, and returned to small negative values such as −0.048 kPa. The raw channel was printed beside the conversion, so the change is visible without relying on the pressure label.

We did not use reference loads or a defined contact area, so the kPa conversion is not validated. For an early control surface, the useful result is narrower: the output changes relative to a known starting condition and returns near it afterward. A force-measuring instrument would need calibration evidence that this test does not provide.

Test the control through its actual cover

The next experiment should use the proposed cover and support. Record:

We have not run these tests yet; they are the next step after the bare-pad run.

If resting values and intended presses overlap, changing the software threshold alone may not fix it. Inspect how the cover contacts the pad and how the assembly holds the board. Once the states are clearly separate, a threshold can represent a physical action that users can repeat.

That keeps the project focused. The first goal is a control people can operate consistently; a precise pressure display is a separate goal with a different evidence requirement.