BME680 altitude trending the opposite of what I would expect

I'm experimenting with the altitude readings from a BME680. My code is effectively as simple as this (using the Adafruit BME680 library):

#define SEALEVELPRESSURE_HPA (1013.25)
bme.readAltitude(SEALEVELPRESSURE_HPA)

Seems basic enough? The problem is the altitude readings go down in a linear progression, even as the device itself goes up from one floor to the next, and stays on that floor for hours at a time! At this point I don't even care about the absolute altitude, I just want the relative altitude to make sense.

RED line is altitude in the graph. What am I missing?

If the pressure values increase (green line), the estimated altitude must decrease, so the code is working correctly.

The question is: why does the pressure seem to increase, when you move up a floor? In a sealed building, that could be the HVAC at work.

Yeah that's an interesting thought. The problem is this is in my house which is powered by a single HVAC system and the floors are all open to each other. I wouldn't expect to see these values within what I would classify as a "box" of my house :).

Does the temperature also go up as you move up a floor?

Not really - it stays pretty stable:

It might be worth trying it outside. At worst, you could poke it out of a window on each floor to eliminate HVAC impacts.

Unfortunately I'm actually trying to measure indoor altitude. Basically I'm trying to see if I can build an indoor asset tracking system that measures x,y,z coordinates with GPS (if available), wi-fi triangulation (if no GPS lock), and a 680 for altitude. I'm concurrently testing the new BMP581 which advertises extremely precise altitude measurements, but I'm hitting the same inverse altitude data issues.

Maybe what I want to do is literally impossible because of how an HVAC system can impact pressure changes?

I haven't worked with the BME680, but other pressure sensors I've used are fairly noisy, and averaging over a number of measurements is required to get reliable values.

I suggest to average 30 to 100 measurements, over a period of maybe 30 seconds in one location, then move up.

I'd still be inclined to try it outside, to prove to yourself that you're using the sensor correctly.

1 Like

Yeah, tried that too. In fact the graphs shown above use the median values from 50 consecutive readings that are taken about 50ms apart. :man_shrugging:

The temperature shows the inverse trend as the pressure, except at the very end.

Internally, those sensors use temperature compensation when measuring the pressure.

You may have a defective sensor. The LPS25H works well for me, and I can easily measure a change in elevation of 1 meter, inside the house.

Pressure and altitude are inversely correlated using the hydrostatic method.
Is the altitude change correct in absolute terms? If so, there may be a missing negative sign somewhere.

BTW, nice graphs. How did you plot them out?

I don't think it's accurate in abs terms either - looking at the top and bottom ranges it thinks I live in a 60m tall house :).

The dashboard is created with Datacake. Great platform!

Sounding more like a faulty sensor.

The prelim view of Datacake looks great. Thanks for the tip. :+1:

I believe the temperature compensation you refer is part of the sensor calibration that is effected by the temperature of the sensor. I do not believe they use the temperature to adjust the outputted pressure and altitude. How would the sensor be able to know whether the pressure change is due to an actual change in the baro pressure, altitude, ...

Those absolute pressure sensors work by measuring the volume of a sealed chamber. Both the temperature and the volume must be known in order calculate the pressure, using the Gas Law:

PV = nRT

I was of the understanding that the MEMS sensors used the change in capacitance due to the pressure on the membrane, poorly said but I think this https://www.avnet.com/wps/portal/abacus/solutions/technologies/sensors/pressure-sensors/core-technologies/mems/ might be a little more illustrative.

Ideal gas law would be a poor approximation in ambient atmosphere.

You are joking, of course.

16mpost #18

You are joking, of course.

If the ideal gas law was a better approximation than the strain gage method they would probably use it. There is a strong market drive for highly accurate baro sensors, for apps like locating people within a building to better estimates of altitude for unmanned air vehicles.

If they were to use an ideal gas law approximation they surely would not use R but a molecular form of the constant.

All of this is not germane to my original post where I addressed the issue of temperature and how it used in the MEMS baro sensors. I stand by my original theses of how temperature is to compensate the sensors, not calculate the pressure directly.

The world has moved a long ways beyond the ideal gas law.

Signing off,
wade

@roblauer
Have you tried the dfrobot library?

I have had quite consistent altitude results with this library, but it has a few other issues...