Calibration issues

[Scott]

I am processing CSVs from Axivity and am having trouble getting backup calibration coefficients to work. I have attached my script and by backup cal .csv. When I run the analysis the epoch data is no different than without introducing the backup coefficients, and the data quality .csv does not reflect the new coefficients, even though in 1.9-2 the output says that it has read them in. This is not working on 1.9-2 or 1.10-4. Does the group have any experience with this sort of issue? I do get this warning in  whether or not I run with backup coefficients: 

Warning message:

In g.getmeta(datafile, do.bfen = do.bfen, do.enmo = do.enmo, do.lfenmo = do.lfenmo,  :NAs introduced by coercion

Warm regards, 

Scott

[Vincent van Hees]

Thanks Scott,

This is now fixed in the development version on GitHub. 

I will add it to the next GGIR release on CRAN, probably early October.

Best, Vincent

--
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/0ba5adae-4133-49a7-8cce-bfba483af3f2%40googlegroups.com.

[matteo....@gmail.com]

Dear Vincent and group members,

 

I wonder whether this has now been updated in the newest version? (I think so 😊)

May I ask for some advice, please!

I am currently analyzing a similar short dataset (Geneactiv lab study, measurement duration: 2h) and thus would like to use 1s epoch ENMO data from part 1/2 only. The code works fine although, interestingly, I get two different days in the part2_daysummary.csv (Friday 1.75h and Saturday 0.25h). This seems to depend on the window sizes for the non-wear detection (I reduced them also) and perhaps more? But I am not sure why there are always two days...

Anyway, my main question is about using free-living calibration coefficients for the lab study (I would like to follow Hildebrand et al 2016). We have free-living data from the same device collected before/after the lab session. I have extracted the coefficients (x.scale etc.) from the free-living file “data_quality_report” and put them into a new file, which I have added to the code for the lab study (backup.cal.coef = location of new file).

I think, it worked (eg, angles/ENMO values are different between the analysis with and without “backup calibration” + no errors in R) but I am just not sure here:

1)      In general, am I right using the calibration values (x.scale etc.) from the “data quality report file” from the free-living measurements for that? Is this currently the best way to calibrate very short measurements in GGIR?

2)      When referring to the “old” free-living coefficients using “backup.cal.coef “, the angles/ENMOs are the same, irrespective of do.cal = TRUE/FALSE. I read it should be “FALSE” in a different post?

3)      I can find the “old" free-living cal. coefficients in the newly generated file “Data_quality_report” for the lab study but values of Zero for pre and post calibration error and the message saying “Autocalibration not done”. I guess this is ok since I manually calibrated them?

 

Further details:

When analyzing the lab study in the standard way (without backup cal.), calibration is done but auto-calibration not? Eg, there are values for cal.error.start = 0.01324, n.10sec.windows=216 but it tells me that recalibration was not done because there not enough points on all sided of the sphere. That is why I wondered about manual calibration.

 

 

Thank you very much!!

Best wishes

Matteo

[Vincent van Hees]

Hi Matteo,

I am currently analyzing a similar short dataset (Geneactiv lab study, measurement duration: 2h) and thus would like to use 1s epoch ENMO data from part 1/2 only. The code works fine although, interestingly, I get two different days in the part2_daysummary.csv (Friday 1.75h and Saturday 0.25h). This seems to depend on the window sizes for the non-wear detection (I reduced them also) and perhaps more? But I am not sure why there are always two days...

GGIR splits data based on the midnight timestamps it finds in the data.

Did you specify argument desiredtz as your local timezone and did the recording not overlap with midnight?

Anyway, my main question is about using free-living calibration coefficients for the lab study (I would like to follow Hildebrand et al 2016). We have free-living data from the same device collected before/after the lab session. I have extracted the coefficients (x.scale etc.) from the free-living file “data_quality_report” and put them into a new file, which I have added to the code for the lab study (backup.cal.coef = location of new file).

I think, it worked (eg, angles/ENMO values are different between the analysis with and without “backup calibration” + no errors in R) but I am just not sure here:

1)      In general, am I right using the calibration values (x.scale etc.) from the “data quality report file” from the free-living measurements for that? Is this currently the best way to calibrate very short measurements in GGIR?

In theory yes, but this comes with a couple of assumptions:

• Calibration error is consistent between daily life and the conditions of your lab experiment.
• The daily life data included sufficient non-movement periods to inform the auto-calibration procedure.

To my knowledge no research has been done to evaluate these assumptions, and make recommendations. At the very least I would recommend also exploring filter-based metrics (BFEN, HFEN, MAD) as those are less affected by calibration error. I think that has been one of the missed opportunities in the cut-point papers we did.

2)      When referring to the “old” free-living coefficients using “backup.cal.coef “, the angles/ENMOs are the same, irrespective of do.cal = TRUE/FALSE. I read it should be “FALSE” in a different post?

​If argument backup.cal.coef is specified then auto-calibration will not be run. I do not think do.cal will change this.

3)      I can find the “old" free-living cal. coefficients in the newly generated file “Data_quality_report” for the lab study but values of Zero for pre and post calibration error and the message saying “Autocalibration not done”. I guess this is ok since I manually calibrated them?

Yes, this is expected behaviour, but I agree that it is somewhat confusing. Ideally you would like to display the error reduction that was achieved in the free-living data. If you think this is important to fix, would you mind creating an issue item to describe this https://github.com/wadpac/GGIR/issues (Sorry, I tend to forget issue if they are not logged there or recently discussed in this GGIR google group).

 Further details:

When analyzing the lab study in the standard way (without backup cal.), calibration is done but auto-calibration not? Eg, there are values for cal.error.start = 0.01324, n.10sec.windows=216 but it tells me that recalibration was not done because there not enough points on all sided of the sphere. That is why I wondered about manual calibration.

GGIR uses some criteria for auto-calibration, which i believe were also describe in the 2014 paper (van Hees VT, Fang Z, Langford J, Assah F, Mohammad A, da Silva IC, Trenell MI, White T, Wareham NJ, Brage S. Auto-calibration of accelerometer data for free-living physical activity assessment using local gravity and temperature: an evaluation on four continents. J Appl Physiol (1985). 2014 Aug 7).

My impression is that even of the auto-calibration succeeds in a short experiment it is still better to use the data carefully as auto-calibration is not really designed for short experiments.

Best wishes,

Vincent

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

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/f5a9cbec-52c2-4573-a6ab-f3172e106107n%40googlegroups.com.

[matteo....@gmail.com]

Dear Vincent,

Thank you very much for your detailed response!! Regarding issue 1. We've tried different time settings but the split remained. However, we will fix this in some way.

This sounds good. We will then consider BFEN etc. as well.

All the best,

Matteo

[Vincent van Hees]

However, we will fix this in some way.

​

If you observe unexpected behaviour then it is important that you try to help fix it. For example, by sharing a detailed description of the issue and in case you find a solution by proposing that solution to us. 

Open-source projects like GGIR depend on an ongoing effort from the community to report and address problems. Once everyone starts to make their own local ad-hoc fixes to problems it will hugely limit the growth and quality of GGIR.

Just like you are benefitting from the endless hours others have put into GGIR, others will be grateful if you could also share your experiences. Detailed bug reports help.

Thanks,

Vincent

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

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

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/7c4fd814-e5e4-4e98-9995-bec95806273an%40googlegroups.com.