Automatic Drinking Event Recognition and Fluid Intake Estimation in Sport Using an Embedded Wearable Sensor ^†

Abstract

Proper hydration is important for athletic performance and recovery, but many athletes do not accurately track how much water or energy fluid they drink during training. At present, many systems use bottles with hardware like weight sensors, liquid-level sensors, and flow sensors. This study proposes a wearable sensor that uses an embedded accelerometer sensor and TinyML running on a microcontroller to automatically detect drinking activity and estimate fluid intake. A three-axis accelerometer and a microcontroller were mounted on a sports water bottle. Data were collected from different participants performing three activities such as idle, pickup, and active drinking with an anomaly detection algorithm. When a player is not performing any of the predefined activities which are related to drinking detection, the anomaly detection algorithm classifies it as a different activity and is hence not included in the analysis. Features were extracted from the accelerometer signals and used to train a neural network. Detected drinking events and timestamps are transmitted through Bluetooth Low Energy. Fluid intake was estimated from the duration and frequency of drinking events. The TinyML model achieved 96.6% classification accuracy across the three states on held-out test data (macro F1 0.954, ROC AUC 0.98) with an inference latency of <5 ms. The system operated continuously while remaining within the available power budget. The system successfully recorded drinking events and generated session-level hydration logs for all participants. The results of the proposed system show that a TinyML model can accurately recognize drinking activities and support automatic hydration monitoring. The system offers session-level drinking logs and fluid intake estimates that can assist athletes to stay optimally hydrated. Future work will include adding data from additional participants, personalized hydration recommendations, and real-time alerts when fluid intake is less than the recommended levels.

1. Introduction

Fluid loss during training degrades endurance, thermoregulation and cognitive function once body-mass loss exceeds roughly 2% [1], and restoring fluid afterwards improves subsequent performance, with the largest gains in the heat [2]. Yet most athletes rely on thirst or on a rough recollection of how many bottles they emptied, so intake during a session is rarely known with any precision. A sensor that records when and for how long an athlete drinks, with no manual logging, would close this gap.

Existing systems measure the liquid directly with load cells, capacitive or impedance level sensing, or in-line flow metres [3], which is accurate but requires a purpose-built container. An alternative is to sense the motion of the container: a small inertial node attached to any bottle observes the tilt and return trajectory of a drink, and the gravity vector rotating through the sensor frame gives a signature largely independent of the bottle itself [4,5]. This is the principle of wrist-worn activity recognition [6,7], where drinking and eating gestures are well studied [8,9], but a bottle-mounted node avoids confusion with the many other arm movements that occur in sport.

Running the classifier on the node itself, rather than streaming raw samples to a phone, is what makes a small battery-powered device practical. Tiny machine learning (TinyML) places a quantized network inside the microcontroller so that only compact event records leave the device, which cuts radio duty cycle, keeps raw motion data private and removes any dependence on a network [10,11,12,13].

This paper presents a bottle-mounted sensor node based on the Arduino Nicla Sense ME that classifies one-second accelerometer windows into drinking, picked (bottle handled but not consumed from) and not_drinking (idle), flags motion outside these states with a Gaussian mixture model (GMM) anomaly detector, and turns the event stream into a session-level hydration log sent over Bluetooth Low Energy (BLE), supporting low-cost preventive monitoring in line with United Nations Sustainable Development Goal 3, Good Health and Well-being.

2. Materials and Methods

2.1. System Architecture

Figure 1 shows the system. All signal processing and inference run on the sensor node: each one-second window is converted into a class label and an anomaly score, consecutive labels are merged into drinking events, and each event is sent as a BLE notification to a smartphone or gateway that keeps the session log. No raw acceleration data leave the bottle.

Figure 1. System overview. Sensing, feature extraction, classification, anomaly detection and event logic all run on the bottle-mounted Nicla Sense ME; only event records are transmitted over BLE.

2.2. Sensor Node and Choice of Platform

The sensor node is an Arduino Nicla Sense ME (22.86 × 22.86 mm, Arduino, Monza, Italy), which integrates a Bosch BHI260AP smart sensor (Bosch Sensortec GmbH, Reutlingen, Germany) hub with a built-in six-axis IMU and an ANNA-B112 module (Nordic nRF52832, Arm Cortex-M4F at 64 MHz, 64 kB RAM, 512 kB flash) that hosts the application and the BLE stack [14,15]. Only the three accelerometer axes are used in this work.

Figure 2 shows the assembled node. The board sits in a translucent snap-fit enclosure that adds only a few millimetres to each dimension, powered by a single-cell LiPo pouch cell (3.7 mAh); the USB-C connector is used for charging and flashing. The node is attached near the base of the bottle with double-sided adhesive, oriented so that the board z-axis runs along the bottle axis. This position keeps it clear of the carry strap and the drinking end and far from the grip point, so a given tilt rate produces the largest tangential acceleration at the sensor.

Figure 2. Sensor node: (a) Nicla Sense ME in its enclosure; (b) internal view showing the board and the single-cell LiPo battery; (c) node mounted near the base of the sports bottle used in the study.

The Nicla Sense ME was chosen over other TinyML-capable boards for four reasons. First, footprint: it is small enough to sit on the outside of a bottle without changing how the bottle is gripped or balanced. Second, the BHI260AP is a smart sensor hub rather than a bare IMU; it has its own core that samples the accelerometer and buffers it, so the application processor is not tied up with sampling. Third, the ANNA-B112 module combines a Cortex-M4F with floating-point unit and a BLE 5 radio in one package, so INT8 kernels run efficiently and no separate radio is needed. Fourth, the board carries an integrated LiPo charger and is well supported by the embedded machine learning toolchains used here. An Arduino Nano 33 BLE Sense offers a comparable radio and IMU in a 45 × 18 mm form factor, and an ESP32-class board computes more at a higher idle current.

2.3. Data Collection and Activity Classes

Acceleration was sampled at 62.5 Hz, which is sufficient for the low-frequency tilt and return motion of a drink (a full sip cycle lasts 2–5 s) while keeping the DSP cost small. Data was collected from five participants and streamed over a serial link to a host PC, with each recording labelled on capture. Three classes were defined (Figure 3): not_drinking, bottle at rest on a surface; picked, bottle lifted, carried or without being consumed from; and drinking, bottle raised, tilted to the mouth and returned. Motion outside these classes, such as the bottle being dropped, shaken or carried in a bag, is left to the anomaly detector rather than being given its own class.

Figure 3. The three activity classes as seen by the bottle-mounted node: not_drinking (bottle at rest), picked (bottle handled but not consumed from) and drinking (bottle tilted to the mouth).

Recordings were assigned to a training set and a held-out test set, and 20% of the training windows were then set aside as a validation set. The test set was kept fully separate from training, and all results in Section 3 are reported on the validation and test sets.

2.4. Windowing and Spectral Features

The processing pipeline takes the three raw axes into 1000 ms windows with a 500 ms stride, passes them through one spectral analysis block, and feeds the resulting features to a neural-network classifier and a GMM anomaly in parallel. In a raw drinking window, the dominant information is the slow rotation of the gravity vector, visible as the x and y channels moving in opposite directions during the tilt while z stays close to 9.8 m/s².

Each axis is passed through the spectral analysis block (axis scale 0.0746, decimation 1, sixth-order low-pass filter, 32-point FFT with log spectrum, no frame overlap). The parameters were initialized by an automated parameter search and kept because the resulting feature space separated the classes well (Section 3.1). The 30.6 Hz cut-off is only slightly below the 31.25 Hz Nyquist frequency, so the filter acts only as an anti-aliasing guard and the discriminative information lies in the shape of the log power spectrum. For each axis the block outputs RMS, skewness, kurtosis, spectral skewness, spectral kurtosis and 16 log-spectral-power bins of 1.95 Hz width (0.98–32.23 Hz), giving 21 features per axis and a 63-dimensional feature vector.

2.5. Classifier Architecture

Let x ∈ ℝ⁶³ be the feature vector of one window. The classifier is a fully connected network with two hidden layers and a SoftMax output, given in Equations (1) and (2):

h⁽¹⁾ = φ(W⁽¹⁾x + b⁽¹⁾), h⁽²⁾ = φ(W⁽²⁾h⁽¹⁾ + b⁽²⁾),

(1)

ŷ_c = exp(z_c)/∑_j=1³ exp(z_j), z = W⁽³⁾h⁽²⁾ + b⁽³⁾,

(2)

where φ(·) = max(0, ·) is the ReLU activation, W⁽¹⁾ ∈ ℝ^20×63, W⁽²⁾ ∈ ℝ^10×20 and W⁽³⁾ ∈ ℝ^3×10, and ŷ_c is the posterior probability of class c, giving 1523 trainable parameters in total. Training minimizes the categorical cross-entropy with an L1 penalty on the hidden activations, seen in Equation (3):

L = −(1/N) ∑_n=1^N ∑_c=1³ y_n,c log ŷ_n,c + λ ∑_l=1² ‖h^(l)‖₁,

(3)

with λ = 1 × 10⁻⁵. The model was trained for 100 epochs using Adam with a learning rate of 1 × 10⁻³ and a batch size of 32. The weights with the lowest validation loss were retained. The model was then quantized to INT8 using per-channel scales for the weight tensors and per-tensor scales for the activations [16], so that inference runs entirely in integer arithmetic on the Cortex-M4F.

2.6. Anomaly Detection

Because a three-class SoftMax always returns one of its classes, an unseen motion would be forced into drinking, picked or not_drinking. A GMM anomaly-detection block [17] therefore runs in parallel on the same features. Let u ∈ ℝ⁴ be the sub-vector of the four y-axis spectral-power features selected by a feature-importance ranking on the training set, all y-axis spectral power bins (16.6–18.55, 22.46–24.41, 28.32–30.27 and 30.27–32.23 Hz). Three Gaussian components are fitted to the training windows by expectation–maximization, seen in Equation (4):

p(u) = ∑_k=1³ π_k $𝒩$(u|μ_k, Σ_k),

(4)

where π_k are the mixing weights, μ_k the means and Σ_k the covariances. The anomaly score decreases monotonically with log p(u), so a window scoring above a threshold set from the training distribution is excluded from the event logic. These four bins carry the high-frequency vibration content on the axis perpendicular to the bottle, which is where dropping, shaking and transport differ most from the smooth tilt of a drink; restricting the detector to four dimensions also keeps the covariance estimates well-conditioned for a training set of this size.

2.7. Event Detection and Fluid Intake Estimation

Window-level outputs are converted into events on the device. A drinking event is opened when consecutive windows are classified as drinking with an anomaly score below threshold and is closed when the label returns to picked or not_drinking; a short debounce suppresses single-window flicker at the boundaries. The event duration d_i is the number of contributing windows multiplied by the 0.5 s stride, and fluid intake per session is estimated by Equation (5):

V = r ∑_i d_i,

(5)

where r is a per-user sip rate in mL/s, obtained once per athlete by weighing the bottle before and after a short series of drinks while the node records the event durations and stores them on the gateway. Each closed event is sent as a BLE GATT notification carrying its start timestamp, duration and estimated volume; because the node transmits only on events, the radio is idle for most of a session.

3. Results

3.1. Feature Space

Figure 4 shows the training windows projected into two dimensions of the feature space. The classes form distinct clusters: not_drinking a compact region, picked an elongated one, and drinking the largest, because it contains the tilt, hold and return phases. The only overlap is between the tail of the drinking cluster and the start of the picked cluster, which corresponds to the lift phase common to both activities.

Figure 4. Two-dimensional projection of the training windows after spectral feature extraction.

3.2. Training

Figure 5 shows the training graphs. Validation accuracy rises steeply over the first 20 epochs and settles between 0.92 and 0.97 after epoch 60, while training accuracy climbs slowly to about 0.97. Training loss falls monotonically to 0.14, whereas validation loss flattens at roughly 0.25 from epoch 70 onwards. The small, stable gap between the curves, with no rising validation loss, indicates that 100 epochs was an adequate budget and that the model is not over-fitting.

Figure 5. Training graphs over 100 epochs: (a) accuracy; (b) loss. Orange: training; blue: validation.

3.3. Classification Performance

Figure 6 gives the row-normalized confusion matrices of the INT8 model. On the validation set the model reaches 97.2% accuracy with a loss of 0.21, its only confusion being 6.3% of drinking windows labelled picked, and per-class F1 scores of 0.97, 1.00 and 0.97. On the held-out test set the accuracy is 96.6%, with 2.9% of drinking windows labelled picked and 8.3% of picked windows labelled not_drinking, giving per-class F1 scores of 0.99, 0.96 and 0.92. Both confusions are between physically adjacent states, lifting the bottle to drink and setting a picked bottle down, which is the overlap visible in Figure 4.

Figure 6. Confusion matrices of the INT8 model, row-normalized to percentages of the true class: (a) validation set; (b) held-out test set.

Table 1 summarizes the aggregate metrics. Quantization did not degrade performance: on the test set, the INT8 and float32 models produce identical confusion matrices, and on the validation set the INT8 model is slightly better (97.2% against 94.4%). The area under the ROC curve is 0.98 on both sets.

Table 1. Aggregate metrics of the float32 and INT8 models.

Metric	Validation float32	Validation INT8	Test float32	Test INT8
Accuracy	94.4%	97.2%	96.6%	96.6%
Macro F1	0.958	0.979	0.954	0.954
ROC AUC	0.985	0.984	0.984	0.985
Loss	0.204	0.210	0.202	0.200

3.4. Anomaly Detection Results

Figure 7 shows the fitted GMM on two of the four selected axes. The training windows lie inside the shaded one-, two- and three-standard-deviation contours, with a dense cluster at high spectral power (handling motion) and a broader cluster at low power (rest and slow tilt). Windows from motions not present in the training set fall outside the outer contour, score high, and are dropped from the event logic.

Figure 7. Training windows and the fitted GMM components on the y-axis spectral power bins 16.6–18.55 Hz and 22.46–24.41 Hz.

3.5. On-Device Deployment

The trained pipeline was compiled into an Arduino library with the INT8 model and flashed to the Nicla Sense ME (Table 2). The complete pipeline executes in under 5 ms per window, two orders of magnitude below the 500 ms stride, so the processor sleeps for most of each period and the node runs continuously through a training session on the LiPo battery. The node logged every drinking event, and the gateway produced a per-session hydration log for each participant.

Table 2. Deployment resources on the Arduino Nicla Sense ME.

Quantity	Value
Sampling rate/window/stride	62.5 Hz/1000 ms/500 ms
Model	63–20–10–3 dense, 1523 parameters, INT8
Inference latency (DSP + NN + GMM)	<5 ms
Peak RAM	5 kB
Flash	100 kB
Radio	BLE GATT notification per event

4. Discussion

The results confirm that a single three-axis accelerometer on the bottle is enough to recognize drinking with high accuracy and that recognition survives INT8 quantization without loss. The closest prior bottle-mounted system, by Griffith et al., used hand-engineered inclination features and support vector regression on 1908 drinks from 84 people to estimate volume directly from motion [4]; our approach separates the problems, recognizing events on the device and leaving volume to a per-user rate calibration, which keeps the model small at the cost of assuming a roughly constant sip rate within a session.

Processing on the node also means that no motion trace of the athlete is stored or transmitted and that the module can be moved between bottles, which fits the preventive-health aim of SDG 3 [18]. The main limitation is the size of the dataset, i.e., recordings from five participants and a single bottle, enough to show that the pipeline works but not to bound performance across athletes, bottle shapes or fill levels, and fill level in particular changes the dynamics of a drink [4]. The anomaly detector was also evaluated only on training-distribution data, and the fluid-intake estimate has not yet been validated against weighed intake.

5. Conclusions

A bottle-mounted TinyML sensor node based on the Arduino Nicla Sense ME was built to recognize drinking events and estimate fluid intake in sport. Using 63 spectral features from a three-axis accelerometer at 62.5 Hz, a 63–20–10–3 INT8 neural network classifies drinking, picked and not_drinking windows with 96.6% accuracy (macro F1 0.954, ROC AUC 0.98) on a held-out test set, a parallel GMM detector rejects motions outside these classes, and the whole pipeline runs in under 5 ms per window on the device. Future work will extend the dataset to more participants, bottle types and fill levels, validate the volume estimate against weighed intake, and add personalized hydration targets with real-time alerts.