Hard-coded assumption about dynamic range of Axivity sensor when doing clipping detection.

[vincentvanhees]

For most sensor brands that GGIR facilitates an assumption is made about the dynamic range of the sensor when testing for signal clipping: If more than 80% of a 15 minute window is near the dynamic range then the window is labelled as clipping and flagged for imputation. For GENEActiv, AX3, AX6, and Actigraph this threshold is set at 7.5 g .

If the dynamic range is actually less than this threshold then clipping detection will not work. It is less concerning if the dynamic range is higher because accelerating with 7.5 for 80% of the time is likely to be non human, regardless of sensor attachment location.

Nonetheless, it would be neater if GGIR could attempt to replace the hard-coded dynamic range assumptions by actual values, if available.

[xiangnandang]

@vincentvanhees , forgive my lack of understanding of some aspect in the current implementation, specifically around when a clipping happened for a portion of the data, what type of warning/messaging does end user receive in console/stdout, and does result (guessing from part 1) include the information that certain period data was imputed specifically due to clipping?

[vincentvanhees]

In variable clipping_score in the output from part 2. On a side note - I am in the process of migrating all descriptions of output variables to the vignette, because these are currently half in vignette and half in more technical function documentation (the GGIR.pdf file).

[vincentvanhees]

Now reflecting on whether this issue can be closed:

• For GENEActiv the dynamic range is constant
• For ActiGraph the dynamic range of their main device models is automatically account for by GGIR.
• For custom accelerometer formats the dynamic range is accounted for (see GGIR function read.myacc.csv)
• For Axivity dynamic range is extracted but not accounted for I believe....

So, I guess this issue can be specific to Axivity data only. I will update the title.