Data Accuracy and units of data of the EnviroPHAT

What is the accuracy of the different values of the EnviroPHAT?

I found the temperature and pressure to be inaccurate (changing between two measurements in a short time) at the third decimal place. The analog pins without anything connected are at most accurate to 2 places, but maybe it’s more stable if they have some pullup/pulldown attached.

What about the other inputs? And what is the unit of light and accelerometer data? And how is the accelerometer data collected, is it averaged over the acceleration / speed of the last few seconds?

There’s no simple answer to this question, since the datasheets for the various sensors define accuracy ranges that vary under certain circumstances. As briefly as I can, though:

Temperature/Pressure BMP280

  • The BMP280 is accurate to ±0.5° at 25°C, and between 0 and +65°C the accuracy drops to ±1°. Below 0 and above 65°C appear to be undefined.
  • Pressure is accurate to ±1.0hPa between 300 and 1100 hPa at 0 to +65°C - extremes of temperature/pressure affect accuracy beyond these ranges.

Analog ADS1015

  • The analog pins are floating by default, and thus wont give any even approximately sane readings unless they are tied to VCC or GND, or to a sensor.

The ADS1015 is a differential capable 12bit ADC but we use it in single-ended mode, dropping the sign bit gives 11bits of accuracy for 2048 possible readings. Divide the max input voltage, 3.3 ( expressed in mV ) by this number and you get the smallest possible increment of ~1.6mV.

Accelerometer / Magnetometer LSM303D

This LSM303D is configured to a scale of ±2G, Values output should, in theory, be in Gs. A magnitude of +1 or -1 on any axis suggests that it is aligned “down”.

Light ( Actually colour and clear ) TCS3472

I’ll have to get back about this one, it’s actually a colour sensor with a clear channel for scaling the colour values against.

Apart from sampling happening at the device level, no averaging is done on any of the values. This kind of damping is left as an exercise to the user, since the accuracy/speed tradeoff is not one I’d want to be opinionated about!

Thank you so far. I am building some kind of data logger currently. I used two digits for temperature, pressure, heading and acceleration now (seemed the range where it may be stable) and 3 digits for analog pins (just because it returns them).

For light i noticed, that daylight is in the range of 21000 (currently) while artificial light gave me 80. Not sure if the readings are really comparable or if there is some dependence on the spectra as well.

just to add to this, or rather expand on @gadgetoid parting comment:

… while not strictly mandatory it is indeed pretty much always a good idea to ‘smooth’ data when using sensors to display anything past the documented accuracy (IMHO anyway).

Essentially, ‘smoothing’ means taking multiple readings over a short period of time and averaging them. The alternative is to truncate the data and not care about the decimal point(s). If you google ‘sensor smoothing’ it should return a lot of things to inspire yourself from, or as a starting point to meaningful ways to do this.

I guess smoothing over inaccurate data gives more or less the accuracy on truncation anyway. Given that the noise has some standard distribution.

sorry to take this olds post, but i have a question in which part of the answer is in thise tread.
here is written:
This LSM303D is configured to a scale of ±2G,

is possible to change that to ±16g??
if yes, how??
thank you

You would have to edit the library and change the setting for CTRL_REG2:


self.i2c_bus.write_byte_data(self.addr, CTRL_REG2, (3<<6)|(4<<3)) # set full scale +/- 2g

Note the 4 in place of a 0.

Or possibly add:

envirophat.motion.i2c_bus.write_byte_data(self.addr, envirophat.lsm303d.CTRL_REG2, (3<<6)|(4<<3))

To the top of your existing code instead.

thank you!!!
on the same library, i did notice at line 73
ACCEL_SCALE = 2 # +/- 2g

this should not change too?

Thank you

Ah, yes, it should! I don’t believe the chip does anything weird with scaling, so that should- hopefully- give sane output. Now all you need is 16Gs of acceleration to test it with :D

thank you
i did change and i think there is something weird with the scaling ( i get 0.6, when should be about 1)
but is just testing…so, the direction is right…

about the 16 Gs…don’t worry just need to wait for the winter to go…and 5…4…3…2…1…
stay tuned

just another question, if i wish to change the acceleration to ± 8G, what shall i input?

thank you

You can find the full- daunting though it may be- datasheet here if you fancy a loooooong read:

But for brevity pages 35 and 36 detail the bits you need to know:

  • 0b000 = ±2g
  • 0b001 = ±4g
  • 0b010 = ±6g
  • 0b011 = ±8g
  • 0b100 = ±16g

And in all cases this is where the acceleration scale value should be plugged in:

acceleration_scale =  0b011
self.i2c_bus.write_byte_data(self.addr, CTRL_REG2, (3<<6)|(acceleration_scale<<3)) 

Did you have any luck changing it on the fly? Might be a worthwhile feature to plumb into the library if I can get some sensible test readings… wheeling around on my office chair, maybe?

1 Like

Thank you so much for your answer!
i see some light!
i did read the datasheet, but my programming knowledge is not enough to get the “0b100” setting in.

What i did is to install the Raspberry piZero /enviro HAT on a wood plate, and to test acceleration, i literally swing it around!

so i got great numbers:
while not moving i get value of “1” on the vertical axis (earth acceleration)
while moving ( with saturation, expected) for 2g, 6g and 8g i get also “probably good” number.

for 16g looks somehow strange…
in not moving the value is about 0.6…
while moving the graph are on the same side…
maybe something to do with “ACCEL_SCALE = 16” ??
i will look in how is used

and why i whish to measure 16g?
i will use the enviro pHat in one of my model rockets
Enviro Phat has all: accelerometer, barometer and some Led’s…
so i whish to record the flight with!
minimum acceleration is 5g,i expect my model to go with about 8-9 so 16 fits well…

if the recording are good, then i can add program function while learning: apogee, altitude,…
( non flight/safety relevant for the moment)

I’m sure ACCEL_SCALE = 16 is correct.

The X, Y and Z values are 16bit signed integers, which makes them -32768 to 32767, each axis is divided by 32768 to give a 0.0 to 1.0 range (or close enough) and then that range is multiplied up by ACCEL_SCALE to give acceleration in Gs.

I can’t find anything in the datasheet to explain the weird readings you’re getting.

1 Like

Thank you
i will look and test :)
nothing can be damaged ( i think)
and with your explanations i get to understand the code more and more.
I will look too my code, if it doesn’t do anything messy with the numbers, although i never change it between differents Gs…

if i find something i will let you know, if not i will fly it and see what comes out ,)

Hello again

  1. I cannot find anybody using the sensor at 16g. No idea why?

  2. i could find another library and SW example in python. Very similar to Pimoroni but at 16g i get same results! so isn’tt the library or my small SW that screw up…

  3. either is my sensor-raspberry zero somehow broken or else. But at 16g it seems always to give out a 0.67 g on the vertical axis…( i should get a new enviro phat soon). As soon i set scales at 8g, all seems finer.

  4. I have hard time to see any error in the library. It all make sense.
    So either there is something missing (does sensitivity play a big role?) or somewhere there is a logical error so big is not to be seen…

edit: mine are all positive intented comments, i have a huge fun try out the enviro Phat and python…i learn a lot…so if i don’t get it running i will not be disappointed! just learning :)
i don’t think that the enviro phat has been deisgned for 16g…but i will try it out… and see…

so, i’m a stubborn engineer…so i don’t give up till i get it… :)
( i did work for years as troubleshooter…so…)

today try and findings:
first i wanted to see raw number, so i cut out the calculation in Gs.

by this i get raw numbers from the sensor
in my setup, Y axis is vertical

so i set up, as posts above 2 g, maximum scale 2g, ACCEL_SCALE = 2 ( even if ACCEL_SCALE scale doesnt play anymore a role)
i get good logical numers… max scale is 2-> 32768
1g -> about the half

did the same for 4g
should get a quarter of 32768

same at 8g

and 16gs…
expected is about 2000

which when i convert it as the library i get same numbers as post above…(about 0.6xx Gs)
so now:
why about 1300 and not 2000?
sensor bug? sensor gone mad??
the only spot i may imagine could be still to be worked, SW side is where the register with the scale is written…let’s see how i screw it up there, altough it does work with lower Gs…

got today a new enviro Phat from Pimoroni…so i will solder it and see if stay the same…

if not…i will have to find a proper conversion number to get the 16g reading…

Following this as I’ve just gone back to playing with mine (did you post about rockets on RPI forum?)

I have my Envirophat stacked above a SenseHAT to compare.
Just altered my logging program to include the Envirophat and a quick log and i’ll have to play around with the G range as they are both different and on is inverted to the other one.

That’s as far as I got.

I wonder if this is intentional, to prevent these chips being used in exactly the type of scenario you’re trying to use them- or rather more nefarious variants therein, anyway.

Looking at the datasheet, it also defines the LSB value at ±16g at 0.732millig


32000 / ((2^16)-1) = 0.48828870069

It also lists zero-g level offset accuracy at -+60mg but that’s not nearly enough to explain your 0.6g offset.

I wonder if scale comes at a tradeoff with data rate?

Try changing the line:

self.i2c_bus.write_byte_data(self.addr, CTRL_REG1, 0x57) # 0x57 = ODR=50hz, all accel axes on ## maybe 0x27 is Low Res?
self.i2c_bus.write_byte_data(self.addr, CTRL_REG1, 0b00110111) 

This should switch the output data rate to 12.5hz. The rate is the 4 most significant bits of that binary number, ie: 0bXXXX0000

Available rates:

  • 0b0000 = off
  • 0b0001 = 3.125 Hz
  • 0b0010 = 6.25 hZ
  • 0b0011 = 12.5 Hz
  • 0b0100 = 25 Hz
  • 0b0101 = 50 Hz
  • and you can probably see more or less where this is trending now :D