AirQualityWing issues with Particle Argon and Xenon

otherguy

I bought an AirQualityWing last year and only now had time to try it out, but I’m having massive problems with it.

I’m trying to get any data out of it with either an Argon or a Xenon, on either Particle’s firmware (with your default example code) or with Circuitpython, but it seems the device can’t connect to any of the sensors on the board.

I’m a bit more familiar with Python so I flashed the Argon (and Xenon) with Circuitpython and tried it there, but it’s the same:

ccs811 = adafruit_ccs811.CCS811(i2c) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "adafruit_ccs811.py", line 129, in __init__ RuntimeError: Device ID returned is not correct! Please check your wiring.

Same for the SI7021:

Traceback (most recent call last): File "code.py", line 56, in <module> File "adafruit_si7021.py", line 128, in __init__ File "adafruit_si7021.py", line 147, in _command File "adafruit_si7021.py", line 147, in _command File "adafruit_bus_device/i2c_device.py", line 84, in write OSError: [Errno 5] Input/output error

I2C itself seems to be working just fine:

Unlocking I2C I2C addresses found: ['0x8', '0x9', '0xa', '0xc', '0xd', '0xe', '0x10', '0x11', '0x12', '0x13', '0x14', '0x15', '0x16', '0x18', '0x19', '0x1a', '0x1c', '0x1e', '0x20', '0x21', '0x22', '0x23', '0x24', '0x25', '0x26', '0x28', '0x29', '0x2a', '0x2c', '0x2e', '0x30', '0x31', '0x32', '0x34', '0x35', '0x36', '0x38', '0x39', '0x3a', '0x3c', '0x3e', '0x40', '0x41', '0x42', '0x43', '0x44', '0x45', '0x46', '0x48', '0x49', '0x4a', '0x4c', '0x4e', '0x50', '0x51', '0x52', '0x54', '0x55', '0x56', '0x58', '0x59', '0x5a', '0x5c', '0x60', '0x61', '0x62', '0x64', '0x65', '0x66', '0x68', '0x69', '0x6a', '0x6c', '0x6e', '0x70', '0x71', '0x72', '0x74', '0x76']

All of the output is from the Argon+AQW being powered by USB.

The AQW is board revision 4.

Is there any way I can verify if the AQW is defective?

jaredwolff

otherguy

otherguy I2C itself seems to be working just fine:

Unlocking I2C
I2C addresses found: [‘0×8’, ‘0×9’, ‘0xa’, ‘0xc’, ‘0xd’, ‘0xe’, ‘0×10’, ‘0×11’, ‘0×12’, ‘0×13’, ‘0×14’, ‘0×15’, ‘0×16’, ‘0×18’, ‘0×19’, ‘0×1a’, ‘0×1c’, ‘0×1e’, ‘0×20’, ‘0×21’, ‘0×22’, ‘0×23’, ‘0×24’, ‘0×25’, ‘0×26’, ‘0×28’, ‘0×29’, ‘0×2a’, ‘0×2c’, ‘0×2e’, ‘0×30’, ‘0×31’, ‘0×32’, ‘0×34’, ‘0×35’, ‘0×36’, ‘0×38’, ‘0×39’, ‘0×3a’, ‘0×3c’, ‘0×3e’, ‘0×40’, ‘0×41’, ‘0×42’, ‘0×43’, ‘0×44’, ‘0×45’, ‘0×46’, ‘0×48’, ‘0×49’, ‘0×4a’, ‘0×4c’, ‘0×4e’, ‘0×50’, ‘0×51’, ‘0×52’, ‘0×54’, ‘0×55’, ‘0×56’, ‘0×58’, ‘0×59’, ‘0×5a’, ‘0×5c’, ‘0×60’, ‘0×61’, ‘0×62’, ‘0×64’, ‘0×65’, ‘0×66’, ‘0×68’, ‘0×69’, ‘0×6a’, ‘0×6c’, ‘0×6e’, ‘0×70’, ‘0×71’, ‘0×72’, ‘0×74’, ‘0×76’]

That’s a lot of devices! My code and hardware was not designed to operate with that use case in mind.

I recommend trying stand-alone first to make sure there’s nothing wrong with the hardware. I wouldn’t be surprised if there’s an overlapping address which is causing errors talking to the CCS811 and Si7021. (For example, the address for the Si7021 is 0×40. If you have anything else that has address 0×40 you’ll get collisions or things will simply not work.)

otherguy

jaredwolff thanks for your reply!

I believe that is an artifact of Micropython. I’m using the AQW standalone for now (and will only add a single I2C slave device in the final “product”).

Right now it’s only the Argon plugged on top of the AQW.

otherguy

jaredwolff scratch that. I just put the Argon on a breadboard with just 2 pullup resistors for the I2C bus:

>>> print("I2C addresses found:", [hex(device_address) for device_address in i2c.scan()]) I2C addresses found: []

Then I added an MCP9808 temperature sensor:

>>> print("I2C addresses found:", [hex(device_address) for device_address in i2c.scan()]) I2C addresses found: ['0x18']

And then I plugged the Argon into the AQW:

>>> print("I2C addresses found:", [hex(device_address) for device_address in i2c.scan()]) I2C addresses found: ['0x8', '0x9', '0xa', '0xc', '0xd', '0xe', '0x10', '0x11', '0x12', '0x13', '0x14', '0x15', '0x16', '0x18', '0x19', '0x1a', '0x1c', '0x1e', '0x20', '0x21', '0x22', '0x23', '0x24', '0x25', '0x26', '0x28', '0x29', '0x2a', '0x2c', '0x2e', '0x30', '0x31', '0x32', '0x34', '0x35', '0x36', '0x38', '0x39', '0x3a', '0x3c', '0x3e', '0x40', '0x41', '0x42', '0x43', '0x44', '0x45', '0x46', '0x48', '0x49', '0x4a', '0x4c', '0x4e', '0x50', '0x51', '0x52', '0x54', '0x55', '0x56', '0x58', '0x59', '0x5a', '0x5c', '0x60', '0x61', '0x62', '0x64', '0x65', '0x66', '0x68', '0x69', '0x6a', '0x6c', '0x6e', '0x70', '0x71', '0x72', '0x74', '0x76']

A visual inspection of the AQW shows nothing out of the ordinary, apart from the resistor R1 being absent. Is that correct? According to your schematics, there should be a 100k resistor.

I soldered a 120K resistor on the empty R1 pads (didn’t have a 100K) and the output changed slightly:

>>> print("I2C addresses found:", [hex(device_address) for device_address in i2c.scan()]) I2C addresses found: ['0x8', '0x9', '0xa', '0xc', '0xd', '0xe', '0x10', '0x11', '0x12', '0x13', '0x14', '0x15', '0x16', '0x18', '0x19', '0x1a', '0x1c', '0x1e', '0x20', '0x21', '0x22', '0x23', '0x24', '0x25', '0x26', '0x28', '0x29', '0x2a', '0x2c', '0x2e', '0x30', '0x31', '0x32', '0x34', '0x35', '0x36', '0x38', '0x39', '0x3a', '0x3c', '0x3e', '0x40', '0x41', '0x42', '0x43', '0x44', '0x45', '0x46', '0x48', '0x49', '0x4a', '0x4c', '0x4e', '0x50', '0x51', '0x52', '0x54', '0x55', '0x56', '0x58', '0x59', '0x5a', '0x5c', '0x5e', '0x60', '0x61', '0x62', '0x64', '0x65', '0x66', '0x68', '0x69', '0x6a', '0x6c', '0x6e', '0x70', '0x71', '0x72', '0x74', '0x76']

Now there is a devices 0x5e in the list that wasn’t there before. There is no other change and devices on the I2C bus don’t function.

I noticed that the SI7021 also isn’t soldered on straight. At this point I’m assuming the AQW is defective.

There is a testpoint on the board. Do you have any advice on what I could measure to verify it?

jaredwolff

otherguy A visual inspection of the AQW shows nothing out of the ordinary, apart from the resistor R1 being absent. Is that correct? According to your schematics, there should be a 100k resistor.

That part should not matter.

otherguy I noticed that the SI7021 also isn’t soldered on straight. At this point I’m assuming the AQW is defective.

I’ve personally built and tested all AQWs that have left here. I doubt very much, as long as you stored it correctly, that it would be defective after a year.

One thing I will add is I only support the original code that shipped with it. A few requests to debug this further:

If you’d like to load the original code up and show the output that would be useful.
Also please send pictures of the top & bottom of the AQW. There should be a small cut in a trace going to the CCS811 on the bottom side. This could affect the CCS811 I2C operations but it shouldn’t affect the Si7021.
Do you have/are you using an HPMA115?

otherguy

jaredwolff thank you for the support

jaredwolff I’ve personally built and tested all AQWs that have left here. I doubt very much, as long as you stored it correctly, that it would be defective after a year.

I understand! It arrived last year but I didn’t make it back home until recently due to COVID, so it was just sitting on the counter in the box it was shipped in.

One thing I will add is I only support the original code that shipped with it. A few requests to debug this further:

That makes perfect sense. I only switched to Circuitpython because I had some troubles with the Particle cloud.

If you’d like to load the original code up and show the output that would be useful.

This is the output from the Argon. I loaded the code up on a Xenon and it’s identical:

Serial monitor opened successfully: 0000020541 [app] WARN: Error tvoc - no data 0000030541 [app] ERROR: hpma timeout 0000030541 [app] ERROR: Error hpma115 0000030542 [app] ERROR: Error sgp30 0000040541 [app] WARN: Error tvoc - no data 0000050541 [app] ERROR: hpma timeout 0000050541 [app] ERROR: Error hpma115 0000050542 [app] ERROR: Error sgp30 0000060541 [app] WARN: Error tvoc - no data

Do you have/are you using an HPMA115?

Yes, the HPMA115 is plugged in.

Incidentally, shouldn’t the CCS811 have a plastic cover/case?

Also please send pictures of the top & bottom of the AQW. There should be a small cut in a trace going to the CCS811 on the bottom side. This could affect the CCS811 I2C operations but it shouldn’t affect the Si7021.

jaredwolff

otherguy looks like this board was damaged. Unfortunately I’m not sure if anything can be doe here. I’m not sure why the HPMA is not working though. You can isolate/remove the CSS811 by modifying this guy:

  AirQualityWingSettings_t defaultSettings =
      {
          MEASUREMENT_DELAY_MS, //Measurement Interval
          true,                 //Has HPMA115
          false,                 //Has CCS811
          false,                 //Has Si7021
          false,                //Has SGP30
          CCS811_ADDRESS,       //CCS811 address
          CCS811_INT_PIN,       //CCS811 intpin
          CCS811_RST_PIN,       //CCS811 rst pin
          CCS811_WAKE_PIN,      //CCS811 wake pin
          HPMA1150_EN_PIN       //HPMA int pin
      };

Did you get the HPMA from me or elsewhere? The connector has a very specific pinout and the HPMA will not work if it’s not correct.

otherguy

I got the HPMA from Honeywell directly (well, Digikey). It’s working with a breakout board if I connect it directly to the Argon via a breadboard (with custom code)

I tried the code with just the Si7021 enabled and with just the HPMA115 enabled, but the result is the same (minus the error messages for these devices of course).

I understand that you cannot debug any other code but I don’t think it’s a software issue. Remember the long list of I2C devices that Circuitpython sees when the AQW is plugged in? So it turns out I can communicate with I2C devices when it’s just the Argon on a breadboard, but as soon as the Argon is plugged into the AQW, communication with any I2C device fails – not just the 2 on the AQW board, but also external I2C devices. It seems there is a short or a wrong connection somewhere. Possibly it’s related to the damaged CCS811?

I got the board from GroupGets (ORDER #GG-4596) on November 25th 2020 (so less than a year actually). I’m in Europe and just getting another AQW board is prohibitively expensive (I paid $60 with shipping and another $40 in import tax and customs fees).

otherguy

Anything I can measure to isolate what is damaged?

otherguy

Just to be 100% certain I tried it with a second Argon and another Xenon:

Serial monitor opened successfully: Air Quality Wing for Particle & Feather 0000035248 [app] WARN: Error tvoc - no data 0000045247 [app] ERROR: hpma timeout 0000045248 [app] ERROR: Error hpma115 0000045249 [app] ERROR: Error sgp30 0000055246 [app] WARN: Error tvoc - no data

jaredwolff

otherguy one thing I noticed from your pictures is that the trace to the reset pin of the CCS811 is not cut like should be. (It’s hard to tell in that lighting) If you cut it where I recommend below that also may help. Ultimately, since the package of the CCS811 is completely gone, it’s hard to guarantee things are working properly.

As for the HPMA you’ll have to change your cable to match the intended pinout. That means popping out the wire connections and likely reversing them.

Here’s a picture of what the cable looks like with only the needed connections. It’s fairly easy to remove the unused ones using a needle or a very small flat head screwdriver.

(Originally from here)

Ultimately the CCS811 likely needs to be removed all together. If you’re feeling adventurous you could always remove it with a hot air gun aimed from the bottom of your board. That process is not for the faint of heart though!

jaredwolff

Also if you have the ability to capture the I2C signals on a scope that would be interesting. My guess is that it’s all mucked up from the damaged CCS811.

otherguy

Give me some time. I’m traveling at the moment but I will try to do all that on the weekend. My scope is quite basic but it’s good enough for I2C traffic.

I do want to stress that this is the exact condition the board arrived in! The CCS811 never had its original casing. I only noticed that it should have one when I looked at the datasheet and photos of other CCS811.

jaredwolff

Got it. otherguy let me know what you find.

otherguy

jaredwolff alright, I just got around to looking at this.

The trace was indeed not cut but there was a thin scratch between the D2 and D3 pads. I cut the trace right at this point. Your pictures of the HPMA115 wiring were also very helpful because I noticed my wiring was flipped. Oops. I corrected that.

This got me a little farther. The HPMA now turns on but the values reported (changed log level to INFO) are completely off:

0000140421 [app] INFO: {"pm25":1000,"pm10":1013,"temperature":128.87,"humidity":119.00}

Digging a little deeper and adding some debug statements, I noticed that all the values read from the HPMA and the Si7021 seem to be messed up (I’m not measuring next to that volcano in Iceland):

temp_code: 65535
rh_code: 65535
hum: 119.00% temp: 128.87°C
0000059013 [app] WARN: Error tvoc - no data
data+checksum: fc fc
data+checksum: 2df 2df
data+checksum: 2df 2df
rx_buf: 2003e4f0
0000063039 [app] INFO: {"pm25":1000,"pm10":1013,"temperature":128.87,"humidity":119.00}

Next, I will try to remove the CCS811 altogether. Merely disabling it in the code doesn’t change anything.

jaredwolff

otherguy I would disable the Si7021 and CCS811 if you can. The HPMA is on UART which shouldn’t be affected by any of the I2C issues. Start there and go backwards. 😀

otherguy

jaredwolff I did that actually before posting but it didn’t change anything.

rx_buf: 2003e4f0
0000045035 [app] INFO: {"pm25":1000,"pm10":1013}

It’s encouraging that at least the fan is spinning and data is being read.

otherguy

So, just my luck, but the HPMA was brand new but defective. I RMA’d it with Honeywell.

However, I had a PMS5003 lying around which is very similar in design but has a slightly different pinout. Other than that, it also communicates over UART and needs 5V input for the fan. I changed the wiring to match the PMS5003, didn’t touch the code, and it works. The values match the ones reported by a Temtop M2000 station as well as the ones by the local AQI measurement station.

rx_buf: 66 77 0 28 0 7 0 9 0 9 0 7 0 9 0 9 0 0 0 0 0 0 0 0 0 0 0 0 151 8 1
0000082554 [app] INFO: {"pm25":9,"pm10":9}

rx_buf: 66 77 0 28 0 109 0 219 0 250 0 72 0 145 0 166 0 0 0 0 0 0 0 0 0 0 0 0 151 8 5
0000102570 [app] INFO: {"pm25":219,"pm10":250}

The second measurement is from directly next to my soldering station. Eww.

One down.

Next was the CCS811 which came off easily with the hot air soldering gun. I have a spare CCS811 here which I could desolder from its breakout board, but first I want to make sure the rest of the board is working.

The Si7021 is consistently reporting relative humidity of 119.00% and a temperature of 128.87°C. Which seemed odd until I looked at the code that is used for reading the data. The raw values reported by the sensor are just 65535 (0xFFFF) for both temperature and humidity.

And that was also the case for CCS811 before.

So I hooked up my crappy Aliexpress scope and while I’m no electrical engineer and I’m not great at reading the output, it looks to me as if SDA is just permanently stuck on HIGH.

So there is definitely more broken on that board than just the CCS811.

jaredwolff

I would recommend if you do remove it, the CCS811 is very fragile when heated. Best to warm it from the bottom if possible.

So I hooked up my crappy Aliexpress scope and while I’m no electrical engineer and I’m not great at reading the output, it looks to me as if SDA is just permanently stuck on HIGH.

Hmm interesting. Without anything connected, can you measure the pull up resistors? If they’re shorted to 3.3V that would explain the issues a bit more. (Though would be a problem if they were 0 ohms!)

jaredwolff

Hmm definitely not expected behavior!

jaredwolff it looks to me as if SDA is just permanently stuck on HIGH.

Back to this, the SCL line is toggling though? If you put the particle board on a breadboard, do both (SDA & SCL pins) toggle?

What version of Device OS are you using?

otherguy

I would recommend if you do remove it, the CCS811 is very fragile when heated. Best to warm it from the bottom if possible.

Thanks! I will try that once I have the Si7021 working.

Hmm interesting. Without anything connected, can you measure the pull up resistors? If they’re shorted to 3.3V that would explain the issues a bit more. (Though would be a problem if they were 0 ohms!)

Without anything connected, I measure 20kΩ between both SDA/3.3V and SCL/3.3V. I measure 40kΩ between SDA and SCL (which makes sense).

To test the I2C bus, with nothing connected to the AQW and the CCS811 desoldered, I ran the following program:

#include <Wire.h> //include Wire.h library

void setup()
{
  Wire.begin(); // Wire communication begin
  Serial.begin(9600); // The baudrate of Serial monitor is set in 9600
  while (!Serial); // Waiting for Serial Monitor
  Serial.println("\nI2C Scanner");
}

void loop()
{
  byte error, address; //variable for error and I2C address
  int nDevices;

  Serial.println("Scanning...");

  nDevices = 0;
  for (address = 1; address < 127; address++ )
  {
    // The i2c_scanner uses the return value of
    // the Write.endTransmisstion to see if
    // a device did acknowledge to the address.
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0)
    {
      Serial.print("I2C device found at address 0x");
      if (address < 16)
        Serial.print("0");
      Serial.print(address, HEX);
      Serial.println("  !");
      nDevices++;
    }
    else if (error == 4)
    {
      Serial.print("Unknown error at address 0x");
      if (address < 16)
        Serial.print("0");
      Serial.println(address, HEX);
    }
  }
  if (nDevices == 0)
    Serial.println("No I2C devices found\n");
  else
    Serial.println("done\n");

  delay(5000); // wait 5 seconds for the next I2C scan
}

And the output is:

I2C Scanner
Scanning...
I2C device found at address 0x01  !
I2C device found at address 0x02  !
I2C device found at address 0x03  !
I2C device found at address 0x04  !
I2C device found at address 0x05  !
I2C device found at address 0x06  !
I2C device found at address 0x08  !
I2C device found at address 0x09  !
I2C device found at address 0x0A  !
I2C device found at address 0x0B  !
I2C device found at address 0x0C  !
I2C device found at address 0x0D  !
I2C device found at address 0x0E  !
I2C device found at address 0x10  !
I2C device found at address 0x11  !
I2C device found at address 0x12  !
I2C device found at address 0x13  !
I2C device found at address 0x14  !
I2C device found at address 0x15  !
I2C device found at address 0x16  !
I2C device found at address 0x24  !
I2C device found at address 0x25  !
I2C device found at address 0x26  !
I2C device found at address 0x28  !
I2C device found at address 0x29  !
I2C device found at address 0x2A  !
I2C device found at address 0x39  !
I2C device found at address 0x3A  !
I2C device found at address 0x49  !
I2C device found at address 0x4A  !
I2C device found at address 0x59  !
I2C device found at address 0x5A  !
I2C device found at address 0x68  !
I2C device found at address 0x69  !
I2C device found at address 0x6A  !
I2C device found at address 0x6C  !
I2C device found at address 0x7A  !
I2C device found at address 0x7C  !
done

This is the same issue I saw on CircuitPython with a huge list of I2C addresses.