36 Mobile Sensing: Labels and Pipeline
A phone window is only useful for activity recognition when “walking,” “stairs,” or “vehicle” refers to a clear time interval and trustworthy observation. Labels connect physical behavior to sensor samples. A weak label pipeline teaches the model annotation habits instead of human activity.
36.1 Align the Label With the Motion Window
Read Figure 36.1 from phone sensors through windowing, features, model, and activity label. Every arrow carries a timing assumption. If the annotator presses “walking” after movement begins, the first window may span standing and walking. Keep uncertain transition windows separate instead of forcing a clean class.
Figure 36.2 focuses on the deployed direction. A timed sensor window enters the same feature recipe used in training, the model emits scores, and a decision rule produces a label. Follow the version information beside that path: sampling configuration, feature code, model, and threshold must travel together.
The evidence route in Figure 36.3 broadens the label source. Phone motion, location or speed cues, and a diary or confirmed journey can support a transport label. Read the sources before the joined decision. Agreement strengthens the case; disagreement should remain visible rather than being overwritten by the preferred sensor.
Use a ten-second journey segment sampled at 50 Hz. It contains (10\ \mathrm{s}\times50\ \mathrm{samples/s}=500) samples per axis. Five two-second non-overlapping windows fit that segment. If a bus starts moving halfway through window three, label windows one and two as stationary, windows four and five as vehicle, and mark window three as a transition or exclude it under the written rule. Calling all five “vehicle” would attach the future state to earlier stillness.
Label provenance should name who or what supplied the class, when it was recorded, allowed classes, uncertainty, and any reconciliation. For self-reports, account for delay and mistakes. For GPS-derived transport, state thresholds and gaps. For scripted laboratory activities, record whether the phone position matches deployment.
Predict pipeline checks. Create a fixture with 500 samples per axis and expect five windows under the non-overlap rule. Place the change at five seconds and confirm the transition policy selects window three. Remove the confirming journey record and expect lower label confidence rather than an unchanged claim. Finally, replay one saved window through training and deployment paths and compare the exact feature order.
36.2 Overview
This first route defines activity labels and the evidence path from phone sensors to a bounded classification task.
This is part 1 of 2. Continue with Mobile Sensing: Features and Deployment for the second focused route.
36.3 Start With the Story
A sampling rate is the number of sensor readings taken in one second. A phone can take many motion readings while a person walks. One reading says little on its own, so the system studies a short block called a window.
Picture a phone in a trouser pocket. Its accelerometer senses changes in motion. Its gyroscope senses turning. The model groups a few seconds of readings, finds useful patterns, and gives the window a label such as walking, sitting, or unknown.
The label is a bounded guess, not a direct fact. Phone place, user, window size, battery rules, and the set of allowed labels all shape the result. A model trained on one pocket may fail when the phone is held or left on a desk.
This plain path leaves out the exact feature maths and model setup. The Practitioner section shows how to build and test the windows. Under the Hood covers signal axes, feature values, class errors, memory, and power limits.
Build a small honest test. Pick the labels first. Include “unknown” so the model is not forced to make a false choice. Ask several people to walk, sit, stand, and use stairs with the phone in each planned place.
Keep the people used to train apart from the people used for the final check. Save missed acts and wrong labels, not just the total score. Check battery use and the delay before a label can guide an alert.
State the limit with the result. A pocket test does not prove a wrist, bag, or desk case. A test on one group does not prove all users. Recheck when the sensor, phone build, label set, or model changes.
Start with a small label set. Each label needs a plain meaning and a good example. Make hard pairs clear, such as standing and sitting still. Keep “unknown” for a case that does not fit.
Check the window by sight. A very short window may miss the shape of a step. A long window may mix two acts and make the result late. Pick a size from the real task and test the wait it creates.
Keep the raw time and the label time. If an alert follows, keep that time too. This shows whether the phone sensed late, the model ran late, or the app acted late.
Watch power. A high rate and constant model use can drain a phone or watch. Test a full day with the real sensor plan. A model that works only near a charger may not fit the job.
Let a person correct a bad label when the task allows it. Keep that note as new proof, but do not train on it without a clear check. One quick tap can also be wrong.
Picture an IoT team using the ideas in Mobile Sensing and Activity Recognition during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.
The mathematical gist. At the chapter’s 50 Hz rate, each gyroscope sample spans 0.0200 s and angle is the running sum . With a catalog-typical 0.0500°/s residual bias and 1.00°/ angle random walk, a 2-second window accumulates 0.100° bias versus 0.0236° random error; after 60 seconds those become 3.00° and 0.129°. Bias grows linearly, so fusion and ground truth are necessary for long trials.
36.4 Activity Recognition Labels
Mobile sensing uses phone or wearable sensors as a source of motion, location, audio, proximity, and context records. In human activity recognition, the usual signal is an inertial stream from accelerometers and gyroscopes. The model does not classify one sample at a time. It slices the continuous stream into windows, extracts features from each window, and predicts a bounded label such as walking, running, sitting, standing, stair movement, or unknown.
The important design question is not "can a phone recognize activity?" The useful question is which activity classes, phone placements, users, sampling rate, window size, labels, and validation setting the claim covers. A model trained with a phone in a trouser pocket may not mean the same thing when the phone is in a backpack, on a desk, or held in the hand.
If you only need the intuition, this layer is enough: mobile activity recognition is a windowed classification problem. Keep the window, label source, placement, user context, battery cost, privacy boundary, and retest trigger with every model claim.
Worked example: a walking-versus-running classifier may collect accelerometer and gyroscope streams at 50 Hz, group them into 2-second windows, extract magnitude and frequency features, and emit one label per second. The claim is only valid for the carrying style and label process used in the study. A waistband phone, a loose jacket pocket, and a phone held while texting can produce different axis directions, damping, and transitions, so placement metadata is part of the model evidence rather than a note added later. The output cadence also matters: one label per second may be fine for summaries, but fall alerts or coaching prompts need a latency target tied to the window and overlap.
Activity recognition is only one mobile-sensing target. The same evidence pattern can support transportation-mode detection from motion, GPS, Wi-Fi, and map context; environmental or social context recognition from microphone, camera, location, and co-location signals; and narrow behavior-inference tasks such as fitness feedback or intervention prompts. These claims should be more tightly bounded than the interface label suggests: emotion, context, and co-location inferences are sensitive, so the release record should state consent, data minimization, retention, unsupported classes, and the fallback behavior when the signal does not justify a label.
That same evidence pattern also scales by who is sensing, not just what is being sensed. Mobile and wearable sensing is attractive largely because it reuses general-purpose hardware people already carry and charge themselves, unlike a dedicated sensor network where every node needs its own deployment and maintenance budget; that cost difference is also why mobile sensing can grow by recruitment instead of by capital spend. Individual sensing serves one person, such as fitness tracking or a behavior-intervention prompt, and the release record only needs that person's placement, consent, and validation evidence. Group or community sensing pools several people's devices toward a shared goal, such as a neighborhood safety assessment, local environmental monitoring, or a shared recycling target; the evidence record now also needs a group-membership boundary and a rule for how one unreliable participant's data is weighted or excluded. Urban-scale sensing recruits a large, mostly anonymous population running the same application to track a citywide signal, such as the speed of a disease's spread, traffic congestion, or pollution; at that scale, per-device validation is impractical, so the review shifts toward aggregate calibration, participation bias, and the confidence interval on the population estimate rather than any one phone's accuracy. Naming the tier early changes what "validated" has to mean before the claim is trusted.
The activity-recognition diagram in Figure 36.1 makes the label boundary visible before the chapter compares features or classifiers.
Trace Figure 36.1 from accelerometer, gyroscope, and magnetometer samples into time windows, then through feature extraction to activity labels. The window fixes the evidence available for one decision; features summarise its motion; the classifier maps only that representation to the supported classes. Read the output labels last and notice what they omit: placement, user, device, and unsupported activity context. That gap advances the chapter’s running argument that a mobile label is valid only inside the collection, consent, placement, timing, and population boundary that produced it.
Signals
Accelerometer and gyroscope streams describe motion and orientation. Location, audio, and app context can add evidence, but each signal has its own permission and quality boundary.
Windows
Continuous samples become fixed-duration windows such as 1 to 3 seconds. Overlap smooths decisions but increases compute and energy use.
Features
Mean, standard deviation, magnitude, energy, dominant frequency, and axis correlation summarize each window before classification.
Boundaries
Labels are valid only for the phone placement, users, activities, sample rate, and validation population that the training and test evidence cover.
Overview Knowledge Check
Before choosing features, use Figure 36.2 to see exactly what one activity label is allowed to claim from a two-second window.
Read Figure 36.2 from SAMPLE to WINDOW, then check why CLASSIFY keeps all three probabilities before ACT releases WALKING. The confidence gate prevents the 0.78 winner from being presented as certainty, while the frame bounds preserve the evidence behind that decision.
Activity alone is not enough to explain a commute; Figure 36.3 shows why transportation mode needs motion and environmental context to agree.
In Figure 36.3, MOTION contributes vibration and turn-rate evidence while CONTEXT contributes 34 km/h, a road corridor, and 600 m stop spacing. FUSE keeps car and bicycle as runners-up; that visible uncertainty is the price of spending less GPS energy or collecting less location context.
36.5 Continue to Part 2
Continue with Mobile Sensing: Features and Deployment.