Difference between revisions of "Iis2dh"

From Wiki at Neela Nurseries
Jump to: navigation, search
(Created page with "Notes on . . . * https://community.st.com/s/question/0D50X00009XkdfV/understanding-acceleration-data-from-iis2dh <i>Excerpt on accelerator configurations from this develope...")
 
m
Line 65: Line 65:
  
 
<!-- comment -->
 
<!-- comment -->
 +
 +
<!--
 +
 +
mhackney (Community Member) to ST Community (ST Employee): asked a question.
 +
Edited by STM Community November 29, 2018 at 4:56 PM
 +
Understanding acceleration data from IIS2DH
 +
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.
 +
 +
    MEMS and Sensors
 +
 +
    Share
 +
 +
    15 answers
 +
    309 views
 +
 +
    mhackney (Community Member)
 +
    Edited by ST Community July 21, 2018 at 5:26 PM
 +
    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 (ST Employee)
 +
Edited by ST Community July 21, 2018 at 5:26 PM
 +
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 (ST Employee)
 +
Edited by ST Community July 24, 2018 at 4:32 PM
 +
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 (Community Member)
 +
Edited by ST Community July 26, 2018 at 1:13 PM
 +
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 (Community Member)
 +
Edited by ST Community July 26, 2018 at 4:05 PM
 +
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 (ST Employee)
 +
Edited by STM Community July 27, 2018 at 9:13 AM
 +
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 (Community Member)
 +
Edited by STM Community July 27, 2018 at 11:46 AM
 +
Posted on January 02, 2017 at 23:40
 +
 +
 +
 +
 +
 +
Is there a way to read the actual value that generated the interrupt?
 +
 +
Miroslav BATEK (ST Employee)
 +
Edited by STM Community July 27, 2018 at 1:02 PM
 +
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 (Community Member)
 +
Edited by STM Community November 7, 2018 at 1:49 PM
 +
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!
 +
 +
 +
 +
 +
 +
mhackney (Community Member)
 +
Edited by STM Community November 7, 2018 at 1:49 PM
 +
Posted on January 03, 2017 at 15:56
 +
 +
 +
 +
 +
 +
 +
 +
Miroslav, I am making progress! Thank you for your help. I think I have a much better understanding of the accelerometer now but have some more learning to do. I implemented the Stream-to-FIFO mode and print the 32 bytes of data after each INT1. The results are logical and they should allow me to start to tune the system. Here are the data for a single probe contact:
 +
 +
 +
 +
#1 - Time: 68s - Since Last: 68s
 +
 +
 +
 +
acceleration data (FIFO):
 +
 +
 +
 +
0: 0.74g
 +
 +
 +
 +
1: 0.74g
 +
 +
 +
 +
2: 0.70g
 +
 +
 +
 +
3: 0.80g
 +
 +
 +
 +
4: 0.86g
 +
 +
 +
 +
5: 0.99g
 +
 +
 +
 +
6: 1.15g
 +
 +
 +
 +
7: 1.18g
 +
 +
 +
 +
8: 1.31g
 +
 +
 +
 +
9: 1.34g
 +
 +
 +
 +
10: 4.06g
 +
 +
 +
 +
11: 1.86g
 +
 +
 +
 +
12: 0.38g
 +
 +
 +
 +
13: 1.92g
 +
 +
 +
 +
14: 1.60g
 +
 +
 +
 +
15: 0.13g
 +
 +
 +
 +
16: 1.02g
 +
 +
 +
 +
17: 1.44g
 +
 +
 +
 +
18: 1.12g
 +
 +
 +
 +
19: 1.18g
 +
 +
 +
 +
20: 1.66g
 +
 +
 +
 +
21: 1.28g
 +
 +
 +
 +
22: 1.09g
 +
 +
 +
 +
23: 1.22g
 +
 +
 +
 +
24: 1.28g
 +
 +
 +
 +
25: 1.34g
 +
 +
 +
 +
26: 0.99g
 +
 +
 +
 +
27: 0.64g
 +
 +
 +
 +
28: 0.77g
 +
 +
 +
 +
29: 1.02g
 +
 +
 +
 +
30: 0.86g
 +
 +
 +
 +
31: 0.86g
 +
 +
 +
 +
Note point # I see exactly this same pattern in all 13 probe contacts. The value is 4.06g for 9 of the probe contacts but there are a few points as low as 3.26g. This may be due to the hard plastic surface or other factors related to the mechanical aspects of the printer. This data was collected with FS=4g and low power 8-bit data mode with threshold value set to 95 (3.04g). No high pass filter.
 +
 +
 +
 +
I next need to understand high pass filter and how to use it.
 +
 +
 +
 +
I also need to experiment to see if I can makethe contact impact lower by adjusting the probe speed, etc.
 +
 +
 +
 +
What do you think about this data? Does it give you any ideas on how best to tune the system now?
 +
 +
-->
 +
 +
 +
 +
<!-- EOF -->

Revision as of 19:04, 14 October 2021

Notes on . . .

Excerpt on accelerator configurations from this developer: mhackney (Community Member) Edited by ST Community July 21, 2018 at 5:26 PM 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);





Retrieved from "https://wiki.neelanurseries.com/index.php?title=Iis2dh&oldid=5134"