Accelerometer calibration

sjmerel

We're using the accelerometer and gyroscope data streamed from MetaWear C devices for analysis by our algorithms.  We've noticed that the accelerometers do not seem to be very accurate.  I would expect the magnitude of the accelerometer reading to be around 9.8 m/s^2 regardless of the orientation, but in fact the magnitude does vary pretty significantly.  I measured it along each of 6 directions (+/- x, y, z) with the device stationary for 2 devices, and found magnitudes as low as 8.3 and as high as 11.5.

Is this what you would expect for all the MetaWear devices?  Or do some of them use more accurate accelerometer hardware?

Eric

Can you post the raw XYZ data that you measured?

sjmerel

Here some the raw values (but scaled by 9.80665f). We're sampling at 50Hz.

gravity along -z:
-1.95367,-0.49321,-8.99741,
-1.93930,-0.47405,-8.96389,
-1.94888,-0.46926,-8.93516,
-1.93451,-0.46448,-9.00220,
-1.93930,-0.47884,-8.95431,
-1.93451,-0.47884,-8.94474,
-1.92494,-0.49321,-9.01178,
-1.93930,-0.48363,-8.98783,
-1.92973,-0.47405,-8.93516,
-1.93930,-0.48363,-8.96868,
-1.95367,-0.48842,-8.99262,
-1.94409,-0.47884,-8.97347,
-1.95367,-0.48363,-8.96389,
-1.94409,-0.47884,-8.96389,
-1.94409,-0.47405,-8.93037,
-1.93451,-0.46448,-9.04051,
-1.92015,-0.47405,-8.92080,
-1.96325,-0.48842,-8.94953,
-1.92973,-0.48363,-8.94953,
-1.96325,-0.50278,-8.92558,

gravity along +z:
-1.38864,0.05267,10.66856,
-1.42694,0.05267,10.65899,
-1.42216,0.04788,10.62068,
-1.39343,0.03352,10.63983,
-1.41258,0.02394,10.64941,
-1.42694,0.05267,10.64941,
-1.41258,0.00000,10.64941,
-1.41737,0.04788,10.68772,
-1.38864,0.00958,10.64462,
-1.44131,0.02873,10.65899,
-1.41737,0.05267,10.63026,
-1.40779,0.03831,10.71166,
-1.40779,0.06225,10.66377,
-1.42216,0.01915,10.62547,
-1.42694,0.04310,10.74518,
-1.40779,0.02873,10.60153,
-1.40779,0.02394,10.63983,
-1.37427,0.03352,10.67335,
-1.40300,0.03831,10.67814,
-1.42216,0.02394,10.63983,

gravity along +y:
-1.81959,9.46667,1.55144,
-1.79565,9.46667,1.53708,
-1.77650,9.48104,1.53229,
-1.81480,9.45710,1.53229,
-1.82917,9.46189,1.55623,
-1.78129,9.46189,1.53229,
-1.76213,9.45710,1.54187,
-1.78129,9.45710,1.56581,
-1.80044,9.45231,1.57538,
-1.81959,9.46667,1.54187,
-1.80523,9.46189,1.56102,
-1.78129,9.46667,1.50835,
-1.77650,9.47625,1.53229,
-1.78607,9.45710,1.56102,
-1.78607,9.44752,1.58496,
-1.79086,9.45231,1.58975,
-1.76213,9.49540,1.53229,
-1.78129,9.43794,1.54665,
-1.80523,9.45231,1.52271,
-1.81002,9.46189,1.54187,

gravity along -y:
-1.80044,-9.95509,1.10133,
-1.80044,-9.95030,1.07739,
-1.73819,-9.98382,1.04866,
-1.76213,-9.97903,1.04387,
-1.77650,-9.95030,1.08218,
-1.82917,-9.97424,1.01035,
-1.78607,-9.97424,1.03908,
-1.76692,-9.95030,1.09176,
-1.77650,-9.97903,1.11091,
-1.78607,-9.96946,1.10612,
-1.77171,-9.96946,1.11091,
-1.82438,-9.96467,1.13964,
-1.79086,-9.95988,1.10133,
-1.75734,-10.01255,1.00556,
-1.77171,-9.98861,1.01993,
-1.77171,-9.95509,1.14922,
-1.81480,-9.95988,1.12049,
-1.82917,-9.95509,1.08697,
-1.78129,-9.99819,0.96726,
-1.74777,-10.00297,0.98641,

gravity along -x:
-11.48738,-0.37828,1.59454,
-11.49696,-0.36392,1.56581,
-11.48259,-0.37828,1.48919,
-11.47301,-0.38786,1.48441,
-11.45865,-0.36871,1.54187,
-11.48259,-0.36392,1.56102,
-11.47301,-0.36392,1.56102,
-11.50175,-0.38307,1.49398,
-11.48259,-0.38786,1.47962,
-11.48259,-0.39744,1.53229,
-11.50653,-0.36871,1.55144,
-11.47780,-0.36392,1.50835,
-11.48259,-0.38307,1.52750,
-11.48738,-0.38786,1.51314,
-11.48738,-0.39744,1.47483,
-11.49696,-0.39744,1.49398,
-11.48738,-0.37350,1.48919,
-11.52090,-0.37828,1.52750,
-11.42513,-0.39744,1.51792,
-11.49217,-0.38786,1.51792,

gravity along +x:
8.03973,-0.48363,-0.22984,
8.05888,-0.41180,-0.11492,
8.03973,-0.52194,-0.12450,
8.04452,-0.52672,-0.11013,
8.04931,-0.48842,-0.11492,
8.07325,-0.46926,-0.07661,
8.04931,-0.50278,-0.08140,
8.06367,-0.56982,-0.12450,
8.05409,-0.47884,-0.13886,
8.04452,-0.46448,-0.11013,
8.04452,-0.49799,-0.08140,
8.04452,-0.51236,-0.08140,
8.04931,-0.49799,-0.07661,
8.07325,-0.48363,-0.13408,
8.02536,-0.49321,-0.14365,
8.05409,-0.51236,-0.11971,
8.08761,-0.48363,0.00479,
8.06367,-0.50757,-0.14365,
8.05888,-0.50757,-0.07661,
8.03015,-0.49799,-0.10534,

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000}
span.s1 {font-variant-ligatures: no-common-ligatures}

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000}
span.s1 {font-variant-ligatures: no-common-ligatures}

Matt

sjmerel

We observed similar but less severe offset on devices in the lab.

The "Zero-g Offset" spec for the BMI160 (most models) is +/- 150mg, and for the BMA255 (select models) is +/- 60mg.

To improve the offset, you could self calibrate a sensor using the offset endpoint exposed by the firmware.

sjmerel

Thanks - Is this error typically a constant offset to the actual value, then (as opposed to a scale factor, or something more complicated)?

sjmerel

@Matt can you give me more details on how to use the offset endpoint?  Is this accessible through the iOS API?

Is there any way we can store calibration data on the device persistently?  That way we could calibrate before shipping to a customer, rather than requiring the customer to go through a complicated calibration process themselves.  

Eric

The iOS API currently does not support setting the offset registers but we can add that in the next release.  Alternatively, you could try using the SPI module to directly write to the registers.

You can use the macro module to write the calibration commands to the flash memory and have them execute on boot.

sjmerel

Thanks Eric,

Are the offset registers persistent or do they reset after the device is turned off and on?

Can you give more some more details on how to write the calibration commands to the flash memory?  

Eric

No, registers revert to their default value after a reset.

See this section in the iOS documentation for writing commands to flash memory:

https://mbientlab.com/iosdocs/2.8.4/advanced_features.html#persistent-configuration

sjmerel

I can see how I would use MBLRestorable to change a setting when the device boots (e.g. to set the device name). If you did add the ability to set offset registers to the iOS API, then I think I could set them to the correct value for each device at startup that way.

However, since we don't have that in the current version, is there a way to store arbitrary data (i.e. the necessary x/y/z offsets) persistently?  Then the iOS app could read them from the device and apply the offsets to the data as it receives it.

Or, I see that you can use MBLArithmeticEvent to modify event data, but can this can be set up at boot (or can it even apply to accelerometer data at all)?

Eric

Filters can be saved as described in this tutorial:

https://mbientlab.com/docs/apis/objective-c/persistent-events-and-filters/

You can't store arbitrary data in the flash memory but we'll work on getting the offset registers supported in the APIs.

sjmerel

Actually, it seems like I can store data!  I just needed to implement an MBLRestorable with properties for x/y/z offsets; when I call setConfiguration it serializes those property values persistently.  I can read them later and offset the accelerometer values as needed.

(This is actually easier and more flexible for our case than creating custom events to add the offsets, since we still have access to the original uncorrected accelerometer data if we need it.)

thanks!