Step and Cadence Analysis"

In GGIR: Raw Accelerometer Data Analysis

GGIR does not have a build-in step detection algorithm, but does facilitate the embedding of an external function for event detection such as steps. Such algorithms typically count steps per epoch, where an epoch is usually a 5 second or larger time interval. Steps and cadence per epoch alone is not of direct value for research. Therefore, GGIR facilitates the extraction of summary statistics, which will be discussed below.

Verisense algorithm

The only external algorithm for step detection currently available for GGIR is the Verisense algorithm, which was design for data collected on the wrist. The algorithm has been described and evaluated in studies by Maylor 2022 and Rowlands 2022.

The original Verisense algortihm code is not actively maintained at the time of writing this documentation. An improved copy of the Verisense algortihms code with minor bug fixes is part of the GGIR GitHub repository.

How to use the Verisense algorithm?

To use the algorithm, copy-paste the following code to the top of your R script and update the file path in the first line to the Verisense function file on your computer. A discussion of this code will follow further down.

source("C:/path_to_file/verisense_count_steps.R")
myfun = list(FUN = verisense_count_steps,
             parameters = c(4, 4, 20, -1.0, 4, 4, 0.01, 1.25),
             expected_sample_rate = 15,
             expected_unit = "g",
             colnames = "step_count",
             outputres = 1,
             minlength = 1,
             outputtype = "numeric",
             aggfunction = sum, # aggregate step by taking sum
             timestamp = FALSE,
             reporttype = "event",
             ilevels = c(0, 100, 250), # acceleration levels to be used
             clevels = c(0, 80, 100, 120), # cadence levels to be used
             qlevels = c(0.5, 0.9), # quantiles to be used
             ebout.dur = c(1, 5, 10), # event bout duration to extract
             ebout.th.cad = 30, # event bout threshold for cadence
             ebout.th.acc = 50, # event bout threshold for acceleration
             ebout.criter = 0.8, # event bout criteria (same as boutcriter)
             ebout.condition = "AND") # event bout logic (see below)

Note the that parameters = c(4, 4, 20, -1.0, 4, 4, 0.01, 1.25) is based on Rowlands et al. "Stepping up with GGIR" from 2022.

Next, use GGIR as you normally do, but include myfun = myfun as input argument. If we would rely on all GGIR default parameter values and segments days in 6 equal parts then this would look as follows:

GGIR(myfun = myfun,
     outputdir = "C:/myresults",
     datadir = "C:/mydata",
     qwindow = c(0, 4, 8, 12, 16, 20, 24))

Time resolution for deriving statistics

Per day or groups of days

All step and cadence statistics are derived as summary per recording day and per recording as a whole, and stored in results/part2_dayeventsummary.csv and results/part2_eventsummary.csv, respectively. The column name extensions AD_, WD_, WE_, WWD_, and WWE_ inside the file part2_eventsummary.csv have the same meaning as elsewhere in the GGIR part2 output, e.g. AD means aggregation across all recording days.

Per day segment

When you use GGIR's day segment analysis functionality the statistics are also derived per time segment within a day. The time segment for which each statistic is derived is clarified in the ending of a column name as _startHour-endHourhr. For example, _0-14hr indicates that it was extracted from data between midnight and 14:00.

Step count and cadence summary statistics

Total step count is stored with tot_step_count in the column name. Cadence is derived in the unit 'steps per minute', even if the epoch size for step detection is not 1 minute. Cadence is abbreviated as cad in the column name. Mean cadence is indicated as mn_cad.

Note that Chapter 6 discusses how acceleration metrics are imputed based on a mean of valid time points on other days of the recording. For steps and cadence this would be problematic as the average between walking and non-walking is not informative. Therefore, imputation of steps is done by the median instead and by that represents typical stepping behaviour at that time of the day.

Stratified by acceleration and/or cadence level

Per acceleration level

As discussed in Chapter 7 accelerometer data can be described in terms of acceleration levels. As such, we can also describe step count and cadence per acceleration level.

To control this aspect, include in your myfun object the item ilevels as a numeric vector with the acceleration values to define the acceleration levels, e.g. ilevels= c(0, 50).

Output:

• Mean cadence for the acceleration range 0-50 m_g_ when working with acceleration metric ENMO will be stored with column name mn_cad_acc0-50mg_ENMO. Note: The step bout detection functionality automatically uses the acceleration metrics specified by the user. So, if you want to try it out with both ENMO, ENMOa, and MAD metric then that should work.

• Total step count for the acceleration range 0-50m_g_ when working with acceleration metric ENMO will be stored with column name tot_step_count_acc0-50mg_ENMO. Here step_count is the value as provided via myfun parameter colnames.

Per cadence level with absolute thresholds

Similarly, we can also describe the data based on cadence level and use absolute cadence thresholds.

To control this aspect, include in your myfun object item clevels as a numeric vector with the cadence values that define the cadence levels, e.g. clevels = c(0, 30, 120).

Output:

• Total step count for the cadence range 0-30spm will be stored with column name tot_step_count_cad0-30spm.
• Time spent in the cadence range 0-30spm will be stored with column name dur_cad0-30spm.
• Mean acceleration in the cadence range 0-30spm will be stored with column name mn_ENMO_cad0-30spm

Per cadence level with relative thresholds

Instead of setting absolute thresholds to define cadence levels we can use percentiles.

To control this aspect, include in your myfun object the item qlevels as a numeric vector with fractions of 1 to define the quantiles, e.g. qlevels = c(0.5, 0.9).

Output:

• Cadence value for the 50th percentile of the cadence distribution, e.g. cad_p50 for qlevels = 0.5 and cad_p90 for qlevels = 0.9.

Per most and least active consecutive cadence time window

The same statistics can also be derived from the consecutive X hours with the least and most cadence per (segment of a) day.

To control this aspect, include in your myfun object the item winhr, e.g. winhr = c(5, 10) which works the same as winhr in GGIR itself.

Output:

• The X hour window with the least amount of cadence will be stored with column name LX_cad_, e.g. L10_cad_.
• The X hour window with the most amount of cadence will be stored with column name MX_cad_, e.g. M5_cad_.

This is then followed by:

• mean_Y where Y reflects the metrics being average, which can be acceleration metrics, step count per epoch or the mean cadence. For example, "L10_cad_mean_ENMO_mg_0-24hr", "L10_cad_mean_step_count_mg_0-24hr", "L10_cad_meancad_0-24hr".
• L10hr_ indicates the timing of the 10 hours with the least cadence.

Walking bouts

Similar to the detection of physical activity bouts as discussed in Chapter 11 we can detect bouts of stepping behaviour. In GGIR we define these based on duration, minimum cadence AND/OR minimum acceleration and the fraction of the bout for which these criteria need to be met.

The step bout detection functionality automatically uses all acceleration metrics specified by the user. So, if you want to try it out with both ENMO, ENMOa, and MAD metric then that should work.

To control the criteria for bout detection, include in your myfun object the items:

• ebout.dur a numeric vector of length 1 or larger with the minimum bout duration(s) of interest, e.g. ebout.dur = c(1, 5, 10).
• ebout.th.cad a single number being the minimum cadence value in steps per minute, e.g. ebout.th.cad = 30.
• ebout.th.acc a single number being the minimum acceleration value in steps per minute, e.g. ebout.th.acc = 50.
• ebout.criter a single number as a fraction of 1 being the faction of a bout for which the inclusion criteria need to be met identical to boutcriter in the context of physical activity bouts, e.g. ebout.criter = 0.8.
• ebout.condition whether cadence and acceleration condition are both required (ebout.condition = "AND") or either of the conditions is required (ebout.condition = "OR"). If both cadence and acc need to meet a thresholds then fill in "AND". If it also acceptable if only one of the thresholds is met then fill in "OR". If you do not want cadence or acceleration to be used in the equation then simply set ebout.th.cad = 0 or ebout.th.acc = 0.

Output:

Columns names related to detected bouts start with the word Bout_, e.g. "Bout_meandur_E5S_B10M80%_cadT30_AND_accT50_ENMO", "Bout_number_E5S_B5M80%_cadT30_AND_accT50_ENMO" and "Bout_totdur_E5S_B5M80%_cadT30_AND_accT50_ENMO".

• Average bout duration is indicated with Bout_meandur_ in the column name.
• The total duration is indicated with Bout_totdur_ in the column name.
• The number of bouts is indicated with Bout_number_ in the column name.
• Underlying epoch size is indicated with E5S in the column name where 5S refers to a 5sec epochs.
• Minimum bout duration is indicated with B10M in the column name where 10M would refer to a 10 minutes.
• The minimum fraction for which the bout conditions need to be met is indicated as a percentage in the column name, e.g. 80%.
• The minimum cadence and acceleration values are presented in the column name as cadT30 and accT50_ENMO when using a 30 and 50 thresholds, respectively.
• The setting of parameter ebout.condition is directly copied into the variable name as AND or OR.

GGIR documentation built on Jan. 27, 2026, 5:06 p.m.