What Would You Do with the Indoor Air Quality HAT for Raspberry Pi

I think I would compare it with other sensors on the market, as I haven't been entirely satisfied with any of them for CO2. I think the gold-standard is still IR-based type sensors, but they are more expensive and bulky.

I currently have experience with the Sensiron SGP30 which is a CO2eq and TVOC sensor, and a Bosch BME680 which also claims to output VOC readings. The SGP30 seems to have a lot of "cross-sensitivity" effects which result in wacky CO2eq readings when hit by VOCs (e.g. just open up a bottle of ethanol next to it and it will go nuts). The Bosch BME680 is not entirely satisfactory either - instead of providing ppm/ppb concentrations, it reports VOC as a resistance change of an internal (presumably metal oxide) element.

Perhaps evaluating the cross-sensitivity behaviour under regular conditions and high-VOC concentrations would be a good activity, along with using it ordinarily in a bedroom to evaluate correlation in sensor values between the SGP30 and the Renesas solution. It would be good to see how well each of the sensors manage to handle the situations, as many of them are "self-calibrating" to a "background" of 400ppm, so the drift and accuracy in the long term would be good to know.

I think that the decision to evaluate the sensors in a Pi Hat could also cause problems which I'd be keen to check out - for example, the positioning of the sensors look close to where the Pi4 has the USB3 controller and previous Pis have a USB Hub and Network IC - all of these chips are known to be hot ICs, so I wonder whether the "high precision" of the sensors would be wasted given the close proximity when used "as a hat". Also having previously evaluated the Bosch CISS, Omron 2JCIE-EV-AR01 and BU/BL01 solutions, it might be nice to compare the temperature/RH performance versus the "industry standard" Sensirion SHT30 used in the latter solutions.

- Gough

Actually, it seems like Renesas/IDT actually have contracted KSI to do some testing on their sensors which confirms my suspicion that MOX based CO2eq/eCO2 numbers are a bit funky in general, but IR-based CO2 is much more reliable:

https://www.idt.com/us/en/document/rep/ksi-report-algorithm-evaluation-eco2-tracking?language=en

The document on their site shows comparison between the IDT/Renesas ZMOD4410, Sensirion SGP30 and AMS CCS811 MOX type sensors; and Sensirion SCD3x, Senseair K30 and Cubic CM1106 IR-type sensors. The most interesting Fig 14 seems to show just how the different MOX sensors fared:

Having used the SGP30 myself, it seems that the SGP30 has a longer decay time than the other sensors and reports higher than the other sensors, but all of them can deviate quite far from the ground truth.

During their calibration of the SCD3x (note their labelling error), K30, CM1106 with their MX1102, we can see the IR sensors are generally quite good at following the trends.

Curiously, they didn't attempt using the same dry mixture to calibrate the eCO2 values for the MOX sensors. Perhaps the baseline drift algorithm would have prevented that from working, but their observation that ethanol makes the sensors go crazy is pretty much apparent, although the behaviour of the ZMOD seems a little interesting in that it seems to "clamp" low into 400ppm for anything less than the maximum tested value, which is perhaps a nicer sensor behaviour. There is a significant unit-to-unit difference in response, as noted in https://www.idt.com/us/en/document/rep/ksi-report-zmod4410-gas-sensors-compliance-ubas-iaq-study?language=en , but this seems to be calibrated out to achieve their claimed accuracy ranges:

It's nice to see this level of detail available openly, as I have not seen this level of detail for other sensors, but the performance perhaps depends on the algorithm (the latest being their V2) using AI. There are also separate firmwares for fan control and sulfur odour detection. They also say the following in their datasheet (which has no information on I2C registers):

For implementing the sensor module in a customer-specific application, detailed information on the programming is available. The recommended requirements for the host MCU are 16kB flash for ZMOD4410 related firmware code, 1kB RAM for ZMOD4410 related operations, and the capability to perform I2C communication, timing functions, and floating-point instructions.

I suspect this is a conventional non-AI algorithm and that even the I2C register map is subject to agreement on some terms/conditions? I suppose the RoadTesters may be able to find out.

- Gough

Actually, it seems like Renesas/IDT actually have contracted KSI to do some testing on their sensors which confirms my suspicion that MOX based CO2eq/eCO2 numbers are a bit funky in general, but IR-based CO2 is much more reliable:

https://www.idt.com/us/en/document/rep/ksi-report-algorithm-evaluation-eco2-tracking?language=en

The document on their site shows comparison between the IDT/Renesas ZMOD4410, Sensirion SGP30 and AMS CCS811 MOX type sensors; and Sensirion SCD3x, Senseair K30 and Cubic CM1106 IR-type sensors. The most interesting Fig 14 seems to show just how the different MOX sensors fared:

Having used the SGP30 myself, it seems that the SGP30 has a longer decay time than the other sensors and reports higher than the other sensors, but all of them can deviate quite far from the ground truth.

During their calibration of the SCD3x (note their labelling error), K30, CM1106 with their MX1102, we can see the IR sensors are generally quite good at following the trends.

Curiously, they didn't attempt using the same dry mixture to calibrate the eCO2 values for the MOX sensors. Perhaps the baseline drift algorithm would have prevented that from working, but their observation that ethanol makes the sensors go crazy is pretty much apparent, although the behaviour of the ZMOD seems a little interesting in that it seems to "clamp" low into 400ppm for anything less than the maximum tested value, which is perhaps a nicer sensor behaviour. There is a significant unit-to-unit difference in response, as noted in https://www.idt.com/us/en/document/rep/ksi-report-zmod4410-gas-sensors-compliance-ubas-iaq-study?language=en , but this seems to be calibrated out to achieve their claimed accuracy ranges:

It's nice to see this level of detail available openly, as I have not seen this level of detail for other sensors, but the performance perhaps depends on the algorithm (the latest being their V2) using AI. There are also separate firmwares for fan control and sulfur odour detection. They also say the following in their datasheet (which has no information on I2C registers):

For implementing the sensor module in a customer-specific application, detailed information on the programming is available. The recommended requirements for the host MCU are 16kB flash for ZMOD4410 related firmware code, 1kB RAM for ZMOD4410 related operations, and the capability to perform I2C communication, timing functions, and floating-point instructions.

I suspect this is a conventional non-AI algorithm and that even the I2C register map is subject to agreement on some terms/conditions? I suppose the RoadTesters may be able to find out.

- Gough