11.5 Sensor and IoT time-series

What this is and why it exists

Data coming off real hardware is a time series with the hardware's defects included: sensors drift, readings go missing, clocks disagree, calibration wanders. Handling those is not preprocessing before the real work — it is most of the engineering. This topic is that handling, the windowing decisions that quietly decide what a model can learn, and the leak that is this domain's signature: overlapping windows from one session landing on both sides of a split.

The vocabulary

• Multivariate stream — several sensors producing readings over time.
• Sampling rate mismatch — sensors reporting at different rates.
• Clock skew — devices whose notion of the time differs.
• Resampling — putting several streams onto a common time base.
• Window — a fixed span of the stream treated as one example.
• Overlap — consecutive windows sharing samples.
• Drift — a sensor's readings shifting slowly for reasons unrelated to the world.
• Dropout — readings missing entirely.

The mental model

Synchronisation is the unglamorous first step and most projects underestimate it. A wearable reports acceleration many times a second, a heart rate every few seconds, a temperature every minute. Devices have their own clocks, which drift; a phone's timestamp and a sensor's timestamp differ; buffering delays arrival relative to occurrence; and where several devices are involved, none of them agrees with the others.

So: put everything on one time base before anything else. Resample the fast streams to a common rate — or resample the slow ones up, holding or interpolating, and be explicit about which, since interpolating a value that was never measured is inventing data and should be a deliberate choice rather than a default. Where absolute alignment matters, use a shared event to correct the offset: a tap felt by two sensors, a signal both can see, a synchronisation marker at the start. Check the alignment on real data by plotting two streams around a sharp event — the misalignment is visible immediately and invisible in any summary statistic.

Windowing is where most of the modelling decisions actually sit, and window length frequently matters more than the model does.

Length must exceed the phenomenon. Recognising a footstep needs perhaps a second; recognising cooking needs tens of seconds; a machine fault developing over a shift needs minutes. Too short and the pattern does not fit inside a window, so no model can see it. Too long and each window contains several different things and the label becomes a mixture.

Overlap decides how many examples you get. Half-overlapping windows roughly double the count and mean a pattern is never unluckily split across a boundary. That is a real benefit and it is exactly what creates the trap below.

Labelling is the harder half. Continuous activity does not divide neatly, and the honest questions have to be answered rather than defaulted: does a window get the label at its centre, or the majority label, or is a mixed window discarded? What about the transition, where somebody is standing up — a genuine third state, an edge case to drop, or noise? Write the rule down and apply it consistently, because a rule applied inconsistently is a labelling error the model will faithfully learn.

Then the leak, which is the signature failure of this domain. Windows overlap, so consecutive windows share most of their samples. Split those windows at random into training and test, and the test set contains windows that are nearly identical to training windows — the model has effectively seen them, and the reported accuracy is fiction. The number is usually spectacular, which is what makes it convincing.

And it is worse than overlap alone. Even without overlap, windows from the same session, the same person and the same device are far more similar to each other than to windows from a different one. A model can identify the session — the particular way this person walks, the way this device sits — rather than the activity, and score well by doing so.

So split by session and by subject, never by window. All windows from one recording go to one side. Where the model must generalise to new people, hold out whole people and report the score across held-out subjects, which will be considerably lower than a random split and is the number that predicts deployment. Do the windowing after the split, not before, which removes the whole class of error mechanically rather than by remembering.

Activity recognition from wearables is the template problem because it contains every characteristic difficulty: several sensors at different rates, ambiguous boundaries between activities, classes that are wildly imbalanced (sitting dominates everything), subject variation so large it dominates class variation, and label noise from people annotating what they were doing from memory. Solve it once, honestly, and the transfer to industrial and medical sensor problems is nearly complete.

Now the hardware defects, which is where the engineering is.

Drift is a slow shift unrelated to the world — thermal, ageing, mechanical. It is dangerous because it looks like a trend, so a model trained on early data sees a different baseline later and quietly degrades. Detect it by watching a reference: a period where the true value is known, a resting baseline, a redundant sensor. Correct it by removing a slow trend, by normalising per session rather than globally, or by using features that are immune to a constant offset — the variation within a window rather than its level, or a difference between two sensors rather than either alone. Choosing offset-immune features is the cheapest defence and it is under-used.

Dropouts are missing readings — a lost packet, a flat battery, a loose connection, a device asleep. The important part is that a gap is information, not an inconvenience: a sensor that stopped may have stopped because the thing it measures stopped. So record where data was missing rather than filling it silently, and treat filling as the deliberate decision it is: forward-filling is honest for a slowly changing quantity and dishonest for a fast one; interpolating across a long gap invents a signal; and dropping a window with too much missing is frequently the right answer.

Calibration error is a systematic offset or scale error, which differs between devices — the same measurement from two units disagrees, so a model trained on one performs worse on the other. Calibrate where you can, normalise per device where you cannot, and evaluate across devices rather than on the one you developed with.

And silent failure is the one to design for, because a sensor that reports plausible constant values has failed in the way that is hardest to notice: nothing errors and the data looks fine. Check for it explicitly — a variance of zero over a window, a value pinned at a limit, a reading that has not changed in an implausible time — and flag it at ingestion, which is the quality gate from the production module applied here.

What you should now be able to explain or do

Put multiple streams on one time base and verify alignment against a sharp event. Choose window length from the phenomenon and overlap deliberately. Write a labelling rule covering centre, majority, mixed windows and transitions. Explain the overlap leak and the session leak, and split by session and subject before windowing. Say why activity recognition transfers. Detect and correct drift, preferring offset-immune features. Treat dropouts as information and choose filling deliberately. Handle calibration differences across devices, and detect silently failed sensors at ingestion.

Check yourself