CCS 811 sensor drifting
I’ve logged the CCS811 eCO2 values over 24 h, using the 10s acquisition PULSE mode of the MEAS_MODE.DRIVE_MODE register bit field. It looks like the internal algorithm is not so well able to cope with humidity changes, as soon as humidity drops (when opening a window), the eCO2 values start drifting. The hardware/firmware specs:
The air quality in the room is somewhat constant and should normally range between 400 and 800 ECO2 pseudo-ppm.
In the examples below, no environmental on-sensor compensation (using the ENV_DATA register) is used.
In all cases where too much drifting was registered, the sensor DRIVE_MODE was reset to Pulse (2). You can then also see that the RAW value is then at a different offset.
The sudden humidity changes seem to be problematic, obviously. Since the raw values don’t change much during the continuous measurement interval (without restarting/rewriting DRIVE_MODE) , this would suggest that the firmware is somewhat mislead and keeps adapting its values.
The app note AN369 mentions the handling of the BASELINE register in paragraph 17. This is to be experimented with next.
T/H Environment compensation
The Write-Only (!) ENV_DATA register should, according to the HW reference, allow compensation of the humitidy. However, first attempts made the measurements go completely haywire and oscillating. This is currently under scrutiny.
It looks like that only a more or less constant humidity makes the sensor operate in a sane range. Otherwise, the high eCO2 values can not be trusted whenever the humidity rises rapidly. I guess this is a somewhat unwanted property of any SnO2 gas sensor and it can be quite difficult to adjust without knowing the parameters. However in this case it seems that the firmware is doing some internal adjustment that is still somewhat not understood.
The BASELINE register is somewhat obscure and undocumented: Some MSBs seem to be flags, the LSB some offset value. The AN tells you to just write back a ‘known’ baseline from clean air. However, I’d assume that for a proper measurement you’d have to record a set of baselines corresponding to environment T/H values to figure out which to write. Not there yet…
Conclusion / possible way out
Whenever the humidity is changing rapidly, the current strategy is:
- Wait until humidity has settled and try resetting the BASELINE to a ‘known good’ state
- Rewrite DRIVE_MODE to the previous value and wait a certain settling time
Resetting the baseline according to the AN sometimes works, sometimes produces completely unusable results. It is still a bit of a mystery why the ENV_DATA compensation does not work as ‘promised’.
I’ll probably post more findings here.
2 thoughts on “CCS811 sensor review”
Hi, did you managed to investigate this issue any further?
I’m also facing the same issue, i’m going to try today to compensate the temperature and humidity, but as i read i will probably don’t get any luck with this, i was really hoping this sensor to have acceptable readings but 2000+ spikes are really not acceptable.
unfortunately, I haven’t got past the behaviour of this sensor. So far, AMS has ignored my support requests. I have had a go at reverse engineering the built-in firmware to get a better idea on the arbitrary behaviour, but it seems that the sensor can only operate in an environment which is controlled and cross-checked by a proper reference (this not being a CCS811).
I am under the impression that one would be better off using a bare metal sensor with own logic/intelligence. This sensor unfortunately turned out to cause too much pain…