Barometer sensor underflow?


#1

Hi, I seem something that looks like underflow on the altitude sensor.
I;m not sure to what sea level the sensor is callibrated – but I’m fairly close to North Atlantic Ocean zero level, so in turn, my altitude might be read as negative (w.r.t. reference and/or sensor error).
From the data-sheet it seems the sensor itself should be able to do negative readings (to -698m) and I tried to track down if there is some error caused by something like uint16_t conversion, but seems both bc_radio_pub_barometer() and bc_radio_pub_decode() are handling things right, so the issue is either in gateway or somewhere else. Didn’t have too much time to track it down fully, sorry.

output from mosquito_sub

node/kit-co2-monitor:1/barometer/0:0/altitude 2.81                                                                                                  
node/kit-co2-monitor:1/barometer/0:0/altitude 1.06
node/kit-co2-monitor:1/barometer/0:0/altitude 2.62
node/kit-co2-monitor:1/barometer/0:0/altitude 0.62
node/kit-co2-monitor:1/barometer/0:0/altitude 65534.00
node/kit-co2-monitor:1/barometer/0:0/altitude 65535.12

For the last 8 hours, the sensor has stayed in the 65k range, so it wasn’t one-off error


#2

I just spent more time on this and my suspicion has moved to this

So far I cannot correlate that line with 13.2. in


but seems suspicious, as you are taking three 8uints (24 bits) into 32bit uint, without handling the case when the value is negative (encoded as 2-complement). But maybe it would work out, hard to guess without testing it.

In another doc here


it states (sec 7.1.3)

 Left shifting the
OUT_T_MSB byte by 24 bits into a 32 variable and doing a logical OR with the OUT_T_CSB byte left shifted 16 bits and a logical
OR with the OUT_T_LSB byte left shifted 8 bits gives the altitude in meters times 65536.

which is a different computation than you do and in that case you will get the sign of the OUT_T_MSB aligned with the sign of the 32bit variable (provided it’s a signed variable).


#3

Thanks for report, I fixed in sdk


#4

And I’m going to update the sdk firmware in wireless kits and build new versions.


#5

Thanks. If it’s of any help, I can confirm it behaves the expected way now