The problem
A person praying can lose count of rakats, especially in the four rakat prayers and especially when tired. Paper counters and beads need a free hand and phone apps cannot be touched during prayer. The client wanted a small enclosure under a standard mat, two force sensors that pick up the head touching down, an LED display to glance at between rakats, and a cycle that fits a four rakat prayer with no user interaction at all.
What I did
On boot the firmware averages eighty samples on each sensor while the mat is unloaded and uses that as zero. The runtime loop compares the live reading against that baseline as an absolute delta, so it does not matter which way round the sensor is wired. The state machine has three states. IDLE waits for four consecutive samples over the 300 mV press threshold on both sensors, which rejects a single spike.
PRESSING needs the press to hold 250 ms before it counts, which rejects a quick tap, and abandons after 3 seconds, which catches a stuck sensor. CONFIRMED waits for four release samples. Every two contacts lights one LED. At four LEDs the device flashes three times and resets. While idle the baseline drifts slowly toward the live reading so temperature and sensor creep do not push it out of band.
I also wrote a Python simulator that runs the same logic against synthetic traces, with six bench tests, and designed the SolidWorks enclosure with main body, back cover and foam liner.
Decisions that shaped it
- Polarity agnostic delta detection, so the same binary ships against either wiring.
- Debounce and sustain as two separate gates, because a child crawling across the mat trips a single threshold.
- Two contacts per LED and four LEDs, matching the checkpoint count a person keeps in their head.
- A host side simulator, because a real bench test of a prayer mat is expensive in time.
Result
A finished product the client took to a manufacturer: firmware, enclosure and the test rig that proves the logic.
