FAQ’s

Browse through some of the questions we are often asked:

Help With ActivityScope

Data from the sensors is collected at 100Hz. This means one-hundred measurements on each axis or each sensor per second; thats quite a lot of data. Rather than present measurements at 10ms resolution, data is aggregated into summary chunks. These chucks are called epochs and are 1-minute width.

That means every minute there is only one epoch measure per axis, but this measure contains information from 6000 samples (60 seconds * 100Hz).

ActivityScope uses a multi-stage analysis approach. This means there isn’t a single algorithm that gives all the results you see. Each stage is a self contained module based on its own validation studies.

For more information on the each of the algorithms used, its accuracy and validation studies please see the manual for ActivityScope

As default, **Not-Worn** periods are currently EXCLUDED and non-contributory to the figures presented in the interface.

ActivityScope doesn’t use just one algorithm; there are separate ones for counts, steps, distance, bouts, energy. Each algorithm has been validated in isolation and so its not appropriate to quote a single overall figure.

For more information on performance of each individual algorithm, please visit the ActivityScope manual

Help With GaitKeeper

As default, **Not-Worn** periods are currently EXCLUDED and non-contributory to the figures presented in the interface.

Yes. Each sensor is configured to go on a specific leg. If its attached to the wrong leg (left instead of right or front instead of hind) the results may not make sense.

Help with MX Cradle

The cradle can work in Offline mode for configuring sensors and downloading them. However, results will not be available until the cradle has been fully synchronised.

Please remember the cradle also has limited memory capacity so its important to regularly synchronise to avoid memory issues.

The cradle has enough battery for approximately 4-6 hours of use. Exact figures will vary depending on the number of sensors being configured and if streaming is enabled.

Help with MX Sensors

The MX sensor is specifically designed to capture the raw output from the on-board IMU. The IMU chip is programmed with the requested sample rate but, as it is responsible for its own timing, the exact rate may vary slightly. Other devices will re-sample this at a fixed (more precisely timed) rate, but this approach can cause blocking/aliasing artifacts; something that is avoided by recording the raw data. Instead, timestamps are stored (at a high precision) and, for applications that required a fixed sample rate, this “re-interpolation” can be performed after the data is downloaded (and more accurately by a desktop computer). In addition it leaves the raw data intact. The EXPORT functions in the software include an option to perform such interpolation.

The MX sensor incorporates a 9-axis IMU motion sensor (accelerometer, gyroscope and magnetometer); MPU9250. The chip is manufactured by Invensens and full technical information can be found on the manufacturers datasheet here

Data from the sensors is collected at 100Hz. This means one-hundred measurements on each axis or each sensor per second; thats quite a lot of data. Rather than present measurements at 10ms resolution, data is aggregated into summary chunks. These chucks are called epochs and are 1-minute width.

That means every minute there is only one epoch measure per axis, but this measure contains information from 6000 samples (60 seconds * 100Hz).

The MX sensor incorporates a 9-axis IMU motion sensor (accelerometer, gyroscope and magnetometer); MPU9250. The chip is manufactured by Invensens and full technical information can be found on the manufacturers datasheet here

The MX sensor can be configured to log with various range settings (±4,8,16g). This range should be set such that the largest experienced accelerations does not cause clipping. At each range setting, the MX Sensor has a limited or fixed amount of bits to represent the data; this is termed the bit-depth. In 1st generation sensors a 16-bit sensor is used

At each bit depth, the range of accelerations is quantised into discrete levels. The width of each one of these levels is often called the sensitivity. To calculate the sensitivity you can simply use the following:

2^16 = 65,536 levels

Then divide the range by the number of levels. For example at ±8g, there is a dynamic range of 16g. Therefore:

16g / 65,536 = 0.00024g (or 0.2mg)

The MX sensor incorporates a 9-axis IMU motion sensor (accelerometer, gyroscope and magnetometer); MPU9250. The chip is manufactured by Invensens and full technical information can be found on the manufacturers datasheet here

There are a number of developer resources available for working with the data from the MX sensor and also the actual sensor itself. These resources are published under the developer pages.

There are a number of developer resources available for working with the data from the MX sensor and also the actual sensor itself. These resources are published under the developer pages.


Cant find what your looking for then get in contact