Axivity AX3 drift in data after using export CSV

[digitalinteraction]

Axivity AX3 drift in data after using export CSV

[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