SCD30 - CO2 sensor

[localhorst]

Sorry you're right, I didn't google it but just assumed it was one of those newer MEMS units.

It seems to be one of the best CO2 sensors in this price range at the time - nearly eliminating, due to its dual chamber, one of the biggest problems of NDIR sensors - the constant drifting and need to frequently recalibrating.

The SCD30 is really not small.

Yes, that's true. Quite wide and long. But on the other hand very thin.
But it shouldn't be a problem for me, as my housing should be big enough.

[TD-er]

About the accuracy or precision (two totally different things) of the internal temp/hum sensors...

My point is that they are inside a component which heats up and thus the temperature will be higher than the ambient temperature and the humidity is thus lower than ambiant.
For internal compensation algorithms to correct the measured CO2 concentration those are perfectly fine as they relate to the air being measured.
But for measuring ambiant temperature in the room it is kinda useless.

You can assume there is a constant amount of energy being used in the enclosure and given the volume and heat exchange capabilities of your enclosure will be constant, there is a rather fixed temperature offset.
Thus you can calculate the absolute humidity (or calculate dew point temperature), then subtract the constant temperature offset and use the previously computed absolute humidity or dew point temperature to compute a compensated relative humidity.

However this only applies when the environment doesn't change a lot, so this assumption can only be applied when your sensors operate in a small temperature range of just a few degrees and not being exposed to sudden change in air flow (e.g. next to a door or open window)

I know about the automatic base calibration (some brands call it ABC, no idea if this is a copyrighted or (TM) term)
You can also change this on SenseAir modules.
But be aware that on older S8 units (be careful with units sold before 2020 I guess, not 100% sure when the last faulty batches were sold) there was a firmware bug which only allows to lower this period and never increase it so you can render your sensor useless if you try changing it.

The MH-Z19 indeed cannot change this ABC period, but you can disable it.

I don't know how well this "2nd chamber" will keep on working over longer periods of time as it is extremely hard to keep all gasses sealed.
I can imagine this also puts some requirements on handling the device, like soldering, storage, etc.


One more thing to keep in mind when using NDIR sensors.
They really don't like IR "light", so direct sunlight is of course a big no-no, but also don't mount them directly above some heater as the black-body radiation also emits IR in the small spectrum where these NDIR sensors perform their measurements.

[localhorst]

I don't know how well this "2nd chamber" will keep on working over longer periods of time as it is extremely hard to keep all gasses sealed.
I can imagine this also puts some requirements on handling the device, like soldering, storage, etc.

Yes, it puts some requirements on the handling. Especially regarding mechanical stress given to the chambers.
Sensirion is having a very good documentation and is pointing out, that the chambers should never be touched or pressed.
As well, that first calibration is crucial - as the sensor might have gotten any stress during transportation, soldering and building in in its end location.
Here is an interesting chart on page 3/5 how a mechanical stressed sensor might shift and how much a calibration brings it back on track.

Regarding keeping the gas / the sealing, I haven't read anything that this is a problem.

Coming back to temperature / humidity:
I guess I'll let one device run with all sensors, BMP280, SHT21 and SCD30, simply compare and see how the difference is.
Still waiting for the SCD30 - they are stated as already arrived in my town since yesterday. Well, German "Post"...

[localhorst]

Having my first SCD30 running and setup since this afternoon, I can confirm those settings:

Everything seems to be according to the documentation, if I'm not mistaken. Screenshots are attached.

Maybe the comment in I2C options should be modified, to not be so confusing with msec and usec.

But I've left this settings untouched / default (400000/100000):

The SCD30 is really not small.

To be honest, I've been quite surprised as I had them first in my hands. They are not that big, like I expected.
Compared to the SenseAir S8, they are not that much bigger:

IMG_2738.jpeg (1.29 MiB) Viewed 24521 times

IMG_2737.jpeg (1.26 MiB) Viewed 24521 times

(FRC) Calibration in fresh air definitely needs to be done at first. This first SDC30 had a shift of around 200 ppm in plus, but everything fine after calibrarion.
Double check a couple hours again in fresh air is fine, returning to 400 ppm.

Temperature needs to be corrected by

Code: Select all

%value% -5.9

Humidity by:

Code: Select all

%value% +11

This needs to be checked in the long turn, but for now, it seems to be running pretty smooth.

[Ath]

Maybe the comment in I2C options should be modified, to not be so confusing with msec and usec.

Some other sensors (may) need a more precise clock stretch setting, and most modern sensors don't need it at all, so it's not used that often, I guess.
The low-level interface offers the usec resolution adjustment, so that's made available here.

But I've left this settings untouched / default (400000/100000):

The default values should not need adjusting for this sensor, and it is already set to "Force Slow I2C speed" by default, as the SDC30 specs say it only supports up to 100 kHz.

For some reason this device seems to use a rather old implementation of an I2C interface, not sure why it's not updated, as 400 kHz and no need for clock-stretching (that's really a kludge) has been the standard for I2C for a really long time.

[TD-er]

The clock stretch parameter is an upper limit.
So if any other devices needs more time, it will not affect this one.
It is like a timeout.

As Ton said, you shouldn't need to set the "normal" clock speed for I2C.
However if there are other devices connected to the same I2C bus and this SCD30 is really not tolerant to high clock frequencies, then you might need to lower the normal clock speed too.
But if that's really an issue, you might want to consider using an I2C port expander as this also can isolate clocks not intended for a specific port.
Those I2C port expanders are really versatile as they can be used as level converters to isolate 5V devices in a separate bus and allow for longer cables to a specific device (and thus need special settings like lower clock speed, maybe stronger pull-up resistors, etc)

[localhorst]

Great, thank you both!

But I've left this settings untouched / default (400000/100000):

The default values should not need adjusting for this sensor, and it is already set to "Force Slow I2C speed" by default, as the SDC30 specs say it only supports up to 100 kHz.

Fine - and yes, the SCD30 is doing its job reliable and without any problems so far.

As Ton said, you shouldn't need to set the "normal" clock speed for I2C.
However if there are other devices connected to the same I2C bus and this SCD30 is really not tolerant to high clock frequencies, then you might need to lower the normal clock speed too.

Currently, there is the SSD1306 display on the same I2C bus - but doesn't seem to bother.
For the moment I've disconnected the BMP280 and SHT21 - who would also run on the same I2C bus. I need to solder the cables for connection.
Do you think connecting the both will cause trouble with the current settings and the SCD30?

But if that's really an issue, you might want to consider using an I2C port expander as this also can isolate clocks not intended for a specific port.
Those I2C port expanders are really versatile as they can be used as level converters to isolate 5V devices in a separate bus and allow for longer cables to a specific device (and thus need special settings like lower clock speed, maybe stronger pull-up resistors, etc)

Thank you very much - but I'd rather leave the BMP280 and SHT21 out of the assembly than doing this big effort.
In my use case it's nice to have more or less precise temperature, humidity and air pressure - but this is second. I really need the precise CO2 measurement for my automation - and it should just reliably do.
For temperature etc, there are more than enough sensors in our apartment and temperature / radiators are controlled very well and with other sensors.
Anyways, I'll solder the needed cables to connect and try out the BMP280 and SHT21 together with the display and the SCD30.
When all the testing is done, I'll modify 3 more measuring stations with the SCD30 / exchanging the Senseair S8.

Have a nice weekend!

Kevin

[TD-er]

Like I said, the SCD30 should not be bothered by other devices running at higher frequencies, as long as it isn't being addressed and needs to communicate at those higher frequencies.
So it should be perfectly fine to have other I2C devices running at 100 kHz or 400 kHz without issues.

However, since this device apparently needs clock stretching, there is a possibility the device might be not as flexible as it should be.
So there is a slight chance the setting you chose by accident might be the better option for this specific sensor.

But if the SCD30 is not bothered by the other I2C devices running at higher clock frequencies, then please run at least the display at 400 kHz as this takes 1/8th of the time to send the same data and thus keeps the ESP less occupied so it can act more swiftly on events etc.

[Ath]

Currently, there is the SSD1306 display on the same I2C bus - but doesn't seem to bother.
For the moment I've disconnected the BMP280 and SHT21 - who would also run on the same I2C bus. I need to solder the cables for connection.
Do you think connecting the both will cause trouble with the current settings and the SCD30?

Having multiple I2C devices, on the same I2C bus, usually implies there are also multiple pull-up resistors installed, but having too many in parallel may cause issues for some devices, so you might need to disable (remove?) some pull-up resistors from the sensor boards. Having 2 in parallel, like the display and the SCD30, usually isn't problematic, but having 4 in parallel could be.

[localhorst]

I'm sorry, but I'm not sure if I really understand what you are trying to explain to me. I'm not an expert in this topics.
In this case, I've removed all other sensors for the moment, so it's only the display and the SCD30.
I've set I2C ClockStretchLimit to 20. Then I've started the whole thing up, seeing after a short while that the sensor freezes. After that, I've set it to 150000.
And now it seems to be running fine.
So my current settings are:

• SCD30 Force Slow I2C speed: on (default / unchanged)
• I2C ClockStretchLimit: 150000 (changed)
• Check I2C devices when enabled: off (changed)
• I2C Interface / Clock Speed: 400000 (default / unchanged)
• I2C Interface / Slow device Clock Speed: 100000 (default / unchanged)

Especially in hinsight of a reliable running SCD30: should it be different at some point? Should I change the I2C Interface settings to 50000, just like dmode90 did?

[localhorst]

Having multiple I2C devices, on the same I2C bus, usually implies there are also multiple pull-up resistors installed, but having too many in parallel may cause issues for some devices, so you might need to disable (remove?) some pull-up resistors from the sensor boards. Having 2 in parallel, like the display and the SCD30, usually isn't problematic, but having 4 in parallel could be.

Thank you!
I guess I'll give it a shot. If it's making trouble, then I would leave the BMP280 and SHT21 away.
How may problems with too many pull-up resistors show / look like? Not getting values or nonsense values or not working at all?

[TD-er]

Lower I2C clock is usually only needed when your cabling is a bit non-standard.

There are several generations of the I2C standard.
The most common ones are running at 100 kHz and 400 kHz.
If you are using long cables or experiencing noise, you might need to lower the clock frequency.

And to be honest, devices which need to use clock stretching are often also not really compliant regarding other aspects of the I2C standard.
So it is almost useless to make assumptions on what would be the best strategy when using such devices.

[TD-er]

[...]
How may problems with too many pull-up resistors show / look like? Not getting values or nonsense values or not working at all?

Unreliable or no communication at all with some (or all) I2C devices.
Having too many pull-up resistors will create a "stronger pull" and thus the devices need to pull harder to get the logic level down to GND.
On some devices this may also take longer, so you could lower the clock frequency to mitigate such issues.
One might prefer "stronger pull-up" resistors though when the cables used have too much capacitance and thus "round off" the edges of the digital signal. With stronger pull-up resistors you can get a faster rise time allowing for higher clock frequency on longer cables, but then the time needed to pull the level down must be equal and if the devices can't pull strongly enough, you still end up with "rounded edges" of the signal on the falling edge and thus need more time to get below some logic level.

[localhorst]

And thank you again, very interesting!
Well, it has been running for more than two years with 3 devices on the I2C - now there would be plus one. Like I said, I'll give it a shot.

Please allow me another maybe dumb question: As it is possible to change the I2C pins away from D1+D2 - would it be possible to add a second, separated I2C channel on another set of pins, like D6+D7?

[Ath]

Please allow me another maybe dumb question: As it is possible to change the I2C pins away from D1+D2 - would it be possible to add a second, separated I2C channel on another set of pins, like D6+D7?

Currently, ESPEasy only supports a single I2C bus. Some ESP32 models allow multiple I2C busses, but we haven't added support for that yet, as we can create separate channels by using, as mentioned, an I2C multiplexer, that can have 2, 4 or 8 separate channels.

[TD-er]

ESP8266 doesn't support multiple I2C busses. (and as Ton said ESPEasy doesn't have support yet for the 2nd possible bus on ESP32 devices)

[localhorst]

And again - thanks a million, you are awesome guys!

[localhorst]

Some feedback, all 4 CO2 measurement stations are now changed from Senseair S8 to SCD30 and running smoothly for 24 hours.
The results are looking really good and perfectly logical to me:

Bildschirmfoto 2024-01-17 um 23.31.54.png (218.78 KiB) Viewed 21305 times

You can see directly when somebody came home, went to bed or even the balcony door have been opened.

My learnings for the moment:

• After building in the SCD30 to its end location (and using it for the first time in general), you definitely have to do a calibration. All 4 sensors have been off by 100-200 PPM in plus
• In my setup, it was no problem to add back the BMP280 and SHT21 together with the display and the SCD30 to the same I2C - it works fine
• So I left away using the temperature and humidity sensor of the SCD30. It needed high correction, as the device seems to add quite a lot warmth to it
• The calibration command scdsetfrc,<co2_ppm> sometimes needs some time to take effect (a couple of minutes).
• The load on the ESP seems to be very less, compared to the S8. Now I have normally between 5 and 8% - with the S8 it has been often more than 40%.
  Might this depend on using the HW serial port for the S8, instead of I2C for the SCD30?
  Or might it be just the updated EPEasy (before the update, the stations ran on ESP82xx_mega-20211224)?
• In comparison to the S8, the SCD30 are showing higher (but realistic) CO2 levels. The S8 have been always shifted with ABC after a short while, showing too low results (as taking e.g. 600 PPM as 400).
  But time will tell how the SCD30 with its dual channel will hold after a couple of weeks and months, too early to judge.

Coming to the SCD30 ESPEasy plugin itself, I think everything is just fine - thank you very much!

[TD-er]

Nope, I still need to look into the Modbus code for the SenseAir.
Especially the S8 responds quite slow and the current code in ESPEasy does wait for a response when reading a modbus register.
This is a bit silly, but it does require quite a lot of code change, so I have been postponing this for way too long.

For the Eastron energy meters I already have a proof of concept running for a few months now, where I do read registers asynchronuously and I plan on implementing this for all Modbus RTU plugins.
This does lower the CPU load a lot and makes reading the sensors way more flexible.

But until then, reading from the S8 takes about 200-ish msec per read of a register.