Error in verisense_count_steps with default parameters — 'length = 5' in coercion to 'logical(1)'

[ricardo-martinss]

Dear GGIR maintainers,

I'm encountering an error when running the verisense_count_steps step-counting algorithm with its default settings, built via build_GGIR_verisense_functions ("verisense_count_steps"). The function fails during execution with:

Error in length(peak_info) == 0 || length(peak_info) == sum(is.na(peak_info)) :
'length = 5' in coercion to 'logical(1)'
Called from: myfun$FUN(resampleAcc(data, sf, myfun) * unitcorrection, myfun$parameters)

This suggests that peak_info is a list/vector of length 5 (rather than length 0 or 1) at the point where the internal || check occurs inside verisense_count_steps, which breaks the length-1 logical coercion required by ||. It looks like an internal bug in the peak-detection logic of verisense_count_steps rather than an issue with my input data, since it happens with default parameters.

Session info:
R version: 4.6.1 (2026-06-24 ucrt), Windows 11 x64
GGIR version: 3.3-8
myfun$parameters: c(4, 4, 20, -1, 4, 4, 0.01, 1.25) (defaults)
myfun$expected_sample_rate: 15

Could you let me know if this is a known issue, and whether there's a workaround or fix planned? Happy to provide a reproducible example or test data if useful.

Thank you for your time and for maintaining this package.

Best regards,
Ricardo Martins.

[vincentvanhees]

Please note that Verisense has not been maintaining their repository, so if you follow their instructions it may indeed not work.

Did you follow our instructions: https://cran.r-project.org/web/packages/GGIR/vignettes/StepCadenceAnalysis.html
where we refer to an improved version of the code: https://github.com/wadpac/GGIR/blob/main/user-scripts/verisense_count_steps.R
and the latest published parameters of the algorithm?

If the problem persists, please report:

• Sampling rate
• Accelerometer brand
• Data format

[ricardo-martinss]

Dear Dr. Vicent,

Thank you very much for your response and for taking the time to look into this issue.

To confirm, I did use the updated code from the GGIR user-scripts repository (verisense_count_steps.R) and followed the instructions provided in the vignette, including the latest published parameters of the algorithm. Unfortunately, the error persisted despite following these steps correctly.

As requested, here are the details of my setup:
Sampling rate: 60Hz
Accelerometer brand: ActiGraph (wrist-worn)
Data format: GT3X

I'd also like to add one additional detail that may be relevant for troubleshooting: when I ran the exact same code on an older version of R (4.2.3), it worked without any issues and did not produce the error I reported. This suggests the problem may be related to compatibility with a more recent R version rather than the code or parameters themselves.

I really appreciate your help and the time you've dedicated to this.

Best,

[vincentvanhees]

A common mistake is that people fill in expected_sample_rate = 60, but it should remain 15. The 15 refers to what the algorithm expects, not the sample rate of your own data.

If that does not resolve the issue. Please send me your R script and an example file to allow me to reproduce the error (via email is ok for this).

[vincentvanhees]

Update: After correspondence via email we discovered that the issue was that Ricardo had the following at the top of his R script.

library(bitops)
library(covr)
library(testthat)
library(knitr)
library(rmarkdown)
library(data.table)
library(Rcpp)
library(foreach)
library(doParallel)
library(signal)
library(zoo)
library(matlab)
library(GENEAread)
library(tuneR)
library(unisensR)
library(ineq)
library(stats)
library(utils)
library(plotly)
library(ggplot2)

GGIR package dependencies should never be loaded as such in an R script, GGIR loads any relevant dependencies itself.
Removing this from the script fixed the issue.

Also some of the libraries listed are only relevant for development of GGIR and not needed for using GGIR:

library(covr)
library(testthat)
library(knitr)
library(rmarkdown)

and do not have to be installed.

[vincentvanhees]

I am closing this