Skeptical about result in sleep duration

[Marga Decraene]

Dear all,

I am skeptical about my sleep duration result. I tried two algorithms for sleep duration, and both give a result that I don't fully trust. Only a very large minimum of my participants would adhere to the sleep guideline. However, according to their diaries, participants spend much longer in bed than the sleep guideline. When I analyze the actigraphs via Actilife using the same algorithm that I run in GGIR, the difference is very significant. It is about 1,5 to 2 hours difference. Many participants meet the guideline via Actilife.

I wonder why this might be. I wouldn't expect such a large difference between Actiflife and GGIR when the same algorithm is used.

Does anyone have any idea what could be the reason?

The script I'm using is as follows: getwd()
setwd("D:/GGIR")
getwd()
dir()

library(GGIR)
library(tidyverse)
library(read.gt3x)
library(actilifecounts)

  g.shell.GGIR(
    mode=c(1,2,3,4,5),
    datadir="D:/GGIR/Input",
    outputdir="D:/GGIR/Output",
    overwrite = TRUE,
    do.parallel = TRUE,
    desiredtz="Europe/Brussels",
    do.report=c(1,2,3,4,5),
 
 
  #=====================
  # Part 1
  #=====================
  #f0 = 1, f1 = 5,
  idloc=6,
  windowsizes = c(15, 900, 3600),
  dynrange = 8,
  do.enmo = FALSE,
  #acc.metric = "ENMO",
  #do.mad=TRUE,
  #acc.metric="MAD",
  do.neishabouricounts = TRUE,
  acc.metric="NeishabouriCount_y",


  #=====================
  # Part 2  
  #=====================
  strategy = 1,
  hrs.del.start = 10,          hrs.del.end = 0,
  includedaycrit = 16,
  qwindow=c(0,24),
  mvpathreshold =420,
  bout.metric = 6,
  #excludefirstlast = FALSE,
  iglevels=TRUE,
 


  #=====================
  # Part 3 + 4
  #=====================
  #outliers.only = FALSE,
  do.visual = TRUE,
  loglocation="D:/GGIR/Input/Sleeplogv2.csv",
  sleeplogidnum = FALSE,
  colid = 1,
  coln1 = 3,
 
 
 HASIB.algo="Sadeh1994",
 Sadeh_axis="Y",
 sensor.location="hip",
 HASPT.algo="HorAngle",
 longitudinal_axis=2,
 timethreshold=(5),
 anglethreshold=5,
 ignorenonwear=TRUE,
 excludefirst.part4=TRUE,
 def.noc.sleep=1,
 do.sibreport=TRUE,
 possible_nap_edge_acc=Inf,
 possible_nap_dur = c(15, 240),
  #=====================
  # Part 5
  #=====================
  threshold.lig = 26, threshold.mod = 420, threshold.vig = 842,
  boutcriter = 0.8,      boutcriter.in = 0.9,     boutcriter.lig = 0.8,
  boutcriter.mvpa = 0.8, boutdur.in = c(1,10,30), boutdur.lig = c(1,10),
  boutdur.mvpa = c(1),
  includedaycrit.part5 = 2/3,
  #=====================
  # Visual report
  #=====================
  timewindow = c("WW",),
  visualreport=TRUE,
  week_weekend_aggregate.part5 = TRUE)

[Vincent van Hees]

Dear Marga,

Very good that you are sceptical, everyone should be sceptical about these implementations. I discussed this in the vignette https://cran.r-project.org/web/packages/GGIR/vignettes/GGIR.html#561_Notes_on_sleep_classification_algorithms_designed_for_count_data

There are essentially multiple challenges:

1. Motionlogger Counts: Sadeh and Cole-Kripke used the Motionlogger but they as well as the manufacturer provided no complete transparency about how these counts are calculated. Note that their calculation cannot be the same as the ActiGraph counts used by ActiLife, because they reported to use a zero-crossing counts while ActiGraph count use an area under the curve algorithm. The problem however is that manufacturers like ActiGraph, Actiwatch and many others wanted to benefit from the popularity of the Sadeh and Cole-Kripke algorithm but in order to implement them they had to make some adjustments to their own count values in order to make the algorithm work. Those adjustments are proprietary and have to my knowledge never been shared. As a result, in open source software such as GGIR we have no other choice then to guess how to derive counts with modern data in a way that mimics the counts as used by Sadeh and Cole-kripke in the 1990s.
2. Orientation of axis: Sadeh reported to use the y-axis without documenting what direction the y-axis points in.
3. Algorithm itself: Although the algorithm was published, it is not clear whether ActiGraph, Actiwatch and other companies use the exact same algorithm or a slightly revised version of it to improve performance. Without transparency on their side this is hard to verify.
4. Lack of commitment by sleep research community in the past 30 years to demand transparency from software providers. I have tried to make an educated guess in GGIR based on the information I could find to see how far that would bring us. Further, I did it to educate the research community that claiming to use 1990s algorithms is just a marketing trick by the wearable sensor companies and a completely meaningless way to do science on modern data as it is not transparent.

I welcome efforts to help improve GGIR's implementation of the zero-crossing count and Sadeh and Cole-Kripke algorithms.

Kind regards,

Vincent

--
You received this message because you are subscribed to the Google Groups "R package GGIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to RpackageGGIR...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/b55d4c3a-fa94-48ba-b6d4-626c985eae23n%40googlegroups.com.

[Abdul Haleem Butt]

Dear Vincent,

I really appreciated your comprehensive answer about these differences. I have also observed an issue while comparing the Sadeh algorithm with and without ActiLife count when using GGIR. Additionally, I have noticed suspicious results from the Sadeh algorithm developed in GGIR. In my case, the Sadeh algorithm in time series detected sleep inactivity bouts (SIB) throughout reported sleep period time in the diary. These results occurred with 10 out of 12 subjects we recorded with Axivity Ax6. Do you think it's by chance or is there some other reason? Since the results are a bit suspicious, I would really appreciate your guidance in this regard.

Kind regards,

Abdul Haleem

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/ApVSxzg07Jz00T1a-ofYFf5XsHQg2S5_FsVZC-LqeCB_CYm4wY1CbtyGVkTye9dz2VPcNS37lF4wj9Aji9hUJpoQ4NzdYTlUGpw1ArerAbs%3D%40accelting.com.

[Vincent van Hees]

Dear Abdul,

I am not sure it is fair to expect from me to provide guidance on this. It is the sleep research community who has been using these methods for decades without ensuring a reproducible description. So, it is the sleep research community that needs to answer these questions.

GGIR is open source research software, which means that I implement a lot of methods as good as I can, even methods that are more experimental or for which it is not entirely clear how the original developer intended them to be implemented. It is not fair to expect from me to take responsibility for the fact that others are not transparent in their work. I have been doing my best to provide value, and I have been trying to encourage researchers that have used these methods to help improve them, but that is all I can do. 

Thanks,

Vincent

Dr. Vincent van Hees | Independent consultant | https://accelting.com/