Understanding acceleration data from IIS2DH

mhackney · ‎2017-01-02

Posted on January 02, 2017 at 16:15

I've been trying to understand how to interpret and format the data I'm getting from the accelerometer. First, my setup:

Low power, 5.376KHz ODR, 16G full scale, normalresolution mode, ZHIE enabled, ZLOW disabled, THSset to 30

(First I need to understand how to interpret and format the data with the above configuration, then I can work on tuning things for my application).

I am using an Arduino to interface to the IIS2DH and getting AOI interrupts on INT1. All of this is working in my Arduino and code.

This is a Z probe for a 3D printer, so when the probe (accelerometer) strikes a solid surface, it generates an interrupt for the Z axis event (X and Y are not enabled). This all works. I get the interrupt and then fetch the OUT_Z_L and OUT_Z_H registers as 8 bit integers. It is from here that I need help understanding what I am getting and how to interpret it.

When I run my tests, I can print the output to the console to see what's going on. When I do this, for a typical probe 'hit', I see, in binary:

Z_H = b00001000

Z_L = b00001010

I do see small differences from probe point to probe point - there are 13 probesin a typical run so I see 13 pairs of values. Here's a full set in Z_H / Z_L order:

00001000 /00001001

00001001 /00001010

00001001 /00001001

00001001 /00001010

00001000 /00001010

00000111 /00000111

00000110 /00001000

00000110 /00001001

00001000 /00001001

00000111 /00001000

00000101 /00000111

00001001 /00001001

00001011 / 00001001

Does this make sense? It doesn't to me. I never see data in the high 4 bits of the low or high byte. I thought the data was left aligned and with my normal resolution (10 bits, correct?) I would expect to see nothing in the lower 6 bits of the low byte. Am I retrieving sensible data and if so, how do I reconstruct it into a value?

Thanks in advance!

#iis2dh

Note: this post was migrated and contained many threaded conversations, some content may be missing.

mhackney · ‎2017-01-02

Posted on January 02, 2017 at 16:21

Ok, I overlooked the data sheet that Low Power mode is 8-bit data output. But that still does not explain why the data is not left aligned?

Also, here is my complete configuration to sanity check:

// setup CTRL_REG1

accelerometer_write(CTRL_REG1, 0b10011100); // ODR 5.376kHz in LPMode [7-4] Low power enable [3] Z enable [2]

// setup CTRL_REG2

accelerometer_write(CTRL_REG2, 0b00110001); //

// setup CTRL_REG3

accelerometer_write(CTRL_REG3, 0b01000000); // AOI (And Or Interrupt) on INT1 en [6]

// setup CTRL_REG6

accelerometer_write(CTRL_REG6, 0b00000000); //

// setup CTRL_REG4

accelerometer_write(CTRL_REG4, 0b00110000); // Full-scale selection 16G [5-4]

// setup CTRL_REG5

accelerometer_write(CTRL_REG5, 0b01001010); // FIFO enable [6] Latch INT1 [3]

// setup INT1_CFG

accelerometer_write(INT1_CFG, 0b00100000); // ZHIE enabled [5]

// setup INT1_THS

accelerometer_write(INT1_THS, Z_PROBE_SENSITIVITY); // 40

// setup INT1_DURATION

accelerometer_write(INT1_DURATION, 0);

Miroslav BATEK · ‎2017-01-02

Posted on January 02, 2017 at 23:29

Yes, all 8 bits of Z_H are valid.

Yes, if you need 16 bit value you can do it as you mentioned.

Yes, your interpretation is corrent.

The sensitivity for all configuration can be found in Table 3. Sorry for the confusion the 208mg/LSB is maximum value of the sensitivity, I looked at the wrong column. You should use typical value which is 188.68mg/LSB.

In 8, 10, 12 bit resolution you always use the appropriate number of most significant bits.

10 bit mode ... ((256*OUT_Z_H)+

OUT_Z_L)>>6

12 bit mode ... ((256*

OUT_Z_H)+

OUT_Z_L)>>4

Miroslav BATEK · ‎2017-01-02

Posted on January 02, 2017 at 22:30

In Low Power mode the output is only 8-bit, so you should simply ignore the

Z_L byte. The data in

Z_L byte are not valid.

If you hit the sensor more, you should see also some values in high 4 bits of Z_H. For example if the configuration is FS=16g, Low Power mode the LSB=208mg, so to see 0b00010000 output value, you have to generate acceleration 3328mg.

mhackney · ‎2017-01-02

Posted on January 02, 2017 at 22:53

Thank you. Does this mean that with FS=16g and 8-bit output that all 8 bits of Z_H are valid? To make a 16 bit value from it. do I shift left 8 places and fill the right 8 places with 0?

Looking at my data above for probe point 1:

00001000 / 00001001

What you are saying is that the low byte (00001001) should be ignored. So, what is the actual measured acceleration, is it: 00001000 (actually 00000000 00001000 if 16 bits) or something else?

So in this case: 8 * 208mg = 1664mg or 1.664g This makes some sense so perhaps it is the correct way to interpret?

And where did you get the 208mg for the LSB in FS=16g? In the datasheet it looks like it should be 186mg from table 57? So 8 * 208mg = 1.488g. Is this correct?

Assuming my interpretation above is correct - that I can just use Z_H byte as-is, how is the data arranged in 10 and 12 bit resolution modes?

mhackney · ‎2017-01-02

Posted on January 02, 2017 at 23:19

So based on this better understanding, I updated my code and set FS=4g. So, 1 LSB should be 32mg. I set my threshold to '60', which is 1920mg (1.92g). However, when I probe I am seeing false hits and even probe points themselves that are less than the threshold:

&sharp1 1.57g

&sharp2 1.95g

&sharp3 1.22g

&sharp4 0.32g

&sharp5 1.82g

&sharp6 0.58g

&sharp7 1.79g

&sharp8 1.76g

&sharp9 2.02g

&sharp10 1.98g

&sharp11 1.82g

&sharp12 0.86g

&sharp13 1.50g

&sharp14 1.57g

&sharp15 1.25g

&sharp16 1.60g

&sharp17 1.79g

&sharp18 1.34g

&sharp19 2.14g

&sharp20 1.73g

The data in bold are the actual 13 probe points, the others are all false triggers. My threshold is set to 60 at 8-bit resolution and FS=4G (my CTRL_REG4 is set to 0b00010000. So shouldn't I only see accelerations greater than 60 * 32mg = 1.92g?

Miroslav BATEK · ‎2017-01-02

Posted on January 02, 2017 at 23:38

My guess it that you are not reading the exact same sample as triggered the interrupt. The ODR

5.376KHz is quite fast and there is a dalay between your microcontroller process the intterupt and read data from the sensor. So you are probably reading late value, after the hit, which can be lower then the treshold. There will be probably also some bouncing.

mhackney · ‎2017-01-02

Posted on January 02, 2017 at 23:40

Is there a way to read the actual value that generated the interrupt?

Miroslav BATEK · ‎2017-01-03

Posted on January 03, 2017 at 11:51

Yes, there is a way how to do it. You need to use the FIFO, to be more specific the Stream-to-FIFO mode. In this mode you can analyze the history that generates an

interrupt. The last sample in the FIFO will the one which triggered the interrupt.

mhackney · ‎2017-01-03

Posted on January 03, 2017 at 15:07

Thanks again. I've implemented the Stream-to-FIFO and have 2 questions:

1) Once the interrupt is triggered (INT1 in my case) do I need to do anything to reset other than reset the INT1?

2) you say 'last sample in the FIFO' is the one that triggered the INT1. I just want to make sure I understand this since it is a FIFO. Are you saying that I need to read 32 values to get to the 'last sample' or will if it be the first read after the INT1 is generated?

thanks!