Edge Data Collection & Labeling

Embedded → TinyML + Edge AI on Cortex-M

The unglamorous step that decides everything

A real TinyML project is 80% data, 20% model — a perfectly reasonable 1D-CNN trained on bad data fails in the field, while a mediocre model on good data often works fine. “Good data” means real sensor data, captured the same way the device will in production, labeled correctly, and balanced across classes — not a downloaded public dataset adjacent to the problem.

What the talk covers (and where this lesson picks it up)

Daniel Situnayake (Edge Impulse) walks through his real workflow for training TinyML models across three sensor types — accelerometer/time-series, audio, and vision — using Edge Impulse's Studio. The segment embedded above covers the shape of that workflow before any specific classifier: what “good” raw sensor data looks like, why you capture it on the actual target device rather than a lab bench sensor, and how labeling turns a raw stream into training examples. The talk's later half (architecture, deployment, optimization) is covered by the sibling lessons in this topic.

Capture the same way the product will

The single most common beginner mistake: recording clean, deliberate, isolated samples (“now I wave my hand, now I stop”) that don't resemble how the sensor stream actually looks during normal use. A gesture classifier trained only on isolated clean waves fails the moment it sees a wave embedded in continuous natural arm motion, because it has never seen what “not-a-wave” looks like in context.

Always capture and label an explicit idle / background / noiseclass — continuous data from normal use where none of your target gestures occur. Skipping it is the single most common reason a demo that works perfectly on the bench starts firing false positives the moment it's deployed on a real person doing real things.

Class balance and split discipline

Two disciplines matter as much as the labels themselves:

Discipline	Why it matters
Class balance	90% idle + 3% each of three gestures lets a model score high accuracy by nearly always predicting idle — track sample count per class as you capture, not just after
Split by session, not by shuffled sample	shuffling windows into an 80/20 split lets windows a few hundred ms apart from the same session land on both sides — the model memorizes that session's noise instead of generalizing, inflating test accuracy. Split whole sessions/subjects/days, never individual windows

A capture manifest, in code

Whatever tool you use, it helps to think of each capture session as a structured record you can audit later:

{
  "session_id": "wave_2026-07-17_003",
  "device_id": "nano33ble-07",
  "label": "wave",
  "subject": "s2",
  "sample_rate_hz": 62,
  "duration_s": 10.0,
  "sensor": "accel_xyz_g",
  "split": "train"
}

The subject and split fields are the two beginners most often skip — and the two that later save you from silently misleading test accuracy.

Try it — walk through a capture session

A simulated 4-class gesture capture: record samples, watch the class-balance meter, then attempt a split.

Step 1 — record samples per class

Practice

Read the official Edge Impulse data acquisition docs and follow the continuous motion recognition tutorial. Record ~10s samples for “idle”, “wave”, and “snake” on your own phone or board, label each, and check the class-balance view before training.

Completion saves automatically after you read through to the end.

Next lesson →