If you are developing a device that dries a washable pad, a timer is easy to understand: run the cycle for a set period and stop. A sensor-based decision asks a harder question. What reading would mean that this particular pad, in this particular position, is dry enough for the intended use?
A robot-vacuum discussion about mop drying captures the consumer concern behind that question. Participants discuss dampness, maintenance and drying noise, with differing experiences. The comments help identify the problem; they do not establish a hygiene threshold or show that one drying method always works.
On our bench we ran an early sensing experiment with a Mysentech HDS sensor, a flexible board with two capacitive sensing regions, connected to a Raspberry Pi Pico (RP2040) on a GraftPort carrier. We recorded the assembly, its registers and two capacitance channels changing during a run. We did not tie those values to the water remaining in a pad. That connection is the thing to establish before promising automatic drying control.
Begin with the sensing surface and its connection
The two sensing regions sit on a flexible board, which matters for any material test: the material and the sensing regions need a repeatable relationship if one run is to be compared with another. A pad that sits a little differently each time will produce a different reading for reasons that have nothing to do with moisture.
The sensor talks Modbus over UART0 at 9600 baud, on GPIO16 and GPIO17. Its interface table puts the sensor's RX on the controller's TX and its TX on the controller's RX, alongside the power connections.
Before running the MicroPython program, we read the device with Modbus Poll, a desktop tool that reads numbered registers. A temp(x10) register held 279, which is 27.9 °C under the stated scaling: an example of how a stored integer becomes a readable measurement, and why the scaling has to be documented with the register map.
The same window counted 174 transmissions and 58 errors. Keep that detail when reproducing the setup. Getting values back is not the same as having stable communication, and a link that logs errors on about a third of its requests on the bench is unlikely to get better inside a warm, vibrating appliance.
Read both channels, not just a "humidity" label
Our program used our HDS driver with its Modbus library, configured a serial host, and passed it to the sensor object with address 1, two retries and a 50 ms retry delay. It read a set of basic measurements once per second and handled communication errors.
The captured output started at 29.2 °C, with channel C1 at 7.967 pF and C2 at 51.263 pF. C1 later rose to 25.514 pF before returning near 8 pF, while C2 stayed much closer to 51 pF. A picofarad is a unit of capacitance; these are electrical measurements, not percentages of water remaining in a material.
The difference between the channels is the useful observation: one region responded strongly during the run and the other barely moved. The output also included humidity_level_raw = 0, but nothing in the run documents a calibrated set of drying levels. It is also not the same quantity as the relative-humidity percentage that an air temperature and humidity sensor reports.
Give the electrical change a physical meaning
For the next experiment, use the intended pad or material and hold its position and contact with the sensor constant. Log both channels and the temperature through a documented wetting and drying sequence. Pair the log with an independent reference for the material's condition, such as a defined weighing procedure where that is appropriate. We have not run this yet.
The first question is whether similar material conditions produce distinguishable, repeatable readings in the actual assembly. If moving the pad changes the result as much as drying it does, the fixture needs work before an automatic stop threshold will be useful. Different thicknesses or replacement materials may also need their own evaluation, since a user will not always fit the pad the product was tuned with.
Even a repeatable dryness estimate answers only the drying question. It does not establish cleanliness, odor prevention or sterilization. Keep those claims separate so the product feature means what the evidence supports.
Our HDS run is a practical beginning: a real board, readable channels and a recorded change. The next prototype should connect that change to the condition the user cares about, rather than relabel raw values as "dryness" in the interface.