Axivity AX3 drift in data after using export CSV

[ricci199]

Hi everyone, I am currently doing a research project using Axivity AX3 accelerometers more precisely a step algorithm validation study using video to determine the true values. During my data analysis i realized that there is some kind of drift in the data after exporting it as csv. More precisely, video and acceleration signal match as displayed in the GUI (graph) but there is an increasing time difference when i look at the data, which I exported with the Export Raw CSV option. The error is around 30 sec per hour of video, which is quite significant in my case.
Accelerometer settings: +-50Hz and +-8g.
OMGUI Version: Downloaded 11/2020

I will try to reinstall the Programm and see if my issue is fixed in a newer version.
If that does not work I will try to come up with a reproducible example for you.

[danielgjackson]

Apologies for the late response.

The AX devices were explicitly designed to capture the raw output from an underlying sensor – which includes the fact that it will have a slightly variable rate output that will differ slightly to the rate the sensor is configured at. Other loggers typically decide to resample this output at a fixed rate on the device itself – but this can lead to aliasing/blocking artifacts, and it’s better to leave these sort of decisions to be performed later in software, if required. To allow later reconstruction of times, a real-time clock value (initially set when the device is configured, but free-running afterwards) is noted for each batch of data from the underlying sensor. A timestamp (and offset to the batch) is stored once per “sector” (every 40/80/120 samples depending on device/configuration). This results in some of the samples having a timestamp – these timestamps can be interpolated in software after the fact, and/or this can be used to resample the data.

If you are using OmGUI’s CSV Export options, it is worth noting:

• Exporting raw data to CSV: you get the values as given by the underlying sensor -- at its true (and slightly variable) sample rate -- no processing is applied to the data. OmGUI uses cwa-convert internally for this task, so if you were script/batch processing, you might want to use cwa-convert directly:

  • cwa-convert

• Exporting "resampled" data to CSV (and also the built-in processing) The data is interpolated from the original stream to produce an exactly fixed rate of samples, which is useful for some applications. By default, it will also attempt to derive calibration factors from the data (an implementation of this approach) to remove slight offsets/bias from raw data. OmGUI uses omconvert internally for this task, so if you were script/batch processing, you might want to use omconvert directly:

  • omconvert

If you are recording over a longer period of time and/or if you are trying to synchronize with another device's time-stamped measurements, you may have to consider "clock drift" -- please see:

• Synchronizing data between devices, or with other devices