Cut-off points Neishabouri

112 views
Skip to first unread message

Iris Willems

unread,
Aug 22, 2023, 6:02:04 AM8/22/23
to R package GGIR
Screenshot1_cutpoints Troiano.pngScreenshot2_adjusted cut-points Troiano.pngDear Vincent en Jairo,

I am contacting you as a follow-up of our last videocall addressing different ways to analyze actigraph data. In this session we discussed the use of Neishabouri acceleromter metric.

#part 1
...
#part 2
.....
do.enmo= FALSE,
do.neishabouricounts = TRUE,
acc.metric = "NeishabouriCount_y",

#part 3-4
....

#part 5
....
threshold.lig = c(101), threshold.mod = c(2020),  threshold.vig = c(5998),
....

These cut-points are the cut-points of Troiano et al. As we discussed in the session, there was no need to adjust these cut-points. However, I am not sure if this is correct as I get low LPA estimates as well as no output for MPA and VPA (see screenshot1).

Shouldn't we adjust for epoch lenght and frequency? My data is collected on 60 s epoch and at 100 hz. Troiano validated the cut-points on 60 s epoch at10 hz. So I think, for my data, I need to devided the cut-off points by 10 to adjust for the difference in frequency. 
This generated more 'normal' results (see screenshot2).

What do you think? 

Thank you!

Kind regards,

Iris Willems

Iris Willems

unread,
Aug 23, 2023, 9:05:53 AM8/23/23
to R package GGIR
Dear,

I found the in the preparation of the new release already some extra information about the Neishabouri metric.

The cut-points you find in the literature for ActiGraph counts cannot be applied
to Neishabouri counts directly because both are epoch length specific. The cut-points
from the literature need to be corrected by a conversion factor. The conversion
factor is calculated as the epoch length in the new study (e.g. 5 seconds) divided
by the epoch length in the original study (e.g. 60 seconds). Note that no correction
for differences in sampling rate is needed because Neishabouri counts already account
for this via down-sampling.


However, I collected my actigraph data at 100 hz and 60 sec epoch. So applying this to my data I would get:
             Troaino cut-points for LPA is 100 cpm --> conversion 100* (60s of my own data/ 60s of the study of Troiano)
But this does not make sense as this does not change the cut-off points to use in GGIR. In my previous message you can see in screenshot1 that using counts per minute with conversion, does not seem correct (no MPA and VPA).

Maybe as GGIR works with 5 sec epochs, I still need to convert 100* (5s GGIR epoch/60s of the study of Troiano) despite setting the argument part5_agg2_60seconds =TRUE.

So I am not quiet sure if this the right way to intrepret the conversion you describe above.

Thank you!
Iris Willems

Op dinsdag 22 augustus 2023 om 12:02:04 UTC+2 schreef Iris Willems:

Vincent van Hees

unread,
Aug 29, 2023, 11:04:42 AM8/29/23
to Iris Willems, R package GGIR
Hi Iris,

If you have argument part5_agg2_60seconds = TRUE then part 5 will work with 60 second epochs and no threshold conversion should be needed.

If you have argument part5_agg2_60seconds = FALSE then part 5 will work with 5 second epochs (at least by default) by which you will have to divide your threshold by 12 (5/12). This would be close to the division by 10 that you considered more plausible.

Note that zero time in MOD or VIG is plausible and I would not consider that on its own as a guiding a final decision for thresholds. Ideally we should be able to theoretically justify the selection of the threshold. The sample frequency is accounted for in the calculation of the counts (10 Hertz) in package actilifecounts (written by Jairo), so I think it would be hard to justify accounting for that twice.

Best,

Vincent

------- Original Message -------
--
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/436ffdaf-8229-4a2c-b350-6a5816cd22f5n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages