CO2 Bricklet 2.0 accuracy

[Superp]

Hello,

I have two CO2 Bricklet 2.0's:

Bricklet A "blue": bought December 2021. I had no prior experience with a CO2 sensor, but I found the PPM on the high side, as mentioned in this topic.

So, I bought another one:

Bricklet B "green": bought February 2022. It appears to consistently produce a much lower reading.

This week I had the time to mount both Bricklets side by side and log their readings. This is the result:

Both Bricklets have been reset and disconnected/reconnected multiple times. Both have been mounted outside in "fresh air" for an entire day. This makes no difference.

What am I doing wrong? Am I missing a step? 

[borg]

Did you configure the offset for temperature or air pressure in one of the Bricklets?

The manufacturer writes:

Zitat

CO2 concentrations < 400 ppm may result in sensor drifts when ASC is activated. For proper function of ASC field-calibration algorithm SCD30 has to be exposed
to air with CO2 concentration 400 ppm regularly.

Maybe you can make sure that both sensors see fresh air for some time and then not? At some point both should re-calibrate themself to 400ppm and after that the should have the same behavior with different drift of both sensors, until they re-calibrate to 400ppm again.

[Superp]

Quote

Did you configure the offset for temperature or air pressure in one of the Bricklets?

No, these are 0 (zero) for both Bricklets, and both have been reset. In my experience, even setting these to extreme values does not cause a difference this big.

Quote

Maybe you can make sure that both sensors see fresh air for some time and then not?

I tried that, repeatedly. The day before the experiment that produced the graph above, both sensors sat outside for eight hours. This did not seem to trigger a re-calibration.

The documentation says:

Quote

Optimal working conditions are given when the sensor sees fresh air for one hour every day so that ASC can constantly re-calibrate. ASC only works in continuous measurement mode.

So you would expect 8 hours to be enough. Clearly I'm missing something.

What is this "continuous measurement mode" ? 

[borg]

The continuous measurement mode is always activated in the code of the Bricklet. So the "automatic sensor calibration" (ASC) should be running.

I am not sure why the two sensors don't converge. They should at some point both measure 400ppm when they see fresh air.

Here is the official datasheet from Sensirion about the calibration: https://sensirion.com/media/documents/33C09C07/620638B8/Sensirion_SCD30_Field_Calibration.pdf

The only other thing that i can think of is that we implement the FRC calibration (forced recalibration):

Zitat

Set Forced Recalibration value (FRC)
Forced recalibration (FRC) is used to compensate for sensor drifts when a reference value of the CO2 concentration in close
proximity to the SCD30 is available. For best results, the sensor has to be run in a stable environment in continuous mode at a
measurement rate of 2s for at least two minutes before applying the FRC command and sending the reference value. Setting a
reference CO2 concentration by the method described here will always supersede corrections from the ASC (see chapter 1.4.6)
and vice-versa. The reference CO2 concentration has to be within the range 400 ppm ≤ cref(CO2) ≤ 2000 ppm.
The FRC method imposes a permanent update of the CO2 calibration curve which persists after repowering the sensor. The
most recently used reference value is retained in volatile memory and can be read out with the command sequence given below.
After repowering the sensor, the command will return the standard reference value of 400 ppm.

i always thought that the automatic calibration would work best in most environments.

Maybe we can add the FRC to Brick Viewer as an option to force calibration to fresh air.

[Superp]

Hi Borg,

Thanks for your answer.

That Sensirion document is very interesting.

Implementing an FRC trigger sounds like a really good idea, provided:

1. It would be possible to supply an actual realistic reference value with it (rather than assuming PPM=400).
2. It would also be possible to switch off (and back on) ASC.
3. All this would be part of the API/bindings, not only Brickv.

That's what I think. If I can help in any way, let me know (I can buy another CO2 Bricklet 😉)

Some thoughts:

1. Are we really, positively, sure ASC is enabled? Because "ASC is an optional feature and is deactivated by default" (Sensirion). Is it enabled at TF once after assembly? Or by the FW after each powerup? I could not find it in the FW.

2. ASC works by assuming that the lowest concentration it measures equals exactly 400PPM (right?).  I think it is fairly unlikely that indoor air reaches a CO2 concentration of 400PPM. @Michael_S

3. The Sensirion doc seems to suggest choosing either ASC or FRC, depending on "conditions at the end user".

4. I am wondering if ASC does not kick in because of turbulence. It is a challenge to find air that is both really fresh and not moving much. Air movement does greatly affect the PPM reading, I've noticed.

 

[Michael_S]

Hello Superp and borg,

I agree with your opinion that the addition of FRC would be a useful feature. Especially to restore the functionality of sensors that have such strong deviations, like sensor A of Superb.

As shown in the example on p. 3 of the Sensirion document, such strong deviations can occur e.g. if a sensor has fallen down (or has been treated roughly during shipping...). My assumption is that the optics in the sensor shifts a few micrometers, since the sensor uses an optical measuring principle, specifically the absorption of infrared radiation by CO2. (By the way, this is exactly how the greenhouse effect / climate change works...).

However, as a default setting, I also think the ASC is reasonable.

To reach 400 ppm in a common room is indeed possible, e.g. in rooms that are mechanically ventilated and where no persons are present for approx. > 5 hours. Alternatively, in case of long-term ventilation with fully opened windows (without persons present). However, depending on the outside temperature and wind, this can take up to 1 h (please switch off the heating beforehand). Thereby, however, the air inside becomes very dry....

An alternative idea to run the FRC: take a waste bag and shake it outside several times, so that it is completely flushed and filled by outside air.
Put the sensors inside, close the opening / cable entry and press the FRC button that borg will soon install in BrickViewer :)

Greets

[Superp]

Thanks very much, Michael, for your valuable help.

The things is, I have been running this "A" sensor for over three months, and I never saw any sign of it re-calibrating. Not inside, not outside. It just reports values that are unrealistically high.

I was pondering using some kind of container to position it outside (in "fresh air") without being subject to turbulence (and rain), to get it to auto-calibrate ("ASC"). And then you came up with the smart idea of using a waste bag.

So, I did this: I took a new bin bag, opened it outside, waved it about several times, threw in the sensor on a long cable, sealed the bag shut, took it inside, connected it, and logged its reading for exactly 48 hours.

I thought it might be interesting to share the result:

 

The bag is still slightly puffed up, so hardly any air is escaping.

The PPM in the bag must be much lower than what the sensor reports. But it is not calibrating, or the calibration does not have the desired effect.

For now, I have no more ideas.

 

[Michael_S]

Hi Superp,

this indeed looks like no calibration is taking place.
The visible drift may be due to temperature and/or pressure changes over the days inside the closed bag; depending on if compensation was active.
However, the absolute level is definitely wrong or strongly shifted.

At the risk of making myself unpopular, however: since the calibration is obviously failing or not happening, you might consider reclaiming the sensor; after all, there is a two-year warranty. With a sensor that was purchased just five months ago, such a measurement error should not occur.

bearbeitet April 14, 2022 at 16:29 von Michael_S

[borg]

Am 5.4.2022 um 17:19 schrieb Superp:

Are we really, positively, sure ASC is enabled?

Now, this is rather embarrassing, but i think you are onto something. The enabling is supposed to happen during the flash/test processes, but i don't think it is done properly 😯.

I read the ASC configuration back on a sensor that has gone through the flash/test process and it was not enabled.

I just released firmware version 2.0.3. It enables ASC on each startup (https://github.com/Tinkerforge/co2-v2-bricklet/commit/9a688c7b36326f0ab17b64a99df94bc330140709).

According to the interface documentation we should wait 7 days to see if it works:

 

[Superp]

Will test. Looking forward to receiving the beer.

[Superp]

Just kidding, of course. Will test though.

[Superp]

I have upgraded the firmware, power cycled, and ran the sensor in the famous "fresh air chamber" for 8x24 hours, logging the output. The sensor is still stuck somewhere around the 1200PPM mark. So, either it still is not calibrating, or it is, but there is a hardware problem.

If anybody has a suggestion, I welcome it, because I see no other option than to return this sensor.

[borg]

I am out of ideas. We will ship you a new CO2 Bricklet 2.0.

You will get an acknowledgement email, please check if the address is correct.

Very sorry for the trouble!

[Superp]

No worries. Yes, I received your mail & replied. Thanks for your help.

On the positive side, we got better firmware!

Grüße!

[Superp]

Cross reference: ASC beim CO2 Bricklet deaktivieren