Pressure readings problem when IMU sensor is on


I am using the nano board as a small mobile measuring device that sends its data to my smartphone. I have a working set of programs (I can elaborate on that if needed), but I encountered a problem which I think is link to an interaction between the IMU sensor and the barometer. Here is a striped down version of the problem, using serial connection instead of BLE connection, for easier reproducibility:

#include <Arduino_LPS22HB.h>
#include <Arduino_LSM9DS1.h>

unsigned int period = 50;
unsigned long  data_time ;
boolean debug = false ; // choose TRUE or FALSE here to test the problem

void setup() {
  while (!Serial);

  if (!BARO.begin()) {
    Serial.println("Failed to initialize pressure sensor!");
    while (1);

  if (debug == true) {  // THAT IS THE PART THAT CAUSES THE DIPS
    if (!IMU.begin()) { 
      while (1);
  data_time = millis();

void loop() {
  float pressure ;
  if ((unsigned long)(millis() - data_time) > period) { // wait for 50 ms between two measurements
    // read the sensor value
    pressure = BARO.readPressure();
    data_time = millis();
    // print the sensor value on the serial connection
    Serial.println(pressure, 6);

What this program does is that it measures the pressure every 50 ms and sends the data on the serial connection. The boolean "debug", true or false, enable the activation or not of the IMU sensor (accelerometer, gyroscope, magnometer). When the IMU sensor is not activated, the signal of the barometer is OK. When the IMU is activated, even if it is not used by the program, the pressure measurements show some periodic dips (screenshots below). These dips appear on several devices, and the period of these dips can vary.

Now these dips are small, but they are noticeable, and consistent. I guess there is an interaction between the sensors, but does anyone knows why exactly?

Also, any tips on how to get rid of it would be much appreciated... (not turning on the IMU is not always possible in my use).

Thank you in advance,

Meilleurs Regards,


(PS: this question was first asked on the phyphox forum. Phyphox is the app I am using for BLE communication and data collection, but since the problem is not with the app, I moved the discussion here.)

The code snippet posted looks good.

In order to see better the effect I have activated the IMU sensors at 50 seconds after the acquisition start. One can see clearly a step of the signal in addition to appearance of peaks...

Indeed! it is quite clear in your graph (I see that you are using phyphox as well).

Knowing the origin of this interaction would be interesting, but i am not sure that there is a way to avoid this problem I guess, it looks hardwired into the nano board architecture. A shared power line interaction maybe?

Actually, it is not quite clear to me what IMU.begin() does on a low level. Is there an IMU.end()?

Thank you for your tests,

Meilleurs Regards,


New test: IMU.begin() at 35 sec and IMU.end() at 70 sec.
Traitement de : pressure_and_motion6time.ino…

With Brest regards

The same experiment with other Arduino Nano 33 BLE sense board. Peaks on the pressure recording are even more pronounced when IMU is activated (between 35 and 70 sec).

Arduino Nano 33 BLE Sense:

Is this the IMU.begin() ?
It calls Wire.begin().
The IMU.end() calls Wire.end().

Use IMU.begin() only in setup() and don't call IMU.end(). That is not a fair test. Just turn it on in setup() and leave it on.

The schematic shows that both sensors use the I2C bus and are powered by a output pin. Also the pullup resistors are powered by a output pin.
I assume that power is less strong than the 3.3V. Perhaps the LPS22HB is sensitive for changes or noise in the voltage.

It should not happen, but I think it requires to do measurements on the board itself (voltage, noise, other influences ?).

Thank you for your response, Koepel.

I am afraid, I do not know how the wire protocol is working, so I am not following your comments about IMU.begin() and IMU.end(). It is still not clear what these instructions are doing (initializing the sensor I guess, but do they change its state or just parameterize the communication?). Nevertheless, if i am understanding you correctly, even though you have reservations about using IMU.begin() elsewhere than in the setup(), you agree that there is a problem, probably hardwired, between the IMU sensor and barometer, right?

I looked at the schematic, and as you said both the IMU and barometer (and also Temp and humidity sensor) are powered by the GPIO 049 output. I tried to figured out the power consumption of the sensors. As far as I understood the specs, the consumption of both barometer and thermometer are neglectible (some microamps), whereas the IMU will need up to 4.3 mA. It should be fine (I found a value of 15ma/digital output on internet, but I got lost in the specifications manual of the proc -- I am not a specialist of this kind of electronics obviously). As you said, it must be a question of sensitivity or noise, which would be a nightmare to figure out.

So I guess the conclusion is there is no way of measuring both the pressure and the IMU sensor without having this problem, which is too bad.

Now, if I want to use only the barometer, is there a problem using IMU.end()? Idenbom tests show that the readings are better when doing so, but Koepel comments seem to indicate that it could have some drawbacks that I do not understand...

Thank you both for your help,

Meilleurs Regards,


The processor is a nRF52840:
I can not find in the datasheet how much the pin output voltage drops with a certain current.

Yes, if it is a result of the hardware design, then it is a nightmare. You have to add an external sensor of you want good data.

The MPU.begin() does not just initialize the MPU sensor, but also the I2C bus. That is something for the setup() function and not half-way in the sketch.
The MPU.end() closes the I2C bus as well (in theory) with Wire.end(). The I2C bus might no longer work after that.

[ADDED] In the datasheet at page 156 it says that the output IOH,SD can be 2 mA in standard mode or IOH,HDH is 9 mA in high drive mode.

I gave it a try and got this result:

Doesn't seem quite so dramatic of a difference as @fbouquet, but similar. The two data sets were taken at different times, so I wouldn't assign too much significance to the offset.


Thank you in0. I do not see any problem in your data actually (I agree, the difference in absolute value may not be relevant). Your graph is perfectly OK, and I would like to have similar ones!

In my previous tries, I noticed that the size of the dips is nano-dependent, so maybe you are lucky and yours is OK? Or you did something differently that fixed the problem, and in this case I would like to know what...

Concerning the remark of Koepel about the output capacity, do we know if the high drive mode is enable for the GPIO 049 output? I couldn't find the information, and i am reaching the limit of my microprocessor knowledge quite rapidly here.

Meilleurs Regards,


The Nano 33 BLE Sense I used for the readings in my previous reply has code "49-19" on the bottom. I guess that means manufactured the 49th week of 2019.

I'm using the latest release version of all dependencies:

  • Arduino_LPS22HB 1.0.1
  • Arduino_LSM9DS1 1.1.0
  • Arduino Mbed OS Nano Boards 2.4.1

I have another Nano 33 BLE Sense with code "30-19". Here are the results:

And I did another round with the "49-19" board:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.