IIS3DWBTR Filter LPF2 frecuency response

[MSierraA]

Hello Community,

We have been using the IIS3DWBTR sensor for some time and have observed some odd behavior regarding filters. We recently performed some experimental tests on the LPF2 Filter to corroborate the frequency response curves on page 20 of the datasheet and found that it didn’t behave as intended. Oddly, we found that (experimental artifacts aside) the experimental curve had a better match with the *next* filter cutoff configuration. For example, the experimental results when configuring LPF2 with a cutoff frequency of ODR/20 has a good match with the theoretical curve for a cutoff of ODR/10, as shown in the next plots (yellow is theoretical, blue is experimental).

Theoretical response on page 20:

Experimental Response for us:

ODR/10 Theoretical vs ODR/10 Configured:ODR/10 Theoretical vs ODR/20 Configured:

ODR/20 Theoretical vs ODR/20 Configured:

ODR/20 Theoretical vs ODR/45 Configured:

On our tests we used the following configuration:

spi_buffer[1] = 0x06;               //power down mode + LPF2 Enable +- 16g
spi_write(CTRL1_XL, 1);
spi_buffer[1] = 0x44;               // bdu: 1, if_inc: 1
spi_write(CTRL3_C, 1);
spi_buffer[1] = 0x2C;   // (int 1 or int 2)--> int1: enable, i2c: disabled
spi_write(CTRL4_C, 1);
spi_buffer[1] = 0x00;         // Disable self-test, no rounding
spi_write(CTRL5_C, 1);
spi_buffer[1] = 0x00;        // offset 2^-10 g/LSB, 3 axis mode --> 0x08 offset 2^-6 g/LSB, 3 axis mode
spi_write(CTRL6_C, 1);
spi_buffer[1] = 0x02;// bypassed --> 0x02 enabled offset correction block
spi_write(CTRL7_C, 1);
switch (ODR_Option)
    {
        case 0:
            spi_buffer[1] = (CTRL8_ODR_800);   //0xE0
            break;
        case 1:
            spi_buffer[1] = (CTRL8_ODR_400);   // 0xC0
            break;
        case 2:
            spi_buffer[1] = (CTRL8_ODR_200);   // 0xA0
            break;
        case 3:
            spi_buffer[1] = (CTRL8_ODR_100);   // 0x80
            break;
        case 4:
            spi_buffer[1] = (CTRL8_ODR_45);    // 0x60
            break;
        case 5:
            spi_buffer[1] = (CTRL8_ODR_20);    // 0x40
            break;
        case 6:
            spi_buffer[1] = (CTRL8_ODR_10);    // 0x20
            break;
        case 7:
            spi_buffer[1] = (CTRL8_ODR_4);     // 0x00
            break;
        case 8:
            spi_buffer[1] = (CTRL8_ODR_4);     // 0x00
            break;
       
        default:
            spi_buffer[1] = 0x00;               // 0x00 low pass, 6.3 hHz
            break;
    }
 spi_write(CTRL8_XL, 1);   // Acel bandwidth and low/high pass
 spi_buffer[1] = 0x00;               // Timestamp disabled
 spi_write(CTRL10_C, 1);
 spi_buffer[1] = 0x01;               // int1 DRDY enable
spi_write(INT1_CTRL, 1);
spi_buffer[1] = 0x01;               // int2 DRDY enable
spi_write(INT2_CTRL, 1);
if (ODR_option < 8){
    spi_buffer[1] = 0xA6;               // LPF2 Enable +- 16g
  }else{
    spi_buffer[1] = 0xA4;               // LPF2 disable +- 16g
}
spi_write(CTRL1_XL, 1);
delay_ms(100);         // delay time mentioned in datasheet

The experimental tests were back-to-back tests against a reference piezoelectric accelerometer mounted on an electrodynamic shaker. The signal measured from the piezoelectric was used as reference to calculate the attenuation.

We would appreciate your comments regarding LPF2 performance from your experience or possible explanation for this behavior. Maybe we are not configuring it right. Any suggestion is welcome.

[Eleon BORLINI]

Hi @MSierraA​ ,

Thank you for the detailed measures.

It is not clear to me which is the root cause of this "mismatch" between theoretical and experimental. I would suspect in the presence of a resonance peak around the -3dB roll-off point. Might it be caused by a true mechanical resonance due to spurious vibration of the setup? This peak seems to stay at a constant frequency, even when the frequency of the digital filter is changed. Are you using the STEVAL-MKI208V1K to run these measures?

-Eleon

[MSierraA]

@Eleon BORLINI​ thank for you answer.

Might it be caused by a true mechanical resonance due to spurious vibration of the setup?

• it is possible in 1KHz but other frequency is rare.

Are you using the STEVAL-MKI208V1K to run these measures?

• we don't use it, we use IIS3DWBTR for this experiment.

On the other hand, do you recommend other configuration steps in order or values?

[Eleon BORLINI]

Hi @MSierraA​ ,

about this point:

• we don't use it, we use IIS3DWBTR for this experiment.

so are you using a custom application board? How is it made and how is it mounted on the shaker? And is the reference accelerometer mounted on this board too? I would like to exclude spurious resonances introduced by the test setup. We typically suggest the STEVAL-MKI208V1K as simple form factor for characterization measures.

-Eleon