IIS3DWBTR Filter LPF2 frecuency response
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 datasheetThe 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.