Detecting frost in a prototype: connect the sensor reading to what you can see

For a team exploring frost monitoring, a low temperature is only part of the story. The product may need to know whether frost is forming on a particular surface, or whether a defrost cycle has cleared it. Those events need observations of their own.

In a Home Assistant community thread started in November 2024, users tried to infer heat-pump defrost from temperature and power. They ran into delayed triggers and false triggers, then discussed ways to refine the inference. It is a different system, but it raises the question to ask here: what physical event does the signal actually identify?

On our bench we connected a Mysentech FDE frost sensor to a Raspberry Pi Pico (RP2040) on a GraftPort carrier, then placed the sensor and the controller inside a refrigerator compartment with the cable running out. This note follows that setup to define a useful next experiment, without claiming that a complete frost-detection system has been demonstrated.

Keep placement and measurement tied together

The FDE is a flat board with three capacitive channels, labeled C1, C2 and C3, plus a GND, TX, RX and VDD connector. The supplier describes reference and frost-related channels. That explains the design intent; the experiment still has to establish how each channel behaves in the intended installation.

We photographed where the boards sat on the compartment shelf and how the cable left the compartment. That record matters, but it was not paired with a time-aligned record of frost growth. To evaluate any future threshold, you need to know what was happening on the sensing surface when each reading was taken.

Keep the bench wiring and the installed placement as separate records. On the bench, the sensor connected through an adapter to UART0, with GPIO16 transmitting and GPIO17 receiving. In the compartment, the cable route, the door seal and the board's position relative to the cold surface all become part of the measurement.

Start with the individual channels

We used our FDE driver package. The example program reads temperature, each of the three channels, a combined channel field, a no-load preset and version information. The calibration call in the program was commented out, so the recorded run did not perform a new calibration, and should not be described as calibrated.

The captured output reported 31.2 °C, C1 = 0.030 pF, C2 = 4.396 pF and C3 = 3.549 pF. Those values are a warm baseline to compare with a later cooling sequence. They are not a temperature trace from inside the refrigerator.

There is one specific issue to resolve. The printed C2+C3 Sum field was 10.004 pF, which is not the sum of the two displayed channels (4.396 + 3.549 = 7.945). Before using that field, check the raw register and how the driver interprets it. Keep logging the individual channels while that question is open; they do not depend on the combined field.

A discrepancy like this is easy to miss when only a single "frost" output reaches the interface. Logging the individual fields alongside any combined value is what made it visible.

Observe the event you want the device to recognize

For the next test, document the sensor's mounting position, then take timestamped photographs of its surface alongside the temperature and channel log. Follow the full sequence: cooling, any visible frost formation, and recovery after the door is opened or a defrost runs. If no frost forms on the target surface, record that too. A cold compartment alone does not establish the event.

Things worth recording in that run:

A useful outcome would be a repeatable relationship between a documented surface condition and a change in the channels. With that in hand you can evaluate a detection threshold against observations, including the cases that should not trigger it. Until then, a number labeled "frost" in software hides the main unresolved question.

This keeps the first prototype manageable. Establish the sensing experiment before connecting it to automatic defrost control, which adds actuator behavior and further system checks. The bench readout and the placement record show where that work can begin; the time-aligned observation is the next piece.