ENMO treated in GGIR

[rglenn...@gmail.com]

Based on the attached papers it seems that ENMO is averaged over 5seconds. Is that how GGIR treats ENMO when producing estimates of activity intensity (inactive, sedentary, light, moderate, vigorous)?

[ben_m...@hotmail.com]

Hi Glenn, ENMO is typically averaged over 5 second bins, so it's common to read this in the literature. GGIR does make it customisable by changing the arguments in windowsizes. for example I have used 1s and 60s epochs for various reasons such as investigating short duration movements or aligning it with other data which was saved at a different epoch.

Kind regards,

Ben

[Alex Li]

Hi all,

Thanks for your sharing experience about the ENMO. One question from my group:

Since GGIR can read directly the raw dataset such as .gt3x, how could GGIR interpret the exact timestamp of rows from raw data? We could find the start date and epoch period from header of raw data, and have tested starting with the timestamp = "2021-06-15T17:00:00+1000" for the first row after converting from raw dataset in R and only the first three columns with x,y,z values in gravity, but the manual calculation (30 samples in one second) by Excel was not the same as GGIR result (aggregate to 1s epoch), the blue line. So we doubt the first timestamp was not the time from header, but some time later as a full epoch. Could you help us how to find the timestamps for sensor records in GGIR?

Thank you very much.

Regards

Alex

[Vincent van Hees]

Hi Alex,

GGIR intentionally starts at an integer number of large epochs (default length is 15 minutes) relative to the hour to ease interpretation and comparison of results across recordings and to ensure that epochs never span two different calendar dates. So, if your recording was started at 8:54:00 then you will see GGIR time series output from 9:00:00 onward. The first short (5 second) epoch will be from 9:00:00 and 9:00:05.

read.gt3x is a package that helps you read in the file directly but leaves it up to you to take care of all the data processing and alignment to compare individuals. This is where the value of GGIR comes in.

GGIR is designed for processing multi-day accelerometer data and because of that I think ignoring a few minutes at the beginning and end is justifiable.

Kind regards,

Vincent

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

------- 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/617b0933-6046-4f9b-9437-c598be0298c0n%40googlegroups.com.

[Alex Li]

Hi Vincent,

Thanks for your prompt reply and explain the advantage of GGIR in ENMO. I also noticed that the ENMO 'values presented is the average ENMO over all the available data normalised per 24 hour cycles, with invalid data imputed by the average at similar timepoints on different days of the week', from which I understand GGIR automatically imputed invalid data if there is a time gap from sensor values, and smooth ENMO results than other function. 

Two questions further: 

1. Are ENMO results affected by different window size and cut points for LPA and MVPA? 

We tested ENMO and angles results with the same participant, by three scenarios of window size and cut points for elder people(case 0 as the benchmark). Please check the attached files of summary results from R. 

case_0: using (1,600,900), mvpathreshold =c(60), threshold.lig = c(18), threshold.mod = c(60),  

case_1: using (1,900,900) instead, keep other params the same

case_2: keeping window size as (1,600,900), tuning mvpathreshold =c(14), threshold.lig = c(7), threshold.mod = c(14)

I thought the ENMO calculation should be independent at the beginning of GGIR shell sections, reflecting the fact how participant moved, and not changed according to window size (the 2nd and 3rd size) and cut points which would be focused on sleep detection. But slight mismatch popped up. 

2. Are there any updates for angle calculation? 

We noticed there are two equations from GGIR pdf document (pp. 82) <https://cran.r-project.org/web/packages/GGIR/GGIR.pdf> and g.applymetrics function, line 140-150 <GGIR/g.applymetrics.R at master · wadpac/GGIR · GitHub> . 

Could you please let us know more about the above two questions?

Many thanks.

Regards,

Alex

[Vincent van Hees]

1. The larger windows affect non-wear detection and imputation. This will affect which ENMO values are imputed and as a result the distribution of the resulting ENMO values.
2. The code is right, this is a mistake in the documentation.

Vincent

------- Original Message -------

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/099d9d9c-7aad-4479-8b99-85c20d974eaen%40googlegroups.com.