Pain with capitalization and Wires

[ullix]

It started out easy: downloaded your lib as zip and installed in the uecide IDE for use with my ESP32. Basic example ran fine, even the flash could be done without any problems (so I now have app 0x2000). Great. Was not possible with the Arduino and Sparkfun libs.

But then I wanted to integrate the lib into my big sketch. The ESP32 supports two separate I2C connections, which Wire supports by default as Wire and Wire1 (can be named differently if desired). And my CCS811 has to be on Wire1. Not a major problem; all I had to do was to rename each occurrence of Wire in your lib to Wire1.

As I didn't want to modify the lib at its default place, I created a local copy, private to just my sketch. This is easily done under uecide. But there is a catch: uecide wants the same capitalization of folder, filenames and includes, while you have a mix of big cap in the folder, and small caps elsewhere.

So, now I have renamed everything to big cap, renamed the Wire to Wire1, and it is running! Please, don't upgrade!

But when you do, my wishlist is:

• support both Wire options on the ESP32
• be strictly consistent on your lib naming
• expose the chip ID (like getCCS811ID). I am using so many chips, I'd prefer to just call a function instead of figuring it out from the lib code.

Now I am puzzled with the huge variation of the Css811 data, and I saw a lengthy discussion elsewhere on this site. But one question: there is some "raw" calculation in your basic script. Is that explained somewhere in the datasheet, or did you figure this out yourself? How is that related to the co2 and tvoc data? Is that even explained, or hidden in the firmware?

[maarten-pennings]

The raw calculation is explained in the datasheet but you have to know what they say. Here is the explaining fragment:

RAW_DATA Register (0x03)
Two byte read only register which contains the latest readings from the sensor. The most significant 6 bits of the Byte 0 contain the value of the current through the sensor (0μA to 63μA). The lower 10 bits contain (as computed from the ADC) the readings of the voltage across the sensor with the selected current (1023 = 1.65V).

One thing they don't tell you is that you want the resistance, which is R= V/I. Also implicit is that V scales linearly: 0..1023 ~ 0..1.65V

[maarten-pennings]

Could you explain how I should change the lib to support both wires on the esp32?

[ullix]

I suggest to refer to e.g. this lib: https://github.com/adafruit/Adafruit_BME280_Library , where this dual option is used.

And note that in the Wire lib you find this in Wire.cpp:

    TwoWire::TwoWire(uint8_t bus_num)
        :num(bus_num & 1)
    ...
        
    TwoWire Wire = TwoWire(0);
    TwoWire Wire1 = TwoWire(1);

So, only 2 bus numbers are supported, 0 and 1, and they can be called as Wire and Wire1.

In the Adafruit_BME280.h header file you find the overloaded begin definitions:

      bool begin();
      bool begin(TwoWire *theWire);
      bool begin(uint8_t addr);
      bool begin(uint8_t addr, TwoWire *theWire);       

In my sketch I then start this lib with:

        // setting Wire1 to pins sda, scl
        Wire1.begin(sda, scl);
       ...
        #define BME280_ADDRESS      (0x76) 
        ...
        // Initializing Sensor BME280
        bool status = bme.begin(BME280_ADDRESS, &Wire1);
        if (!status) {
        ...

I use Wire1 for time critical readings of sensors on a separate task, and Wire for devices that allow a more leisurely pace in the main loop task. Works well on all ESP32s that I have used (ESP32-WROOM, -WROVER, -PICO).

Your lib has now mastered an overnight run, and all went as expected. (Though the data remain puzzling :-/)

[ullix]

OK, found the quoted fragment, thanks. The public code goes up to calculating the mox resistance, and ends there. The calculation of eco2 and tvoc seems confidential and hidden in the firmware. The firmware is not disclosed, just this binary blob is available?

This is a similar approach to what Bosch is doing with their sensor BME680. The public code goes up to resistance. For their much PRed "air quality number" you need to register with name, address, ... so that you can download a binary blob fitting to the CPU you are using. It still gives you a single number only; I have not seen any published data supporting their claims. Too bad.

For the CCS811 I find it particular strange, that from one single variable - resistance - you calculate two variables, which are correlated to a degree, but also widely different, and are claimed to be two different things.

I am having some doubts!

[maarten-pennings]

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. My guess: the firmware controls the current through the MOX paste, and measures the voltage (ADC). Then computes the MOX resistance, and that is an indication for VOC concentration.

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.