What do I do with reading outside the 260 - 1260 hPa range of the LPS22B sensor?

[cjwilde]

The LPS22HB has an absolute pressure range of 260 - 1260 hPa. It's possible for the 24-bit pressure output value to fall outside that range. A value < 0x104000 is below 260 hPa, and a value above 0x4EC000 is above 1260 hPa. What should I do with a value outside the absolute range? In my application, I occasionally see values outside the range on two boards, but not on the other boards.

[Eleon BORLINI]

Hi @cjwilde​ ,

in theory, the LPS22HB full scale is capable to cover up to 2bar of dynamics. However, in practice the linear dynamic range is limited by the MEMS sensor, and is the one declared in the datasheet, i.e. 260 - 1260 hPa. Out of this range, the linearity of the MEMS structure is not guaranteed, as well the 4096 LSB/hPa sensitivity.

My question is however another one: are you testing the atmospheric pressure and are you seeing this huge out of range values? Or are you running experiments and you are also checking a reference pressure sensor?

-Eleon

[cjwilde]

Eleon,

We are readingthe atmospheric pressure in a pressurized compartment on an airplane during a flight. I should see pressures from about 756mbar(~2440m) to 1013(0 m). In my code, any value outside the range of 57(20,000m) - 1100(-413m) mbar is considered an error, and a counter is incremented. The ODR is set to 1Hz, the BDU bit is set, the FIFO is in Bypass mode, and the pressure is read every second. On two of our boards we see thousands of pressure errors reported, so the value read from the sensor is either too low or too high in terms of mbar/hPa. We don't know if we're getting lots of single errors or a smaller number of continuous errors. There is no debouncing of the pressure value, so a single bad reading will increment the error counter. Could we have a race condition where we read the data as it's changing?

We don't expect to ever see these errors. If we do, we have to assume that the sensor is bad. I'd like to hear your thoughts on our assumptions.

[Eleon BORLINI]

Hi @cjwilde​ ,

that could be an issue of the sensor, for sure. But let's check the acquisition code. How are you reading pressure data, in polling mode or in one shot mode?

• In the first case, I suggest you to check this sample code --> lps22hb_read_data_polling.c
• In the second case, you should check instead this other code --> lps22hb_read_one_shot.c

For the FIFO example, see the --> lps22hb_multi_read_fifo.c

-Eleon

[cjwilde]

Eleon,

After further consideration, I think it’s unlikely the sensor is returning bad values, and it’s more likely our acquisition code is wrong as you suggest. We’re using the polling scheme. We assumed that since we set the ODR to 1Hz with BDU set, and since we read the sensor every 1 second, the data will always be there. Our acquisition code does not check the STATUS register to verify that new pressure data is available. A couple questions here:

· If we read the pressure before a new value is ready, will we read the old value or some indeterminate value?

o Is it possible we would see an I2C error if we ready before the data was available?

· Since we want to read the pressure once per second, does it matter whether we use the one-shot mode or the polling mode? It seems like the one-shot mode might make more sense for us.

[Eleon BORLINI · Accepted solution]

Hi Chuck @cjwilde​ ,

That makes sense.

>> If we read the pressure before a new value is ready, will we read the old value or some indeterminate value?

It depends. Usually, you will read the old value, but if by chance 2 of the three output registers were updated and the last one would not, you will concatenate strings of bits from different readings, this resulting in a pretty random number. Note that the ODR (1Hz) could slightly vary from device to device (being e.g. 1Hz for DUT1 data and 1.05Hz for DUT2 ones), so your code (with constant delays) could work for the majority of the samples, but could fail for a limited number of other devices.

>> Since we want to read the pressure once per second, does it matter whether we use the one-shot mode or the polling mode? It seems like the one-shot mode might make more sense for us.

You are right, I believe that the one-shot mode makes more sense for you application, and it might help you to save power during the application cycle. For completeness, you should check the P_DA bit of the STATUS (27h).

Or you might characterize "a priori" the actual ODR for every device and then, but I believe this is an "expensive" activity.

Or otherwise synchronize the acquisition using the embedded FIFO (e.g. lps22hb_multi_read_fifo.c), but the code might be a little more complicated.

-Eleon

[cjwilde]

Eleon,

I will revise my code to use the one-shot and the P_DA bit in the STATUS register. Thank you for help. I selected your reply as Best.