Radar-HAR Data Collection: A Practical Guide

To collect a useful radar human activity recognition (Radar-HAR) dataset, define the claim you want to test, record each activity across the people and conditions relevant to that claim, and verify capture integrity and label timing during collection. Preserve original measurements and assign independent participants, sessions or rooms to evaluation splits before generating windows. A large folder of spectrograms cannot repair a collection protocol that confuses activity with room, person or recording order.

Imagine recording every walking trial in a corridor and every sitting trial beside one particular desk. A classifier may achieve an impressive score by recognizing the recording context. Even a participant-independent split would preserve the same activity–location relationship. The experiment would leave a basic question unanswered: did the model learn human movement, or the circumstances in which you recorded it?

This guide treats dataset collection as experimental design. It covers the decisions to make before recruitment, the checks to run while a participant is still available, and the evidence to preserve for a defensible evaluation.

The design principles apply across radar modalities. The acquisition and storage examples below assume frequency-modulated continuous-wave (FMCW) radar.

If an existing release already answers your question, start with our comparison of Radar-HAR datasets. For decoding and processing the files you collect, use the companion guide to building a Radar-HAR pipeline from raw ADC samples. Here, the priority is collecting the right evidence in the first place.

1. Write the claim before writing the recording script

Complete this sentence: After training on these recordings, the system should recognize these activities for these people, in these conditions, using this input, with this decision delay. That sentence determines which variation the dataset must contain.

A system that labels a pre-cut eight-second clip solves a different task from a system that detects an activity in a continuous stream. The latter must handle waiting, transitions, entry and exit, and actions outside its vocabulary. Decide which task you intend to evaluate before choosing trial lengths.

Intended claim	Collection must enable	Evaluation boundary
New sessions from known users	Separate recording sessions with documented setup changes	Hold out complete sessions; users may remain familiar.
Recognition for unseen users	Multiple people covering the target activities	Hold out people, including every session and recording they contributed.
Transfer to another room	Activity coverage in multiple rooms; preferably overlapping participant coverage	Hold out rooms and disclose whether test people are familiar.
Unseen users in an unseen room	Enough people and rooms to reserve both independently	Keep final test people and the final test room out of development.
Continuous recognition	Long streams with background, transitions and other motion	Evaluate events and time in operation, as well as class predictions.

Table 1. The intended claim determines the collection design and the evaluation boundary. These are planning recommendations, not guarantees of generalization.

Also define who the data represents. A convenience sample of young laboratory colleagues does not establish performance for older adults or people with mobility limitations. Record relevant participant characteristics with consent, explain recruitment, and keep the eventual claim within the population you actually studied.

2. Cross the conditions that could become shortcuts

A confound occurs when factors vary together so closely that the experiment cannot separate their effects. In Radar-HAR, activity can become entangled with participant, room, radar placement, furniture, clothing, trial order or firmware version.

Start with a coverage matrix: activities down the rows and participant–room–session combinations across the columns. Mark what you plan to record. Missing cells often reveal problems before any signal analysis does.

For example, if different people appear in each room, a performance change between rooms also includes a participant change. Recording at least a shared participant subset across rooms helps separate those effects. A completely crossed design offers clearer comparisons, although scheduling and recruitment may require a carefully documented partial design.

Within a practical block—such as one participant in one room during one session—include the relevant activities and vary their order. NIST’s treatment of randomized block designs explains how blocking controls known nuisance factors while randomization addresses remaining variation. The radar-specific coverage choices still depend on the intended use. [1]

Two coverage matrices compare walking recorded only in Room A and sitting and drinking only in Room B with a crossed design that records every activity in both rooms. — Figure 1. An illustrative collection design can confound activity with room. Recording each activity in both rooms separates those factors more clearly; participant and session coverage must also match the intended claim. The cells show example coverage, not measured results.

Prevent shortcuts without removing the task’s meaning

Keep a chair in the scene during several activities when appropriate, rather than introducing it only for sitting. Vary drinking props across suitable trials if you want the model to recognize the action across objects. However, do not remove every meaningful contextual cue: a chair is legitimately part of sitting down. The goal is to test which cues support the claimed use, then prevent an accidental cue from carrying the entire label.

Avoid recording every repetition of one class in a single uninterrupted batch. That makes activity correlate with warm-up, fatigue, operator behavior and time. Shuffle activity order within feasible blocks, counterbalance unavoidable sequences, allow breaks, and retain the actual order and random seed. Record protocol deviations instead of quietly rewriting the plan afterward.

Treat viewing geometry as an experimental factor

Log radar height, position, azimuth, tilt, participant range, body facing direction and movement direction. Facing the sensor and moving toward it are different attributes. A person can face sideways while translating along the radar line of sight.

Radar measures radial motion, so an action can produce a different signature when its movement direction changes. Include the views and ranges required by your claim, and check them in the pilot. Our guide to how human motion produces micro-Doppler explains the physical reason. Do not describe a frontal, fixed-range collection as viewpoint-independent.

3. Freeze a sensor configuration you can reconstruct

Choose settings around the slowest and fastest motion of interest, the sensing volume, angular needs and permitted decision delay. Use the actual device documentation to verify the combination. TI’s configuration guide shows that range, velocity, frame timing and output choices interact; one attractive setting does not define the complete operating point. [2]

Save the exact configuration file that the device accepted, its firmware and SDK versions, and a configuration identifier with every recording. Retain the command log or readback when available. A screenshot of the visualizer cannot reliably reconstruct the acquisition.

Record this group	Include at least	Why it matters
Waveform and sampling	Carrier/start frequency, chirp slope and timing, ADC rate, samples per chirp	Reconstruct range and Doppler axes and interpret sampling limits.
Frame and antenna schedule	Frame period, physical chirp count, active receivers, TX sequence and MIMO mode	Recover the data cube and the sampling interval for each transmitter.
Receiver and encoding	Gain, ADC bit depth, real/complex mode, stored word size, byte order and channel layout	Decode signed samples and distinguish ADC resolution from storage format.
On-device processing	Clutter removal, CFAR settings, peak grouping, tracking, exported fields and units	Know which evidence survives into a heatmap or point cloud.
Geometry and versions	Device ID, pose, coordinate convention, configuration hash, firmware and decoder version	Reproduce physical placement and software interpretation.

Table 2. Minimum configuration groups for a reproducible FMCW collection. Exact field names and valid combinations depend on the device.

For time-division multiplexed MIMO, distinguish all physical chirps in a frame from chirps belonging to one transmitter. Doppler processing must use the correct per-transmitter timing. Also distinguish the frame output rate from the chirp sampling rate: a 20-frame/s stream does not, by itself, specify the unambiguous radial velocity.

Save the earliest representation the research needs

If you intend to change the range FFT, clutter filter, Doppler processing or detector, retain the required earlier measurements. Point clouds already reflect detection and processing decisions; they cannot reconstruct samples that the device never exported. If the study evaluates a fixed point-cloud interface, storing points can be a reasonable boundary—provided you describe that boundary accurately.

Call files “raw ADC” only when they contain the corresponding device samples. TI’s raw-capture application note documents different layouts for different devices and capture modes. Confirm lane order, I/Q order, sign extension and framing against the applicable layout before interpreting a spectrogram. [3]

Treat detector settings as part of collection whenever the device exports detections. Our comparison of CA-, GO-, SO- and OS-CFAR explains why detector choice and calibration affect what survives. A mid-campaign threshold change needs a new configuration record; otherwise, it can masquerade as a change in human behavior.

4. Calculate the recording budget before booking participants

Consider an illustrative unpacked ADC payload with four receivers, 256 complex samples per chirp, 128 physical chirps in total per frame, and 20 frames/s. Each complex sample contains one 16-bit I word and one 16-bit Q word: four stored bytes. This is a storage example, not a validated radar configuration.

Payload rate = 4 receivers × 256 samples/chirp
             × 128 total chirps/frame × 20 frames/s
             × 4 bytes/complex sample
             = 10,485,760 bytes/s
             = 10 MiB/s

One hour     = 37.748736 GB = 35.15625 GiB

The count of 128 already includes the physical chirps across the transmit schedule; do not multiply it by the transmitter count again. If your configuration instead specifies 128 chirps per transmitter, calculate the total first. Headers, padding, auxiliary channels, different packing and compressed output require their own accounting.

Measure sustained capture with the actual laptop, interfaces, disk and concurrent reference sensors. Average payload throughput does not prove that a system can absorb bursts or avoid buffer overflows. TI’s DCA1000 guide describes missing or out-of-order packets and buffer-related errors, which is why capture logs belong in the dataset. [4]

Budget separately for backups, reference video, derived arrays and repeated captures. Keep original measurements immutable and write processed outputs elsewhere. Before a campaign, open and decode a file from the backup location; a successful copy message alone does not demonstrate that the workflow can recover usable data.

5. Run a pilot that can stop the campaign

A pilot should exercise the complete path: acquisition, transfer, decoding, timing, annotation and a simple development-only recognition baseline. Include different participants, the planned range and view extremes, short and slow actions, and the longest intended continuous recording. Choose pilot coverage to expose failure modes, rather than treating one attractive walking spectrogram as acceptance.

Check a known-distance reference and a clearly directed motion to verify range scaling, Doppler sign and channel interpretation. Then inspect the weakest relevant movements at the most difficult planned geometry. This checks whether the settings preserve the information the study needs, rather than whether a strong reflector appears somewhere on the screen.

Check each recording before the participant leaves

Check	Evidence to inspect	Action when it fails
Completeness	Expected/received frames, packet counters, file size and capture logs	Flag missing or reordered data; repeat when feasible and retain the failed attempt’s record.
Timing continuity	Monotonic sensor times, timestamp gaps, resets and reference alignment	Locate gaps; preserve real elapsed time and document clock segments.
ADC integrity	Sample distribution, rail occupancy, channel activity and implausible constant blocks	Investigate gain, packing and decoder assumptions before accepting the capture.
Scene and action	Correct person, intended geometry, full relevant motion and operator position	Annotate deviations; distinguish valid challenging trials from protocol mistakes.
Traceability	Configuration ID, parent recording ID, annotation file and verified copy	Complete the metadata and recovery check before ending the session.

Table 3. A per-recording acceptance check. Define device- and task-specific thresholds in the pilot, before examining final test performance.

For ADC clipping, inspect the rails implied by the device’s effective resolution and stored representation. A 12-bit ADC can occupy a 16-bit container; a check that only looks for the largest 16-bit integers may miss clipping. Do not repair saturation by merely rescaling the saved samples.

Likewise, do not infer perfect capture from a plausible file size. If a capture tool inserts padding for missing data, the size can look correct. Inspect the tool’s documented behavior, its logs and continuity evidence. Preserve a validity mask where samples or frames are unavailable; deleting gaps and renumbering time changes the apparent motion timing.

Separate recording integrity from recognition difficulty

A missing packet and a valid frame with zero reported points are different events. The second can occur when the fixed sensing pipeline provides no detections for a real scene. Preserve valid empty frames and legitimate weak signatures when they belong to the intended operating conditions.

If you exclude every trial with too few points or too little motion energy, you may remove the cases that reveal the system’s limits. Define exclusions before evaluation and report their counts by activity, person and condition. Keep difficult valid observations in the relevant evaluation; record genuine acquisition failures separately with a reason and any replacement trial ID.

6. Annotate observed actions, then measure timing uncertainty

An instruction to “sit now” marks a cue, not the physical start of sitting. A filename marks a trial, not every instant inside it. Store activity intervals on the radar timeline and preserve the original reference timestamps so another researcher can audit the alignment.

Define each label operationally. For “sit down,” one protocol might mark onset at the first sustained descent from standing and offset when the person reaches a stable seated posture. State how annotators handle hesitation, a partial sit, an obstructed view and an unclear boundary. Keep “sitting” distinct from “sitting down” if the vocabulary includes both states and transitions.

Use a shared annotation manual, review a subset independently, and report the review subset, disagreements and resolution process. A second annotator helps expose ambiguous definitions. Agreement on class labels does not, by itself, establish accurate event boundaries.

Check offset, drift and timestamp meaning

Prefer a shared hardware timing reference or a supported trigger arrangement when the devices allow it. Otherwise, preserve both sensor and host timestamps and establish a mapping between clocks. Check alignment near the beginning and end, with intermediate checks for long sessions. Refit or segment the mapping after a clock reset.

A common host does not automatically make sensor exposure, radar acquisition and packet arrival simultaneous. Record what each timestamp represents. Where hardware markers are unavailable, use a deliberately visible movement in the reference and radar streams, then quantify how uncertain that event matching remains.

MM-Fi provides a useful reporting example: it stores timestamped sensor streams, selects nearby frames on a common 10 Hz timeline, and reports a 25 ms synchronization bound based on its sampling setup. That reported matching bound should not become a universal tolerance for another system; timestamp semantics and acquisition latency still need investigation. [5]

For an original illustrative calculation, suppose the initial clock offset is 40 ms and relative clock-rate error is 100 parts per million. Ten minutes adds 60 ms of drift. Correcting only the initial offset therefore leaves 60 ms at the end—more than one 50 ms frame interval at 20 frames/s. These assumed values explain the mechanism; they are not measurements or typical specifications for a particular sensor.

An illustrative clock-error plot shows 40 ms initial offset plus 100 ppm drift reaching 100 ms after ten minutes; correcting the initial offset still leaves 60 ms of drift. — Figure 2. Original illustrative clock calculation with a 40 ms initial offset and 100 ppm relative rate error. Correcting the initial offset leaves 60 ms of drift after ten minutes. The dashed 50 ms line represents one frame at 20 frames/s and is not a universal timing acceptance limit.

Choose acceptable timing uncertainty from the event timescale. A short gesture boundary can be more sensitive to a given offset than a long posture interval. Report residual alignment error using check events beyond those used to fit the mapping, and distinguish that error from human uncertainty about when the action begins.

Keep background, transitions and uncertainty visible

Record no-person scenes, quiet occupied scenes, entry and exit, transitions, unrelated motion and activities outside the target vocabulary when they belong to the intended use. “No person,” “person motionless” and “unknown action” mean different things. Preserve that distinction in the annotation scheme.

For each derived window, declare whether you use its center label, majority overlap, multiple labels or a required class-purity threshold. Retain boundary uncertainty and transition intervals even if a clean-clip baseline excludes them. Those exclusions define the baseline’s task; they do not solve continuous recognition.

A camera or pose estimator can help provide labels without becoming an inference input. If the claimed system uses radar alone, keep reference features out of the classifier. Disclose any reference-assisted temporal cropping or spatial gating: manual or camera-derived gates that deployment cannot obtain can make an evaluation substantially easier.

7. Lock independent groups before making windows

Assign the original recordings to training, validation and test groups using the boundary in Table 1. Generate windows separately within those groups. Every crop, spectrogram, augmentation, synchronized sensor view and alternative representation from one parent event must inherit its assignment.

Two-second windows with a 0.2-second step share 1.8 seconds, or 90% of their temporal samples. Randomly placing adjacent windows in training and test sets can therefore share the same physical motion across both. More windows increase the number of training examples; they do not create more independent people or events.

Work by Dehghani examined overlapping windows and evaluation choices in inertial-sensor HAR. It supports caution about apparent gains under dependent evaluation; it does not establish a universal performance effect for radar. Here, the direct radar concern is whether the same parent signal crosses the evaluation boundary. [6]

Check exclusivity at every level named in the claim. A unique recording ID does not prevent one participant’s other session from entering training. A participant–room pair used as a single group does not guarantee that both participants and rooms are individually disjoint.

Scikit-learn’s StratifiedGroupKFold keeps supplied groups non-overlapping while attempting class balance. It cannot infer the correct scientific grouping, and uneven groups can prevent close stratification. Inspect the final subject, room and class counts after splitting. [7]

Fit learned normalization, imputation, feature selection and dimensionality reduction on training data within each fold. Use development validation for window length, filtering choices and decision thresholds. A processing pipeline helps enforce the training-only fitting rule, as the scikit-learn leakage guidance explains. [8]

Apply fixed, predeclared capture-integrity checks consistently, including to held-out recordings. Avoid selecting thresholds or exclusions because they improve final test scores. Freeze the complete processing and evaluation procedure before running the final test.

Group independence does not remove confounding

Return to the corridor-and-desk example. Holding out people prevents participant overlap, but the same activity–room relationship still exists. Leakage control protects the evaluation boundary; collection design determines what explanation the evidence can support. You need both.

8. Work through a realistic collection plan

Consider an illustrative planning example for single-person recognition across new users in two familiar rooms. Recruit 12 participants, record every participant in both rooms, and run two sessions on different days for each participant–room pair. Include six activities—walking, sitting down, standing up, picking up an object, drinking and waving—with five trials per activity in each session.

12 participants × 2 rooms × 2 sessions
× 6 activities × 5 trials = 1,440 planned trials

At 8 seconds recorded per trial:
1,440 × 8 = 11,520 seconds = 3.2 hours

At the illustrative ADC payload rate above:
3.2 hours ≈ 120.80 GB = 112.5 GiB

The eight seconds describes the recorded trial, including any lead-in and lead-out; label the actual activity interval separately. The 3.2 hours excludes setup, instructions, rest, calibration, repeats, transfer checks and any extra continuous sequences. It is signal time, not the staffing or appointment budget.

One possible development split assigns eight people to training, two to validation and two to the final test, with both rooms and all sessions following each person. That produces 960, 240 and 240 planned trials respectively. It tests new people within the two recorded rooms; it does not test a previously unseen room.

Twelve participants and two test people are planning assumptions, not evidence of adequate statistical power. Two people can yield a fragile estimate of population performance. Use pilot variability and the precision required by the claim to set recruitment, and consider participant-grouped cross-validation for development when data is limited.

If new-room transfer is the main claim, redesign the plan to reserve a final room and provide independent development conditions. With only two rooms, using one repeatedly for tuning and then presenting it as an untouched new-room test would defeat the purpose. More recordings of the same two people cannot fix missing environment diversity.

Spend additional collection time on the factor that limits the claim. New participants expand person coverage; new sessions test repeatability; new rooms expand environment coverage; repeated trials help estimate within-condition variability. None of these units is interchangeable with a sliding-window count.

9. Preserve a manifest that explains every result

Create a machine-readable manifest during acquisition. Give each original capture an immutable ID, then connect every derived file to that parent. Use separate identifiers for a recording, participant, session, room, device, configuration and protocol version.

At minimum, retain the raw path and checksum; capture start and duration; expected and received frame counts; sensor and host time references; radar pose and geometry ID; annotation source and version; validity information; quality-control decision and reason; and evaluation assignment. Keep the session identifier unique enough to prevent one person’s “session 1” from merging with another’s.

Store annotations as intervals with explicit units and conventions. For example, use seconds from the recording’s first radar timestamp and intervals that include their start but exclude their end. Preserve labels such as transition and uncertain, and record boundary uncertainty rather than silently converting an approximate manual label into an exact timestamp.

Represent unknown measurements as unknown. A blank packet-loss measurement must not become a zero-loss claim. Keep a separate planned-trial ledger so skipped, failed and repeated trials remain visible; otherwise, a final folder of accepted files can hide systematic collection failures.

Record enough information to reconstruct the processing path without copying participant identities into the research files. Keep the identity lookup and consent records separately under the appropriate access controls. Publish aggregate participant information only at the level justified by the research and consent.

10. Test the collection’s weak points before release

Use development data to look for suspiciously easy explanations. Try a metadata-only diagnostic using room, session or recording-order information; inspect predictions by geometry; and test whether performance collapses when a familiar shortcut changes. Strong metadata-only prediction is a reason to investigate confounding, although class imbalance and a small sample can also affect that diagnostic.

Then evaluate in the form the application will receive. For continuous recognition, specify event matching, minimum event duration, merging of repeated alarms and decision latency. Report event precision and recall, missed events, false alarms per hour and the amount of evaluated background time. Counting every positive frame as a separate alarm would measure a different quantity.

Keep challenging valid conditions visible: a quiet person, a partial action, a weak side view, an ordinary moving distractor, or a second person if multiple occupancy belongs to the claim. A single-person scripted collection cannot establish multi-person performance merely because the radar reports multiple points.

Radar also does not automatically make data anonymous. MiliPoint includes a person-identification task alongside action recognition and pose estimation, illustrating that point-cloud data can retain identity-related information. Arrange the relevant ethics review and consent process before recruitment, explain reference-sensor use and sharing, and avoid collecting unnecessary personal data. [9]

If the study includes staged falls or vulnerable participants, use an appropriately reviewed safety protocol and qualified supervision. Do not improvise risky actions to fill a missing class. Describe staged events accurately and keep claims about real-world events within the evidence collected.

Release documentation with the data, rather than writing it from memory months later. The Datasheets for Datasets framework organizes the questions around motivation, composition, collection, processing, intended uses, distribution and maintenance. Adapt those headings to radar-specific timing, configuration and exclusion details. [10]

Provide split files, label definitions, decoding instructions, units, dependency versions, a minimal baseline, known limitations and clear reuse terms. Report participant, session, room, trial and duration counts before listing derived windows. If you publish uncertainty intervals, respect the independent grouping—for example, resample participants for a participant-level claim when the sample supports it, rather than treating overlapping windows as independent observations.

radar-har-collection-starter-kit Download the Radar-HAR collection starter kit.

A final checklist before the main collection

Write one precise deployment claim and choose the corresponding held-out groups.
Check activity coverage across people, rooms, sessions and required geometries.
Save and verify the exact sensor configuration, decoder and timing setup.
Run the full acquisition-to-label workflow and resolve pilot failures.
Define integrity checks, exclusions, uncertain labels and replacement rules in advance.
Prepare the manifest, backups, annotation manual and participant procedures.
Reserve development and final evaluation groups before producing windows.

The strongest Radar-HAR dataset lets another researcher trace a prediction back to a physical event, an acquisition configuration, an annotation decision and an independent evaluation group. Build that traceability into collection, and the resulting model scores will be much easier to interpret.

How to Collect a Radar-HAR Dataset Without Ruining the Experiment