← Back to projects

Connected health / August 2026

Smart
Medication Monitor.

Making the moments
around medication visible.

I connected physical sensing, embedded intelligence and an iPhone app to understand what happens between a reminder and a medication event.

MedBox / On-device intelligence
01 / Physical signalWeight changeHX711 → ESP32-S3
MedBox iOS result screen showing weight evidence and a separate visual signal in a development mock event
Actual app / Mock event
02 / Visual signalAction contextMediaPipe → Core ML
Project scopeHardware → ML → iOS
Weight holdout result74% 82%
Inference locationDevice + phone
OutcomeWorking research prototype

01 / From reminder to evidence

A small device.
A complete system.

A reminder acknowledgement leaves a gap. The prototype connects medication removal, visible actions and a timestamped record, preserving what each sensor can actually tell us.

Physical sensing / ESP32-S3

What left the platform?

01
Load cell + HX711

Weight sampled at approximately 10 Hz.

02
Rolling baseline + event window

~3 s baseline · 5 s event · 1.5 s settling.

03
Rules + 500-tree Random Forest

On-board classification, sent to the app over BLE.

Visual sensing / iPhone

What happened next?

01
OV2640 camera

ESP32 streams MJPEG over local Wi-Fi.

02
MediaPipe hands + pose

24 sampled frames become 2,576 temporal features.

03
Core ML action classifier

Six visible actions, processed on the phone.

One event, with both signals preserved.

SwiftUI brings together the expected dose, weight result and visual action. Raw camera frames are processed in memory and are not saved to history. The normal flow runs without a desktop computer.

BLE + local Wi-Fi

The system records supporting behavioral evidence. Weight removal and an ingestion-like action cannot confirm swallowing.

02 / Physical rules meet machine learning

Let physics handle the count.
Let the model read the motion.

One or two removed pills produce a useful net change. Near zero, the final weight alone cannot distinguish no removal, a pill returned or a disturbance. I routed these events to a model of the full trajectory.

Explore the physical gate

A little uncertainty
is part of the design.

Move the weight ratio to see which branch receives the event.

Stage 1 / Physical routingONE

The net change lies in the one-pill band. The physical rule returns ONE directly.

0.50 ≤ r < 1.50
Reference mass: 0.848 g · Removed mass: 0.848 g

Interactive explanation of the documented thresholds, using a 0.848 g mock pill. This does not run the trained forest. Near-zero events need 24 trajectory features to classify NONE, RETURN or DISTURBANCE.

Why hierarchy?

The same ending can hide different events.

The dynamic branch excludes final net weight and looks at duration, dips, recovery, variation and area. A return and a disturbance can look similar; that ambiguity explains the remaining holdout errors.

  • 24 dynamic features
  • 500 trees on ESP32
  • 3,174 exported tree nodes
Five representative Round 2 weight trajectories for NONE, ONE, TWO, RETURN and DISTURBANCE
Recorded Round 2 events / Report, p. 19 Enlarge ↗

03 / An interaction became a measurement problem

The best button
was off the device.

Pressing the physical button changed the load path through the scale. I compared five button-triggered trials with five BLE-triggered trials, then moved the trigger into the app.

4.45×

lower mean absolute error with BLE

Interaction design became part of sensing quality. Adding the OV2640 later also occupied GPIO 4, reinforcing the decision to remove the button.

Design takeaway

In a physical interface, the way a user starts a measurement can change the measurement itself.

04 / Bringing the system into everyday use

Evidence, translated
into an experience.

The bilingual SwiftUI app connects planning, device interaction and event review. Each result keeps the weight and camera evidence readable, including when the signals disagree.

English screenshots captured from the working MedBox app in the iOS Simulator. Home and result screens use development Mock events. These images illustrate the interface, not measured hardware performance.

01Keep inference close

Weight classification on the microcontroller; vision on the iPhone.

02Keep the meaning precise

Expected count + TAKE supports an event. Conflicting signals remain visible.

03Keep records local

On-device history and Doctor View; no cloud or remote patient lookup.

05 / What the experiments establish

A working prototype.
Evidence at every layer.

The clearest model comparison uses the same cross-session holdout: hierarchical classification reached 82%, up eight percentage points from the flat Random Forest. The other tests answer different questions.

82%

Cross-session weight accuracy

Train on 50 Round 1 events; test on 50 Round 2 events. The flat Random Forest baseline reached 74%.

96.67%

Camera internal 5-fold CV

120 clips across six actions, from one participant in one session. Cross-user performance remains untested.

150/150

Python / C++ prediction agreement

Recorded and synthetic events match the frozen Python pipeline. This checks implementation parity, not accuracy.

100%

Weight internal 5-fold CV

100 real events pooled across two rounds. This describes internal separability, not an independent field result.

Weight holdout confusion matrix: 41 of 50 correct; nine disturbances mistaken for RETURN or NONE
Weight / Cross-session holdout Enlarge ↗
Camera internal validation confusion matrix: 116 of 120 correct; four errors between ADJUST and TOUCH_FACE
Vision / One participant, one session Enlarge ↗

Where weight recognition breaks

All nine holdout errors came from DISTURBANCE. Seven were classified as RETURN and two as NONE, pointing towards richer disturbance data and more varied mechanical conditions.

Where visual recognition overlaps

Four internal-validation mistakes occurred between ADJUST and TOUCH_FACE. The next useful test separates participants, sessions, lighting and camera placement.

The final report records iPhone hardware flow verification as passed by 21 August 2026, alongside firmware compilation and software checks. Structured latency, power and long-duration stability measurements remain future work.

Reflection / The next iteration

Design the evidence.
Then earn the confidence.

This project brought hardware, signal processing, model deployment and interface design into one loop. The most useful decisions came from understanding how those layers affect each other.

01 / Broader evidence

Independent users and sessions, different pills and containers, and more varied disturbances.

02 / Physical completion

A real lid sensor or actuator. OPEN currently starts a timed event; it does not measure or actuate a lid.

03 / Product readiness

Repeatable device performance logs, secure pairing and authenticated, consent-based remote access.

Explore the work

From experiment to implementation.

← Return to the project circle