CCS811 Sensor Always Reporting 65535 On RPi

I have a CCS811/BME280 sensor plugged into a Raspberry Pi Zero. (https://www.sparkfun.com/products/14348)

I am trying to get the the CCS811 sensor to work in Python, using Sparkfun’s libraries. (https://github.com/sparkfun/Qwiic_CCS811_Py)

At this point, even when I simply download and run the supplied examples, I get the same output for both CO2 and TVOC:

$ python qwiic_ccs811_ex3.py 

SparkFun CCS811 Sensor Example 3 - NTC data to CCS811 for compensation. 

CO2:    65535.000 ppm
tVOC:   65535.000 ppb
Measured Resistance: 9950.000 ohms
Converted Temperature: 25.11 deg C

Once, I have seen non max-int values output, but I hadn’t done anything different. I just stopped and started some code, and it output normalish looking values. Every other time I run the code, I get 65535.

What does this mean? I don’t see any particular errors being reported.

(Separately, I am also getting weird values off of the BME280, but that’s a question for a different thread.)

Thanks for reaching out to us on this.

65535 is the 32-bit binary integer 00000000000000001111111111111111

The product page mentions:

Note: Please be aware that the CCS811 datasheet recommends a burn-in of 48 hours and a run-in of 20 minutes (you must allow 20 minutes for the sensor to warm up and output valid data).

Please refer to the hookup guide for help getting started, found at: https://learn.sparkfun.com/tutorials/cc … 1615791300

Hope this helps, and happy sparking!

Interestingly, I ran the example again just now and it appears to be outputing more reasonable values:

CO2:    400.000
tVOC:   0.000

CO2:    400.000
tVOC:   0.000

I don’t know why its so consistent at 400 ppm for CO2, but maybe that’s expected? If I breath directly on it, I temporarily get different values.

Thank you for posting this. I am getting the same thing (65535). I ran it for 48 hours but was only reading every 30 minutes so maybe it needs to run/read at a greater frequency. I assumed if it was on it was burning in regardless of whether i was reading data off the sensor. I am running an example that reads the data every second and will let this run for a while and see what happens.

Over two days of running straight of running example 1 . Still getting 65535. Any help would be greatly appreciated.

The CCS811 is known for using clock-stretch. The RPI is not good at handling that. Try to lower your speed to 35Khz. Also see https://github.com/paulvha/ccs811

Thank you Paul. You are a genius! I am not very familiar with C.

I have a Rasperry Pi 2 with the Rasperry Pi OS with the Sparkfun Qwiic Starter Kit which uses the environmental combo. I was trying to use the Qwiic Kit for Python example code (https://github.com/sparkfun/Qwiic-Kit-f … pi_demo.py). This resulted in the 65535 issue. Your notes were right the environmental combo breakout was not doing the clock-strech. When using The CS811 python code from Sparkfun (https://github.com/sparkfun/Qwiic_CCS81 … _ccs811.py) to try to isolate the issue it would complain that clock stretching wasn’t working when I ran the begin function despite the fact i had followed all the directions. If I added another begin function to the code it didn’t complain so I thought that had fixed it but perhaps it was a more fundamental issue. I was getting the temperature and humidity using the example python code for the Qwiic Kit but not the C02 or CO2.

I was able to get the CO2 and TVOC to read using your code (https://github.com/paulvha/ccs811) and directions. As I found no way to enable device tree via the raspi-config (per http://www.airspayce.com/mikem/bcm2835/) I added the following to my config.txt and it seems to work: dtoverlay=overlay-name,overlay-arguments

I will have to say the level of effort needed to get to this point makes me feel that the Starter Kit for Rasperry Pi (https://www.sparkfun.com/products/16841) is not worthwhile for a beginner such as myself. The CS811 sensor is ill suited for use with old Rasperry PI models such as the 2 which I have due to the clock-stetching issue. A caution in terms of Rasperry Pi models indicating this on the product description page would have saved me a lot of effort and frustration.