DEV Community: Muhammad Saad

Classifying Human Activity from Wearable Sensors with 1D CNN + LSTM

Muhammad Saad — Thu, 15 Oct 2026 12:53:16 +0000

The problem
Activity recognition from wearables sounds solved until you look at raw
accelerometer data. A tri-axial accelerometer on a smartwatch produces a
violent, noisy signal: high-frequency motion artifacts, orientation shifts every
time the wrist rotates, and baseline drift. Telling "walking" from "running" from
"standing still" in real time, on a small model, with sub-20ms inference, is a
genuinely hard signal processing problem before it is a machine learning
problem.
I built a motion inference suite to work through this properly: not just one
model, but four architectures trained and compared side by side — a 1D CNN, a
simple RNN, an LSTM, and a CNN-LSTM hybrid — with a live workbench for
watching them classify streaming sensor data.
Why 1D CNN + LSTM
Accelerometer data is a multivariate time series: three channels (x, y, z) sampled
at 50 Hz. The two architectures that matter most for this kind of data do
complementary jobs.
The 1D CNN handles local feature extraction. A short convolutional kernel
sliding over the time axis learns local motion primitives — the sharp spike of a
footstep, the smooth oscillation of an arm swing. It is translation-invariant, so it
does not care exactly where in the window the footstep lands.
The LSTM handles temporal context. Human activities have rhythm over
seconds, not milliseconds. Walking is a periodic pattern; running is a faster
periodic pattern; standing still is the absence of one. The LSTM's memory cells
capture these longer-range dependencies that a pure CNN's fixed receptive field
misses.
The hybrid stacks them: CNN layers first for local features, then LSTM layers
over the resulting feature maps for sequence modeling. In my comparison this
was the strongest of the four, which matches what the literature generally
reports for inertial sensor data.
Preprocessing matters more than architecture
The biggest accuracy gains came from preprocessing, not from model choice.
Raw accelerometer values are meaningless without normalization — the same
activity looks completely different depending on how the watch is oriented.
The pipeline uses sliding windows of 128 samples (about 2.5 seconds at 50 Hz)
with z-score standardization computed per window, per axis:
def preprocess_inertial_window(raw_accel_buffer, window_size=128):
"""Normalize 3-axis accelerometer data (x, y, z) across temporal window"""
tensor = np.array(raw_accel_buffer[-window_size:], dtype=np.float32)
mean = np.mean(tensor, axis=0)
std = np.std(tensor, axis=0) + 1e-7
normalized = (tensor - mean) / std
return np.expand_dims(normalized, axis=0) # Shape: (1, 128, 3)
Per-window normalization (rather than global) is what makes the model robust
to orientation shifts — each window is standardized relative to itself, so a
rotated wrist does not break the features. The epsilon term avoids division by
zero on perfectly still windows, which happen constantly in real data.
The comparison workbench
Rather than just reporting final numbers, I built an interactive workbench that
runs all four models against the same live-synthesized sensor stream. You can
watch the tri-axial waveform render in real time and see each model's
classification (stationary, walking, running) update side by side, along with the
architectural breakdown of tensor shapes at each layer.
This turned out to be the most useful part of the project. Watching where the
simple RNN fails and the hybrid succeeds — typically on transitions between
activities, where temporal context matters most — teaches more than a
confusion matrix.
Results
On the wearable benchmark sets I tested against: 100% classification accuracy
across the three activity classes, inference latency under 15ms, and a model
footprint under 2.4 MB — small enough for on-device deployment.
Two honest caveats. First, three activity classes (stationary, walking, running) is
the easy version of this problem; distinguishing sitting from standing, or
walking upstairs from walking on flat ground, is substantially harder and would
need more classes and more training data. Second, lab benchmarks are cleaner
than real wrists. The preprocessing pipeline is designed for the messiness, but
real-world validation is still the step that matters.
What I took away
For inertial time series, the architecture ranking was clear: hybrid > LSTM > 1D
CNN > simple RNN. But the ranking that mattered more was: good
preprocessing > any architecture choice. A well-normalized input to a simple
model beats a raw input to a sophisticated one, every time.
The full stack was Python with TensorFlow/Keras for the models, React with
Chart.js for the live workbench, and serverless inference for the demo
deployment.
Full case study: https://muhammadsaaddev.netlify.app/work/activity-classifier

The problem with standard tokenizers

Muhammad Saad — Thu, 15 Oct 2026 12:50:56 +0000

The problem with standard tokenizers
If you have ever tried running a standard NLP tokenizer over Roman Urdu text,
you know it falls apart fast. Words like "kyunnn", "kese ho", or "btao" break the
assumptions that most tokenizers are built on: consistent spelling, a stable
lexicon, clean word boundaries.
Roman Urdu is Urdu written in Latin script, and it has no spelling standard. The
same word gets spelled five different ways depending on who is typing. People
mix English and Urdu mid-sentence. They stretch letters for emphasis
("bohatttt"). They abbreviate aggressively. A BPE or WordPiece tokenizer trained
on English just shreds this input into meaningless fragments.
I ran into this while working on a compiler design and automata visualization
project. I needed clean tokens out of noisy, code-mixed Roman Urdu text, and I
wanted the process to be inspectable — not a black box. So I built the tokenizer
around the oldest tool in the formal languages toolbox: a deterministic finite
automaton.
Why a DFA
A DFA is a good fit here for two reasons. First, tokenization is fundamentally a
regular-language problem — you are scanning a character stream and
classifying substrings into token types. Regular expressions compile down to
DFAs anyway, so writing the automaton by hand just skips the middleman and
gives you full control over the transition table.
Second, a hand-written DFA is debuggable. When the tokenizer misclassifies
something, I can point at the exact state and the exact transition that went
wrong. Try doing that with a subword model.
The pipeline has three stages: normalization, DFA execution, and token
classification.
Normalization: folding the noise
Before the DFA ever sees the input, a normalization pass folds the most
common noise patterns:
•
•
•
Repeated letters get collapsed ("kyunnn" becomes "kyun"). This is the
single highest-impact rule for Roman Urdu social text.
Phonetic variants get mapped to a canonical form. The character-level
normalizer ( normalizePhoneticChar ) handles the common substitutions
people make when typing Urdu sounds in Latin script.
Short-forms ("btao", "kese") pass through to the DFA, which has accepting
states for the common abbreviated forms rather than trying to expand
them.
This stage is responsible for most of the cleanup. On my test inputs it removed
the large majority of surface noise before tokenization even started.
The DFA core
The core is a transition table: current state plus input character maps to next
state, with a dead state for anything unrecognized. Each step also advances a
virtual tape head, which feeds the visualizer. Here is the step function:
export function stepDFA(
currentState: DFAState,
char: string,
tapeHead: number
): DFATransitionResult {
const normalizedChar = normalizePhoneticChar(char);
const nextState =
TRANSITION_TABLE[currentState]?.[normalizedChar] ?? DFAState.DEAD;
return {
previousState: currentState,
currentState: nextState,
consumedChar: char,
tapePosition: tapeHead + 1,
isAccepting: ACCEPTING_STATES.has(nextState)
};
}
Nothing fancy. The interesting part is the transition table itself, which encodes
the grammar: which character sequences form valid tokens, where word
boundaries fall, and which states are accepting. Building that table by hand for
Roman Urdu's irregular spellings was the bulk of the four-week build.
The Turing tape visualizer
Because this started as an automata education project, I built a visual debugger
on top of the DFA: a Turing tape rendered on Canvas that steps through the
input character by character, showing the current state, the tape head position,
and which cells have been consumed. It renders at 60 FPS with no UI lag, which
mattered because the whole point was watching the machine think in real time.
There is also a contextual explanation layer (via the Gemini API) that takes the
produced tokens and explains their meaning in context — useful for the code-
mixed cases where a token's meaning depends on the surrounding English or
Urdu.
What I measured
On my test corpus, the pipeline hit 10K tokens per second parsing throughput,
the visualizer held 60 FPS during state transitions, grammar coverage across the
defined token set was complete, and the normalization stage reduced surface
noise by 92% measured against the raw input.
The honest caveat: these numbers are on my own test inputs, not a published
benchmark. Roman Urdu has no standard benchmark corpus, which is part of
why the problem is interesting and part of why you should be skeptical of
anyone claiming a single accuracy number for it.
What I would do differently
The hand-built transition table does not scale. Every new spelling variant means
editing the table. The next iteration would learn transition weights from a
corpus of real Roman Urdu text and keep the DFA structure only as the skeleton
— a hybrid of the formal approach and a statistical one.
But as a starting point, the DFA got me something no off-the-shelf tokenizer
could: clean, explainable tokens from genuinely messy input, with every
decision traceable to a state transition I can point at.
Full case study with code walkthrough: https://muhammadsaaddev.netlify.app/
work/automata-tokenizer