CWA difference #369
Comments
|
I added the output from Created on 2020-10-21 by the reprex package (v0.3.0.9001) Session info |
|
It is necessary to understand that cwa file contains records with unfixed frequency. I do not know why but it is fact. As a result all software must use some procedures to provide normal discretisation frequency. In cwareader the linear interpolation is used to convert data to the 100Hz.
Another software can use different method.
Hope it is useful.
Best regards,
Evgeny
|
|
This data is in 100Hz. I understand it may have a varying effective sampling rate, but this still doesn't seem to indicate why the 3rd record is different or there are large differences from this other open-source software for getting the raw data. Also - the values are way to high for acceleration (140g) in the GGIR output but not in the other solutions. |
|
Thanks @muschellij2 - this issue may overlap with #361 which I closed last week after making pull request #367. The issue was that sample frequency was not correctly recognised from the page headers. I see you are using an older GGIR version, does the issue persist when you use the GGIR master branch here on GitHub? In January I expanded the g.cwaread functionality to also be able to handle AX6 cwa file formats and with help from Dan Jackson we resolved some issues in the numUnpack function affecting AX3 data with non-default configuration settings. |
|
just to re-assure any PA/Sleep researcher reading this. The GGIR code does flag every large QC window (default 15 minutes) as invalid if it has even a single raw acceleration value larger than dynamic range x 1.5, positive or negative. This as a safety net in case something goes wrong with reading the data or files get corrupted. That said, it would be good to investigate what is going on. |
Different packages may handle start of the file differently. For example, there is a known issue with AX3 values in some specific firmware versions being 'stuck' for the first couple of seconds. Some packages may intentionally skip these values while other package simply include them in the output. So, I think it is best not to rely too heavily on row or page number but focus on matching timestamps instead. @muschellij2 if you could also send me a copy of the problematic file that would be much appreciated. In the mean time I am trying to retrieve a copy of a file from another group who had a similar problem a while ago, which I now realize could have been the same issue. |
|
|
accProcess.py is at
https://github.com/activityMonitoring/biobankAccelerometerAnalysis
In
https://github.com/digitalinteraction/openmovement/tree/master/Software/AX3/cwa-convert
I used c/, ran make, then used cwa-convert from that.
Best,
John
…On Thu, Oct 22, 2020 at 2:13 PM Vincent van Hees ***@***.***> wrote:
1. Where can I find accProcess.py?
The last CSV is from cwaconvert
https://github.com/digitalinteraction/openmovement/tree/master/Software/AX3/cwa-convert
1. which of the cwaconvert tools in that directory did you use?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#369 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIGPLTLUFZX3HH3N7FRXB3SMBY4RANCNFSM4S2B5KUA>
.
|
re. minor differences in acceleration valuesWhen I plot the extracted acceleration signal derived with OMGUI csv export which internally uses cwaconvert and compare this with GGIR::g.cwaread output I see a small, approximately constant, offset between the two signals which otherwise follow the same pattern in time, which seems to match John's observation This evening I reviewed all the code in GGIR's g.cwaread and numUnpack relative to the cwa file format documentation in https://github.com/digitalinteraction/openmovement/blob/master/Docs/ax3/cwa.h The part of the code I found more difficult to review is the resampling step because this is not cwa format specific: The resampling in biobankAccelerometerAnalysis looks different from what GGIR does....or is it mathematically equivalent? @Mirkes would you mind having a look at these resample functions and check whether you can spot differences that could explain the minor differences in acceleration values? re. extreme valuesIn current version of GGIR these are flagged and ignored (not g.cwaread but more upstream in GGIR). Hopefully it will be possible to retrieve the problematic example file in the upcoming weeks to investigate further. |
|
I've requested the ability to share the UK Biobank file from the UKBB team. |
|
@danielgjackson Is there is a difference in cwa file format between (1) the cwa files used in UK Biobank and the demofile on the Axivity website and (2) cwa files extracted from commercially sold AX3 sensors? I observe that commercial AX3 sensor output is identical across OMGUI exported csv files and GGIR. The small offset in values only seems to appear in UK Biobank data and the Axivity demofile:
Further, I think the resampling inside GGIR is definitely not the problem, because when I turn it off and compare output with GGIR-based resampled data the signal aligns well as it should. |
|
Dear all,
When I developed resampling for cwaread function I used the very simple linear interpolation algoritm.
I know that open code software presents two different algorithms for java and for python implementation.
Unfortunately there is no unique fixed “true” algorithm for such resampling.
Best regards,
Evgeny
|
|
I don't think the resampling is the problem. I wrapped that software btw to https://github.com/muschellij2/read.cwa so that you can run: remotes::install_github("muschellij2/read.cwa")
library(read.cwa)
out = read_cwa(file) |
|
For easy comparison, I also wrapped that software from @activityMonitoring btw to https://github.com/muschellij2/pycwa so that you can run: remotes::install_github("muschellij2/pycwa")
library(pycwa)
out = py_read_cwa(file) |
|
Thanks @muschellij2. For my own cwa test file collected with commercial AX3 sensor the I am currently not working on paid projects related to cwa data but am happy to invest a bit more time on it once someone has been able to pinpoint the cause of the issue (or contracts me to dedicate more time to it). Hopefully my input here has at least been helpful to inform further investigation by others. |
|
So I made 2 other package for reading CWA files: https://github.com/muschellij2/pycwa and https://github.com/muschellij2/read.cwa for comparison to GGIR and potential checks. Created on 2020-10-30 by the reprex package (v0.3.0.9001) Session info |
There shouldn't be any difference that would explain an offset. Very early firmware could not measure fractional timestamps, but did indicate the sample on which the second rolled over, this allowed recreation of timestamps of roughly the sample interval. Fractional timestamps were added in a relatively complicated way so that it was backwards-compatible with this method. Perhaps this code path for non-fractional times is somehow different in GGIR?
If the above does not turn up anything useful, I think this really must be a "raw export" (cwa-convert) comparison to really see what's going on. Also: Biobank data is in the "packed" mode, so it's worth ensuring that any comparison is on the same basis. |
|
I have had another look at this issue and have come to believe that the issue is not in GGIR::g.cwaread but in the resampling algorithm as implemented in OMGUI and probably also the resampling step of biobankAccelerometerAnalysis. Motivation:
When I plot the content of File1 and File2 on top of each other I get the exact same offset as I showed earlier in this thread. So, the offset does not originate from GGIR::g.cwaread but from OMGUI's own resampling step @danielgjackson. As biobankAccelerometerAnalysis had consistent output with OMGUI this may indicate that the same issue applies there too. @aidendoherty: To test this you will have to plot the resampled and original acceleration signal on top of each other as a function of timestamp. GGIR's resampling code is here. Unrelated extra checks on GGIR Following Dan's advice I also looked closer at GGIR. For this I generated a third file (File3) with OMGUI: Without resampling in raw values (1-256). Next, I edited GGIR::g.cwaread to not scale the acceleration signal such that it exports only the raw unscaled values. Next, I plotted this signal on top of the content of File3, which looks identical. So, the raw value extraction seems to be working fine in GGIR::g.cwaread, even for these older cwa-recordings. Further, I see that GGIR::g.cwaread correctly identifies the scaling factor to be 4096. |
|
I am now closing this issue:
|
I'm going to open one here and at @activityMonitoring as well for https://github.com/activityMonitoring/biobankAccelerometerAnalysis.
Below I show 3 things:
GGIR
accProcess from biobankAccelerometerAnalysis
After running
we get the CSV, and read it in:
Making time an actual time object
Goes from 12:56AM to 12:46PM the next day - I'm not sure why this would be or if this is correct, but seems odd.
Created on 2020-10-21 by the reprex package (v0.3.0.9001)
Session info
The text was updated successfully, but these errors were encountered: