Reliability of measurements

[bfaliszek]

From yesterday, every 10 minutes I take measurements (NodeMCU + CCS811). In the code I have delay (300000);. I send measurements to my InfluxDB database. I visualize them using Grafan. Here are my measurements from the last 24 hours.

• A few minutes after midnight I restarted the NodeMCU, because the measurements seemed too high. After the reboot they dropped significantly.
• It is strange that at night, with the windows and doors closed, there has been no increase in CO2 levels. I have poor ventilation in the flat, so it should be significant.
• TVOC and CO2 levels seem to be strongly related. Which is rather strange.

Does CCS811 require any additional calibration? Do I only have such strange measurements?

[maarten-pennings]

Hi, I'm not sure what I should answer, you have many hidden questions :-)

The CCS811 does not require calibration. But it does need to be "burned-in". This means that after around 1 week the sensor is more stable. However, the internal controller knows about this burn in period and compensates. Especially firmware version 2.0.0 is improved here. Which fw do you have? The example ccs811basic prints it.

The CCS811 is a so-called MOX sensor. This class of sensors has a chemical reaction with the gases (an oxidation/reduction). But not all gasses react with the sensors. Most "Volatile organic compounds" react. This is the TVOC reading. But the sensor is insensitive for CO2. The trick is that the CO2 reading assumes the sensor is inside a building (iAQ - indoor air quality), and that humans are the (only) producer of CO2. So the gas sensor measures VOCs, assumes they are from humans, maps that to the amount of humans, and then maps that to the CO2 they would produce. So yes, TVOC and CO2 correlate.

[bfaliszek]

Thank you for the comprehensive information. Especially about the correlation of TVOC and CO2.

I have a new CCS811 sensor. I just uploaded the firmware - https://github.com/maarten-pennings/CCS811/tree/master/examples/ccs811flash

In a few days I will send a new screenshot with measurements.

[maarten-pennings]

So the "flashing of new firmware example" worked? I only had one Chinese board with old firmware, so I could not do much testing.

[bfaliszek]

Yes. It worked on my Chinese board without a problem.

[maarten-pennings]

Thanks for the info - gives confidence!

[rovale]

Hello! This repository looks amazing, well documented! I will try the firmware update. Did you find any release notes for the new firmware?

[maarten-pennings]

Thanks for the compliments. No, I didn't find any release notes of the firmware... (pity). Let me know which board you have and whether the update works. I now have a 100% success rate but only for two boards :-)

[rovale]

Hi Maarten! Success! 👍 3 out of 3!

I also got a Chinese one, I guess. I bought it at a web shop close to you: https://www.tinytronics.nl/shop/en/sensors/temperature-air-humidity/ccs811-air-quality-sensor

I flashed it with an ESP32, a LOLIN D32. Your library does not work with the 1.0.0 release of https://github.com/espressif/arduino-esp32 but it does work with the latest master.

Again, thanks a lot! I will definitely use your library for my IoT project.

[maarten-pennings]

Thanks, so now a flash success rate of 5 out of 5! And you flashed with ESP32, also new!

I was a bit puzzled by your ESP32 remark. Are you saying that Arduino with ESP32 and CCS811 version 1.0.0 does not work?

When I had my Chinese CCS811 (1.0.0) board attached to an ESP8266 on Arduino it didn't work the first time. The 1.0.0 firmware had an incompatibility with my driver, so I added some driver code to support 1.0.0 sensors. I would expect my updated driver to work with 1.0.0 ccs811s irrespective of the host (ESP8266 or ESP32). Do you know why ESP32 doesn't work with 1.0.0?

And yes I know TinyTronics, I just got some stuff there, picking it up by bike :-)

[rovale]

Hi Maarten, I flashed only one making your success rate is 3 out of 3, still 100%!

I was a bit puzzled by your ESP32 remark. Are you saying that Arduino with ESP32 and CCS811 version 1.0.0 does not work?

No, I wanted to tell you that your CSS811 library doesn't work with the 1.0.0 release of the ESP32 Arduino Core (https://github.com/espressif/arduino-esp32). It does work with the latest github master.

I want to start using the latest master anyway, because the 1.0.0 release has some trouble with WiFi disconnects which might have been solved in the upcoming 1.1.0 release. I see there are some commits related to that.

I really like TinyTronics. I had some mail conversations with Loek over the years, he is always so helpful.

[bertrik]

A bit off-topic, but I just like to mention that I also just successfully flashed a CJMCU-811 board from 1.1 to 2.0. I compiled it using platformio, I ran it on a wemos d1 mini (ESP8266).

Also I just noticed that the upper range in TVOC appears much larger now. With the sparkfun library I tried earlier, it saturated at a value of 1156. But now with this library and with the updated firmware, it appears it can go much higher. It appears that it's the firmware update that fixed the upper value issue.

[maarten-pennings]

Thanks @bertrik for logging the result (platformio is a new environment, so good to know).

[bfaliszek]

@maarten-pennings I just got a Chinese sensor CCS811 HDC1080. Do you know if I can upload a new firmware for this sensor?

[bertrik]

If you run the ccs811basic.ino example and open a serial console at 115200 bps, you should see it report the 'application version' after rebooting. If this is lower than 2.0 you can flash it with a newer firmware. If it's already updated to 2.0, the firmware update sketch does nothing (skips the update).

[bfaliszek]

@maarten-pennings I just got a Chinese sensor CCS811 HDC1080. Do you know if I can upload a new firmware for this sensor?

I just uploaded the firmware to 2.0. Everything went without problems. CCS811 and HDC1080 works OK. I plan to compare the data from two Chinese CCS811 boards(one with HDC1080 and second without HDC1080)

[maarten-pennings]

Successful CCS811 firmware updates:

#	Person	When	Board	Host	IDE
1	@maarten-pennings	2018 Dec 5	ams eval kit	ESP8266 (Robotdyn)	Arduino
2	@maarten-pennings	2018 Dec 7	CJMCU-811	ESP8266 (Robotdyn)	Arduino
3	@bfaliszek	2018 Dec 17	CJMCU-811	ESP8266	Arduino
4	@rovale	2018 Dec 28	CJMCU-811	ESP32 (LOLIN D32)	Arduino
5	@bertrik	2019 Jan 03	CJMCU-811	ESP8266 (d1 mini)	platformio
6	@bfaliszek	2019 Jan 04	CCS811/HDC1080	ESP8266	Arduino

[bfaliszek]

Measurements from the last 12 hours. Performed every minute. Sensors connected to two different ESP8266. Identical code. I do not understand these differences in measurements. Before 12:00 o'clock I turned off and turned on the ESP8266 again. The data after restart is much lower than before. Even after a few minutes of sensor work.

• CCS811 (Chinese PCB, FW 2.0) – CJMCU-811 – Yellow
• CCS811+ HDC1080 (Chinese PCB, FW 2.0) – CJMCU-8118 – Green

PS: WAK pin connected to GND.

[maarten-pennings]

Hi @bfaliszek, you have two issues.

First of all, you notice that the two sensors give different readings. What you should know is (quoting data sheet) "metal oxide sensors do not give absolute readings". Yes they pretend with their CO2 and TVOC registers, but they don't. They measure the resistance of their metal oxide layer, and then check how much that deviates from normal resistance, and that deviation maps to a CO2/TVOC readout. The problem is with this normal resistance, quoting the data sheet again " The resistance RS varies from sensor to sensor (manufacturing variation), from use-case to use-case, and over time." Bottom line, all sensors give a different CO2/TVOC reading, but when it goes up it at least we know air got worse.

Second issue you bring up is the drop in readings after power cycling. This has a similar background. Again quoting the datasheet on the aspect that clean (normal) air resistance varies: " To mitigate this problem, the output of the sensor is normalized: RS is divided by RA. The value of RA is known as the baseline. RA cannot be determined by a one-time calibration; it is maintained on-the-fly in software". By power cycling, you effectively remove the clean air knowledge built up by the sensor: if you power a sensor on in bad air, it only has that as a a reference and considers that as clean.

See the section "Manual Baseline Correction" in the datasheet.

I did not yet put in support for baseline backup and restore in the driver...

[bfaliszek]

@maarten-pennings Many thanks for the answer. I am getting ready to read the datasheet.

If I understand correctly, if I would like to get more "absolute readings", then I would have to restore the Baseline value from perfectly clean air, after each reboot of the sensor.

[maarten-pennings]

Indeed. It will not be absolue readings, but at least the reading before and after the power cycle will be the same if you get the baseline before power down, and restore it after power up.

(and that is not yet in the driver ... so you have to add that yourself and mail it to me :-) )

[maarten-pennings]

Hi @bfaliszek, there is a new release of the driver, it has baseline get and set. Not yet tested. Test should be:

• sensor on for more than 20 min (run-in) in clean air, get baseline
• take empty bottle and put drop of alcohol in
• switch sensor off, put in bottle, and switch back on. Internal baseline is reset but no wait for run-in needed because sensor was only of some seconds
• read tvoc, will be reported as none/clean air (because the sensor woke up in dirty bottle)
• Do set baseline and read again tvoc, should now be very high.

Good luck - and if you test, please let me know.

[bfaliszek]

I did the test. Saving the baseline works. A few days ago I got MH-Z19, so I decided to compare CO2 measurements. I assumed that the measurements from CCS811 will be slightly different (eCO2 vs. CO2), but the trends will be maintained and when the values from MH-Z19 will increase, the values from CCS811 will also grow. However, it did not happen. I put the CCS811 in clean air for 30 minutes to keep the right baseline. Then I changed the code so that ESP8266 would restart every 15 minutes (not to save the new baseline). Here are the results from the last 48 hours.

• CCS811 (Chinese PCB, FW 2.0) – CJMCU-811 – Green
• MH-Z19 - Yellow

[maarten-pennings]

Thanks for checking the baseline save and restore.

The MH-Z19 is an absolute CO2 sensor, the CCS811 is a relative VOC sensor. That is hard to compare. They really measure different things. By the way, strange to see that several CCS811 spikes coincide with MH-Z19 valleys.

Your MH-Z19 readings are, for me, counter intuitive. The bad air builds up from around 16:00 till 9:00, where it sharply drops to clean air. Is this sensor in an apartment, where people come home at 16:00, the sleeping room is connected to the living, and you ventilate at 9:00 when you go to work... ?? Also, CO2 ppm levels above 1000 start to induce health problems (drowsiness, headaches).

Did I understand that you restart the CCS811 without baseline save and restore? That does not sound wise. Assuming your air indeed gets worse and worse (as the MH-Z19 indicates), the CCS811 would assume every 15 minutes - when it is re-powered - that the then measured air is clean air. So restarting a CCS811 is a good recipe for getting a flat line (with incidental spikes within the 15min periods).

[bertrik]

Perhaps this is a person wearing perfume/aftershave walking past the sensor and then opening a door. The perfume would increase the TVOC reading, while opening the door would decrease the CO2. Just a guess...

BTW, I'm pretty sure that the MH-Z19 is in essence also a kind of relative sensor. It also uses an automatic baseline calibration algorithm to determine the lowest CO2 reading over 1 or 2 days and adjust that to 400 ppm (the assumed outdoor value). Here are some images of the insides of a MH-Z19: https://forum.mysensors.org/topic/7761/mh-z19-teardown and it looks like it basically just has a single infrared light path, with the light going from the light source, through the gas cell, then reflected against a curved mirror and finally through an infrared filter onto a photo detector.

[bfaliszek]

The bad air builds up from around 16:00 till 9:00, where it sharply drops to clean air. Is this sensor in an apartment, where people come home at 16:00, the sleeping room is connected to the living, and you ventilate at 9:00 when you go to work

That's exactly what it is. Readings are made in the bedroom. The decrease of readings in the case of MH-Z19 means ventilation of the room.

Did I understand that you restart the CCS811 without baseline save and restore? That does not sound wise.

I restart CCS811 and load the baseline (the last one was made is the one with clean air). That's why I thought that CCS811 will show similar trends as MH-Z19.

[maarten-pennings]

I restart CCS811 and load the baseline

You say the baseline. So a baseline you once made, and then restored every time? If that would work, than that would be called calibration, and it would be done once. The whole problem is that the baseline changes (due to chemical reactions in the mox transducer). That is why the chip keeps track of the baseline.

By the way, the CCS811 also has a "Conditioning Period (Run-In)" (see the section of that name in the datasheet), which essentially means that the sensor is only stable after 20min.

So, I would suggest: let it run, don't restart it. If you want to restart, take longer on-periods (>> 20min); restore baseline after the run-in (so after 20 min), let it run for a while, and back-up baseline before power cycling.

[bertrik]

I've been logging both the reported TVOC en eCO2 level on a CCS811 with up-to-date firmware. My ESP8266 software uses a BME280 to correct for humidity and temperature. It saves the baseline value once every hour (and restores it on startup). I saw a sudden drop last night in both levels that I can't explain in terms of sudden changes air in quality.

I guess this is the automatic baseline algorithm adjusting itself. Are you also seeing this? The levels do seems pretty constant (not continually increasing or anything like that). Possibly this happened about 25 hours after re-powering it. The peak happened because I was teasing the sensor a bit, but it seemed to recover to its previous value.

https://imgur.com/trGEgB3

[maarten-pennings]

Yeah, i also get that, typically in 24h intervals.

[hmax42]

flashing worked for me. i used arduino and an esp8266 with the purple cjmcu811 board.

[pashar1]

Have anyone figured out how to make both HDC1080 and CCS810 to work together...

it looks like as soon as you initialize ccs811 HDC1080 no longer works...

i get correct readings from HDC1080 prior to ccs811.begin but after it's 125C and 100%

[maarten-pennings]

Hi @pashar1, from code review, I see no reason why ccs811.begin would break hdc1080. I have no hdc1080.

What you could do to pinpoint the problem is to comment out more and more sections in ccs811.begin to see what breaks hdc1080.

[pashar1]

so far I was not able to pinpoint where...

here is sketch I have put... I have tried with ClosedCube_HDC1080 library and with example from TI just using i2c

#include <Wire.h>
#include <ccs811.h>

CCS811 ccs811(D4);

void setup() {
  uint16_t eco2, etvoc, errstat, raw;
  double temperature;
  double humidity;
   //Initialize I2C Communication
  Serial.begin(115200);
  Serial.println("");
  Serial.println("setup: Starting HDC1080 basic demo");

  Wire.begin();

  //Configure HDC1080
  Wire.beginTransmission(0x40);
  Wire.write(0x02);
  Wire.write(0x90);
  Wire.write(0x00);
  Wire.endTransmission();

  //Delay for Startup of HDC1080
  delay(20);

  humidity = readSensor(&temperature);

  //Print the current temperature to the right of the label

  Serial.print("T="); Serial.print(temperature);

  Serial.print(" RH="); Serial.println(humidity);

  Serial.println (" ccs811.begin " );
  ccs811.set_i2cdelay(50); // Needed for ESP8266 because it doesn't handle I2C clock stretch correctly
  bool ok = ccs811.begin();
  if ( !ok ) Serial.println("setup: CCS811 begin FAILED");

  delay(100);

  humidity = readSensor(&temperature);

  //Print the current temperature to the right of the label

  Serial.print("T="); Serial.print(temperature);

  Serial.print(" RH="); Serial.println(humidity);

  delay(100);

  ok = ccs811.start(CCS811_MODE_1SEC);
  if ( !ok ) Serial.println("init: CCS811 start FAILED");

  delay(10000);

  humidity = readSensor(&temperature);

  //Print the current temperature to the right of the label

  Serial.print("T="); Serial.print(temperature);

  Serial.print(" RH="); Serial.println(humidity);

  ccs811.read(&eco2, &etvoc, &errstat, &raw);

    Serial.print("\neCO2 concentration: ");
    Serial.print(eco2);
    Serial.print(" ppm");

    Serial.print("\nTVOC concentration: ");
    Serial.print(etvoc);
    Serial.println(" ppb");

    delay(100);

    humidity = readSensor(&temperature);

    Serial.print("T="); Serial.print(temperature);

    Serial.print(" RH="); Serial.println(humidity);

}

void loop() 
{

}

double readSensor(double* temperature)
{
  //holds 2 bytes of data from I2C Line
  uint8_t Byte[4];

  //holds the total contents of the temp register
  uint16_t temp;

  //holds the total contents of the humidity register
  uint16_t humidity;

  //Point to device 0x40 (Address for HDC1080)
  Wire.beginTransmission(0x40);
  //Point to register 0x00 (Temperature Register)
  Wire.write(0x00);
  //Relinquish master control of I2C line
  //pointing to the temp register triggers a conversion
  Wire.endTransmission();

  //delay to allow for sufficient conversion time
  delay(20);

  //Request four bytes from registers
  Wire.requestFrom(0x40, 4);

  delay(1);

  //If the 4 bytes were returned sucessfully
  if (4 <= Wire.available())
  {
    //take reading
    //Byte[0] holds upper byte of temp reading
    Byte[0] = Wire.read();
    //Byte[1] holds lower byte of temp reading
    Byte[1] = Wire.read();

    //Byte[3] holds upper byte of humidity reading
    Byte[3] = Wire.read();
    //Byte[4] holds lower byte of humidity reading
    Byte[4] = Wire.read();

    //Combine the two bytes to make one 16 bit int
    temp = (((unsigned int)Byte[0] <<8 | Byte[1]));

    //Temp(C) = reading/(2^16)*165(C) - 40(C)
    *temperature = (double)(temp)/(65536)*165-40;

   //Combine the two bytes to make one 16 bit int
    humidity = (((unsigned int)Byte[3] <<8 | Byte[4]));

    //Humidity(%) = reading/(2^16)*100%
    return (double)(humidity)/(65536)*100;
  }
}

here is output:

setup: Starting HDC1080 basic demo
T=24.35 RH=46.97
 ccs811.begin 
T=24.35 RH=0.00
T=24.35 RH=0.00

eCO2 concentration: 400 ppm
TVOC concentration: 0 ppb
T=24.35 RH=0.00

[regnerus]

Thanks for the awesome flashing sketch, just flashed two CCS811 / HDC1080 modules from Aliexpress (https://www.aliexpress.com/item/32871695408.html) using a WEMOS D1. 😄

[maarten-pennings]

Hi @regnerus, thanks for letting me know. I have added your result to the table.

[ardatekin]

Hi Maarten

I use CCS811-HDC1080 Module with DOIT ESP32 DEVKIT V1 developer board to measure the CO2 level with the library you shared with us. Here is the module I bought, https://www.banggood.com/CCS811-HDC1080-Carbon-Dioxide-CO2-Temperature-And-Humidity-Sensor-VOCs-Air-quality-Monitor-Sensor-Module-Winder-p-1428378.html

Modules wired on breadboard is below

I have upgraded the firmware to 2.0 version as you have explained in CCS811 flash page.

I am not sure about the ppm values found by this electronic set. Please see the data I have shared in ccs811_hdc1080_eco2_etvoc_data.txt file.

ccs811_hdc1080_eco2_etvoc_data.txt

When I restart the ESP32, I receive around 400ppm in my office but after a while ppm values increases too much. I had measured same office room with MH-Z19B sensor and had found about 400-600ppm range in my 2 weeks test.

Here is the code

air_quality_esp32.txt

My questions are,

• Should I rely on this results or do I have a right implementation with the electronic set and written code? I need your comments about that.

• When I enable printSerialNumber() function, the application crashes, abort() is called and ESP32 restarts and this loops forever. Here is what I see when I enable the printSerialNumber function

17:24:53.819 -> rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) 17:24:53.819 -> configsip: 0, SPIWP:0xee 17:24:53.819 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 17:24:53.819 -> mode:DIO, clock div:1 17:24:53.819 -> load:0x3fff0018,len:4 17:24:53.819 -> load:0x3fff001c,len:928 17:24:53.819 -> ho 0 tail 12 room 4 17:24:53.819 -> load:0x40078000,len:8424 17:24:53.819 -> ho 0 tail 12 room 4 17:24:53.819 -> load:0x40080400,len:5868 17:24:53.819 -> entry 0x4008069c 17:24:53.965 -> 17:24:53.965 -> setup: Starting CCS811 basic demo 17:24:53.965 -> setup: ccs811 lib version: 10 17:24:53.965 -> setup: hardware version: 12 17:24:53.965 -> setup: bootloader version: 1000 17:24:53.965 -> setup: application version: 2000 17:24:53.965 -> Device Serial Number=FFFF-FFFF-FFFF 17:24:54.019 -> 17:24:54.019 -> Stack smashing protect failure! 17:24:54.019 -> 17:24:54.019 -> abort() was called at PC 0x400d70b0 on core 1 17:24:54.019 -> 17:24:54.019 -> Backtrace: 0x40089a8c:0x3ffb1ee0 0x40089cb9:0x3ffb1f00 0x400d70b0:0x3ffb1f20 0x400d0d01:0x3ffb1f40 0x400d0dc1:0x3ffb1f80 0x400d2e2f:0x3ffb1fb0 0x40085aa1:0x3ffb1fd0 17:24:54.019 -> 17:24:54.019 -> Rebooting... 17:24:54.019 -> ets Jun 8 2016 00:22:57 17:24:54.019 -> 17:24:54.019 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) 17:24:54.019 -> configsip: 0, SPIWP:0xee 17:24:54.019 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 17:24:54.066 -> mode:DIO, clock div:1 17:24:54.066 -> load:0x3fff0018,len:4 17:24:54.066 -> load:0x3fff001c,len:928 17:24:54.066 -> ho 0 tail 12 room 4 17:24:54.066 -> load:0x40078000,len:8424 17:24:54.066 -> ho 0 tail 12 room 4 17:24:54.066 -> load:0x40080400,len:5868 17:24:54.066 -> entry 0x4008069c 17:24:54.219 -> 17:24:54.219 -> setup: Starting CCS811 basic demo 17:24:54.219 -> setup: ccs811 lib version: 10 17:24:54.219 -> setup: hardware version: 12 17:24:54.219 -> setup: bootloader version: 1000 17:24:54.219 -> setup: application version: 2000 17:24:54.219 -> Device Serial Number=FFFF-FFFF-FFFF 17:24:54.219 -> 17:24:54.219 -> Stack smashing protect failure! 17:24:54.266 -> 17:24:54.266 -> abort() was called at PC 0x400d70b0 on core 1 17:24:54.266 -> 17:24:54.266 -> Backtrace: 0x40089a8c:0x3ffb1ee0 0x40089cb9:0x3ffb1f00 0x400d70b0:0x3ffb1f20 0x400d0d01:0x3ffb1f40 0x400d0dc1:0x3ffb1f80 0x400d2e2f:0x3ffb1fb0 0x40085aa1:0x3ffb1fd0 17:24:54.266 -> 17:24:54.266 -> Rebooting... 17:24:54.266 -> ets Jun 8 2016 00:22:57 17:24:54.266 -> 17:24:54.266 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) 17:24:54.266 -> configsip: 0, SPIWP:0xee 17:24:54.266 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 17:24:54.266 -> mode:DIO, clock div:1 17:24:54.266 -> load:0x3fff0018,len:4 17:24:54.266 -> load:0x3fff001c,len:928 17:24:54.266 -> ho 0 tail 12 room 4 17:24:54.266 -> load:0x40078000,len:8424 17:24:54.320 -> ho 0 tail 12 room 4 17:24:54.320 -> load:0x40080400,len:5868 17:24:54.320 -> entry 0x4008069c 17:24:54.420 -> 17:24:54.420 -> setup: Starting CCS811 basic demo 17:24:54.420 -> setup: ccs811 lib version: 10 17:24:54.467 -> setup: hardware version: 12 17:24:54.467 -> setup: bootloader version: 1000 17:24:54.467 -> setup: application version: 2000 17:24:54.467 -> Device Serial Number=FFFF-FFFF-FFFF 17:24:54.467 -> 17:24:54.467 -> Stack smashing protect failure! 17:24:54.467 -> 17:24:54.467 -> abort() was called at PC 0x400d70b0 on core 1 17:24:54.467 -> 17:24:54.467 -> Backtrace: 0x40089a8c:0x3ffb1ee0 0x40089cb9:0x3ffb1f00 0x400d70b0:0x3ffb1f20 0x400d0d01:0x3ffb1f40 0x400d0dc1:0x3ffb1f80 0x400d2e2f:0x3ffb1fb0 0x40085aa1:0x3ffb1fd0 17:24:54.520 -> 17:24:54.520 -> Rebooting... 17:24:54.520 -> ets Jun 8 2016 00:22:57 ......... .........

• When I enable the code for HDC1080 module I read similar values that pashar1 user shared in this thread

Temperature 125C and Humidity 100%

and sometimes correct temp and hum values are written on logs. This may not be the scope of this thread but I would like to know if you also have any comments about this case.

Kind Regards, Arda

[bfaliszek]

@ardatekin to fixed HDC1080 125/100 problem, check this link https://github.com/closedcube/ClosedCube_HDC1080_Arduino/pull/8/commits/724a233c76da13d4e559262eb6eeaa5037d33f09 and add Wire.begin(HDC1080_SDA, HDC1080_SCL); and of course `#define HDC1080_SDA 18

define HDC1080_SCL 19`

you can of course change the pins to other.

[theoroborus]

Hello,

Using VSC and PIO, I was returned errors on the CCS811_SW000246_1-00.h file, but was possibly my fault as I'm quite new to that IDE. So I used the Arduino IDE and it worked like a charm. Thank you so much maarten-penning !

I also observed that the upper boundaries are higher now.

It was so interesting to read about other experiences. I wasn't aware about the baseline, will sure use the set_baseline.

By placing the sensor just above a drop of alcoolic gel, I sometimes obtain this : http://image.noelshack.com/fichiers/2019/33/5/1565966769-values.png

I wonder why the sensor goes that crazy. The value is always the same when it happen :).

[maarten-pennings]

You mean the value 4294934528? That is a funky value: it starts with 17 ones when you write it in binary, I'm wondering whether that is an I2C line problem (SDA stuck hi) or an internal overflow.

[ardatekin]

Finally I come to conclusion that the sensor and MCU should be wired to each other by soldering on a perfboard or pcb rather than on breadboard in order to read the most reliable results.
I have measured that there is a variable amount of resistance between the pins of sensor and MCU such as 15-24ohm.
And I also replaced esp32 with NodeMCU which looks more stable in my tests. Resetting the i2c bus line with I2Cbus_clear when getting CCS811_ERRSTAT_I2CFAIL would also prevent getting more errors in operation time. (https://github.com/maarten-pennings/I2Cbus)

Sharing some screens from my environment. Thank you very much Maarten and bfaliszek

[maarten-pennings]

I'm glad you got it working. Your project looks good!

[jarsiv]

Thank you @maarten-pennings !

I got ESP32 Lolin and chinese CCS881 (CJMCU-811 ? ) on yeasterday. After couple hours it was running. I also success to update firmware to V2.0 with Arduino.

[maarten-pennings]

Good work @jarsiv!

[ciphercore]

Updated my CCS811 (CJMCU-811) from Aliexpress from App Version 1.1 -> 2.0 (Arduino Uno)

Thank you @maarten-pennings and everyone else in this thread

[maarten-pennings]

Hi @ciphercore thanks for the feedback, I added your success to the table https://github.com/maarten-pennings/CCS811/blob/master/examples/ccs811flash/README.md

[astappiev]

Updated my CJMCU-811 from 0x1100 to version 0x2001 successfully (yes, there is a new file on AMS website). Thanks for the library @maarten-pennings.

They even added a changelog now

2-0-1      Firmware build including all 2-0-0 features accept management of the burn in period          

2-0-0      MOX sensor need a burn-in period of several days of operation from first power on before 
                 eCO2 and TVOC readings stabilize. The burn-in period is now managed so that stable 
                 readings are available after only 60 minutes of operation after first power on
           Extend eCO2 maximum output value to 64000 ppm
           Extend TVOC maximum output value to 64000 ppm
           Removed NTC functionality. Pin 8 not measured and left undriven
           Added "Internal_State" variable to the command register map
           Improved the algorithm which computes eTVOC and eCO2 

1-1-0      Initial Version

[maarten-pennings]

(yes, there is a new file on AMS website)

No, 2.0.0 and 2.0.1 are the same firmware.

See the readme:

The version of firmware to use depends on the usage status of the device. New fresh sensors use firmware 2-0-0 Sensors run for a number of days use firmware 2-0-1

[astappiev]

Sorry to disturb then.

I saw, but I thought may be they added it later as your code do not count it (at least it should now flash it again when I run in twice).

On Sat, Jan 25, 2020, 18:11 Maarten Pennings notifications@github.com wrote:

(yes, there is a new file on AMS website)

No, 2.0.0 and 2.0.1 are the same firmware.

See the readme:

The version of firmware to use depends on the usage status of the device. New fresh sensors use firmware 2-0-0 Sensors run for a number of days use firmware 2-0-1

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/maarten-pennings/CCS811/issues/8?email_source=notifications&email_token=ABCNXWPVIEHEK4S4WYNFS4DQ7RQDLA5CNFSM4GKU4KK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ47RYI#issuecomment-578418913, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCNXWKVB6K4APUMPPEBNQ3Q7RQDLANCNFSM4GKU4KKQ .

[nicoolaro]

(yes, there is a new file on AMS website)

No, 2.0.0 and 2.0.1 are the same firmware.

See the readme:

The version of firmware to use depends on the usage status of the device. New fresh sensors use firmware 2-0-0 Sensors run for a number of days use firmware 2-0-1

So i burned chip for 24hours with old 1.2 version, i just reflashed with your 2.0 version, should i waited for new 2.0.1 as stated in AMS website or should i keep using your version? A bit confused now, thanks

[maarten-pennings]

I also think it is confusing.

I believe the new firmware uses special algorithm at the early life of the sensor. When early life is over, it uses the standard algorithm. The firmware knows when early life is over by persistently storing the run time on the sensor. The special algorithm at early life is needed, because the chemicals in the sensor are not yet "baked" to stability. Again, all this is what I mentally model from the documentation.

Since the old firmware did not have this algorithm, it also did not store the run time.

So, the 2.0.0 firmware is good for fresh "non-baked" sensors. But if you would use it on a baked sensor, the firmware would (incorrectly) apply the special algorithm the first couple of days, giving suboptimal readings. However, after the first couple of days, the persistent timer reaches the end-of-early-life value and switches to the standard algorithm, so your readings will be good from then onwards.

I believe the 2.0.1 firmware sets the internal timer to maximum, so that the standard algorithm kicks in immediately. This is good for "baked sensors". For fresh sensors, the first couple of days you would get suboptimal readings, but from then on it is fine.

Conclusion, after running a couple of days, it doesn't matter which firmware you have.

[nicoolaro]

Gotcha, no concerns then.