PiicoDev ENS160 Air Quality Consistently Poor

Hi Team,

I purchased a PiicoDev Air Quality Sensor ENS160 for my Raspberry Pi back in September in order to measure indoor air quality at home. The sensor is connected to the pi via the PiicoDev Adapter for Raspberry Pi. It seemed to be operating well for the first few months, returning results that make sense for the room and amount of fresh air available.

Since late December, however, the results started showing consistently poor air quality with no obvious changes to the environment.

I was able to temporarily resolve the issue by leaving the sensor disconnected for 24 hours then reconnecting and allowing the warm up period to complete, however, around 15 days later, the issue has returned.

Here are the current results using Core’s example script for a room with multiple windows open and plenty of fresh air coming through:

AQI: 5 [unhealthy]
   TVOC: 6311 ppb
   eCO2: 2153 ppm [bad]
 Status: operating ok

And for reference, a graph for the last ~30 days demonstrating the abrupt changes in reported data:


The gap at 12/29 corresponds to when the sensor was left disconnected for 24 hours.

Is there some recommended way to troubleshoot this sensor further?

Thanks

1 Like

While glossing over the data sheet it mentioned “auto baseline”. I have a cheapish AirQuality meter I got for random one off checks (not this unit) and to calibrate I needed to leave it outside in good clean air for a period of time.

Im wondering if the unit base line/calibration has drifted. Is their a way/method to recalibrate it ? The datasheet mentioned a calibrate register.

I also wonder if there may be something building up on the sensor?

These are just thoughts

1 Like

Hey @Alex279135,

The equations used for the output data both take temperature and humidity into account, see the section below for code:

(From our Getting Started Guide)

Could some changes in outside temperature and humidity be affecting your values? I know here on the east coast we have had some drastic weather changes with massive storms and whatnot.

I’m not sure how integral these parameters would be to the expected output, but perhaps worth looking into.

1 Like

Thanks for your responses.

@Zach That did actually occur to me yesterday, as I am indeed on the east coast (that second gap in the graph was due to the power being out for 12+ hours!). I tried a script including the temp/humidity values from my BME680 sensor but this didn’t seem to make any noticeable difference.

@Michael99645 Yeah, I’m not too sure about recalibrating this sensor - I am pretty new to all this stuff! I did also wonder about some kind of physical build up on the sensor. I gave it a clean with some isopropyl and a microfibre cloth but sadly no apparent change.

1 Like

Hey @Alex279135, @Michael99645,

The ENS160 in particular shouldn’t need any manual calibration at all. The “auto baselining” referred to in the documentation is an automatic function performed by the ENS160 to compensate for oxidizing gases such as ozone. It stores the value of this baseline in non-volatile memory so it will be maintained through power losses.

The datasheet makes reference to a “DATA_STATUS” flag at memory address 0x20. It’s a 1-byte register holding info on the validity of the sensor. It looks like the PiicoDev module accesses this register through a value called “status_validity_flag”, among a few other things. Can you use the following code to check these values and send the output you receive?

print(sensor.status_statas)
print(sensor.status_stater)
print(sensor.status_newdat)
print(sensor.status_newgpr)
print(sensor.status_validity_flag)

The sensor needs to be on and being used to receive the desired outputs.

Another thing you could try to confirm the sensor is working properly is to bring Isopropyl Alcohol near the sensor (or spray it lightly in the area) while the sensor is reading values. The sensor should react to this and report different values. This way we can confirm at least that the sensor is feeding data to the module, and not just completely busted.

Hope this helps!

1 Like

Hi @Zach,

Thanks again for your reply.

Please find the output of the provided code here:

python test.py
True
False
False
True
0

Regarding the test with Isopropyl, I’ll have to get back to you to confirm as I don’t have physical access to the sensor just at the moment.

Cheers!

1 Like

Hey @Alex279135,

Thanks for running that test. I’ll run you through my process (both for your sake, and anyone else who comes across this thread).

In comparing with the following table from page 28 of the datasheet, we can confirm that the sensor is running as expected (or at least it thinks it is).

Paying attention to the “Field Name” and “Field Description” sections, we can deduce the following:

  • STATAS returned True, indicating that an operation mode is running, a.k.a. the sensor is operating either in standby or in sensing mode.
  • STATER returned False indicating that no errors were detected.
  • NEWDAT returned False indicating that no new data is available in the data registers
  • NEWGPR returned True indicating that new data is available in the GPR_READ registers.
  • STATUS VALIDITY FLAG returned 0, indicating that the device is operating normally.

NEWDAT and NEWGPR don’t really give us any information, useful to know they’re functioning as expected.

I look forward to seeing the Isopropyl Alcohol test and moving forward with more troubleshooting from there.

2 Likes

Hey @Zach,

So naturally since we’ve started troubleshooting it, last night without any action or input, the sensor suddenly returned to reporting normal numbers:


You can see the drastic drop at ~20:30 which doesn’t strike me as a natural change.

At any rate, I’ve still performed the isopropyl test this morning and can confirm the sensor immediately reacted:


(Live results from the terminal actually briefly showed much higher levels, but my monitoring system isn’t getting results quite that rapidly.)

I guess it’s going to be tough to troubleshoot now that it seems to be back to normal, but if you have any further thoughts I’m happy to hear them. Hopefully it stays this way now!

2 Likes

Im just interested in this, so my comments here could be way off.

But as commented already, could it be normal.

Not sure where you live, but I do find it interesting that where I am (just East of Melbourne, Vic) My home weather station record a start of rapid air pressure change at 8pm last night. I also noted a minor pick up on the average wind speed and a more noticeable pick up in the wind guest speeds.

Im not saying is air pressure that is causing it, rather there was a change in the weather around that time (here). And we know the outside air quality can be affect by things, keeping in mind pollen and smoke from fires etc.

Did you try finding an official “air quality” report for where you live to compare to ?

2 Likes

Hi Alex
Interesting little event.
Did you turn off an air conditioner or anything like that at about 2030? If something like an aircon was running the air quality might have been actually bad due to filters need a clean or something like that. I think the quality has to be really bad to detect it just by breathing so is it possible that the sensor is telling the truth.
I admit that sudden change does look pretty suspicious. It IS very sudden even on the lower graph which I assume is an expanded version of the upper one. Almost as if you have something which is causing some sort of interference which was switched off at 2030. Even 240VAC LED lights have a little power supply in the base which can be very “noisy”. I have some of these LED down lights and when they are on AM Radio reception is nearly impossible.
Take note and you might get a clue if and when the problem returns.
Cheers Bob
PS: If interference is suspected a simple hand held AM transistor radio can be a good “sniffer” tool to try and pinpoint the source.

2 Likes

Hey @Alex279135,

Always nice when the problem fixes itself! As the other comments have asked, it would be interesting to know if anything specific in the environment changed to cause this difference in recorded output.

Otherwise, assuming the sensor continues to behave normally, I wish you the best in your future projects! :slight_smile:

Hi @Samuel,

Nope, there was no change in the environment that I’m aware of that would have caused the change in readings. I don’t have air conditioning so nothing like that making any dramatic differences to the air inside.

At any rate, I’ve actually ordered a second module to use elsewhere but if it does start misbehaving again I should at least then be able to compare using the second sensor.

Thanks for your input, everybody.

It looks like the problem has returned today, so having already received my second ENS160 module I’ve now had the chance to use them together to troubleshoot.

With the two sensors daisy chained and about 10cm apart, these are the results I’m getting. Sensor 0 here is the new one, with Sensor 1 being the older, troublesome one.

python air_quality_2.py
Sensor 0:

    AQI: 2 [good]
   TVOC: 160 ppb
   eCO2: 641 ppm [good]
 Status: operating ok
--------------------------------
Sensor 1:

    AQI: 5 [unhealthy]
   TVOC: 3440 ppb
   eCO2: 1466 ppm [poor]
 Status: operating ok

That’s gotta be something wrong with the sensor itself, right? It seems like this behaviour is triggered by genuine poor air quality (I had the place shut tight today) but it’s as though it fails to properly detect a return to normal air quality levels.

Hi @Alex279135

Looking at the different readings it is likely that the sensor is faulty, if you respond to your email confirmation one of our support team will be in touch.

Hey @Dan,

Thanks for the reply. Could you clarify which email confirmation you’re referring to?

Hi @Alex279135

If you have your original order confirmation, you can respond to that. Otherwise you can email on support@coreelectronics.com.au

Thanks, Dan. I’ve responded to that email now.

1 Like