IMU data from read_gt3x and Actilife sometimes differ at the 6 decimal place

[dht7166]

We have been using the AGread package to read IMU data from GT3X files. However, we notice that their are places where the values converted from this package differs from Actilife, usually at the 6 decimal places. While this is not a big error, we would like to know what is the source of this issue, and whether someone could potentially fix it.

An example file in our study (GT3X, IMU from Actilife, and corresponding file from AGRead) is attached here . Please note that the IMU data is written to csv just with write.csv(data[["IMU"]], outname).

[paulhibbing]

I suspect this is an artifact related to some aspect of computing precision, likely floating point operations or conversions (akin to this thread). AGread uses R and C++, whereas I believe ActiLife uses C#.

With the legacy parser in AGread::read_gt3x, I went out of my way to make the outputs as similar as possible to ActiLife. However, I worried less about that with the dev parser (and the external one that wraps read.gt3x::read.gt3x), because the corrective steps add computing time without a commensurate benefit. My feeling is that once you're beyond ~3 digits, the amount of error is probably less than the expected measurement error of the sensor, so the minor differences across platforms become completely acceptable.

I do agree that it is important to have an explanation for the differences, so I hope this helps.

[dht7166]

Thanks! The error is small enough that it is most likely not an issue. I will probably ask actigraph about this.

On another note, is there a document that you refer to to write the parser? I checked actigraph documentation on Git, but the documentation is lacking.

[paulhibbing]

Yes, it is based on the ActiGraph documentation. That includes not only the README on the homepage of that repository, but also the files it links to in the LogRecords folder.

[paulhibbing]

Sounds like the decimal rounding question is resolved, so I'll close this