Building a room CO2 monitor? Test the enclosure before trusting the display

A CO2 sensor is sending numbers to your controller, and the first display looks convincing. Now the project needs to become an object someone can leave on a desk. Where should the sensor sit, how will room air reach it, and what happens when the processor and screen warm up inside the case?

Those questions belong in the prototype stage. A September 20, 2026 build log from Experimental Engineering describes moving a room monitor toward a local display while still on a breadboard, and explicitly leaves enclosure checks for later. On our bench we reached the same point with a GraftSense SCD41 module and a GraftPort-RP2040 board running MicroPython: reliable readings first, then a plan for testing the physical arrangement around the sensor.

First establish what the sensor measures

The SCD41 measures CO2 using photoacoustic NDIR sensing, and also reports temperature and relative humidity. It is not a general detector for every air pollutant, and a changing CO2 number alone does not show that a room is safe or that a ventilation product meets its requirements.

Our setup had the module on a short I2C cable, with no enclosure, no calibrated reference instrument and no documented room test. So the useful result is a working measurement path, not validated room-monitor accuracy.

Reproduce the bench connection before changing the packaging

We used the I2C0 connector with GP4 for SDA and GP5 for SCL, on a 100 kHz software I2C bus. After a three-second startup delay, the program scanned for the sensor's fixed address 0x62, initialized the driver and printed the sensor's serial number.

Check your module's power input and signal levels before copying that connection to another board. The sensor chip's allowed supply range and a breakout board's regulator arrangement are different specifications. Also plan for measurement current peaks: the 2022 specification we worked from lists up to 205 mA at 3.3 V, even though average figures in some modes are much smaller.

We used an SCD41 MicroPython driver package (version 1.0.0). The program set an altitude of 100 m, a temperature offset of 2 °C and automatic self-calibration, saved those settings and started periodic measurement. Those were our example's settings, not defaults to copy into every installation.

Altitude should match the application. The temperature offset should be found in the intended physical arrangement and measurement mode. And saving settings is a configuration step, not something to do on every boot of a frequently restarting prototype, because the sensor's settings memory has limited write endurance.

Keep the measurement sequence visible

The loop waited for the sensor's data-ready flag, read CO2, temperature and humidity, printed them and slept five seconds. Checking readiness matters: a display can refresh faster than the sensor produces new data, and repainting the last value does not create a fresh measurement.

The driver checks a CRC on each returned data word, which catches damaged I2C transfers. That is still separate from measurement accuracy: a valid packet can faithfully carry a reading from a sensor badly placed in a warm case.

Here is the start and end of the recorded sequence:

CO2: 981 ppm  Temp: 31.07 °C  RH: 53.72 %
CO2: 1006 ppm  Temp: 31.11 °C  RH: 53.95 %
...
CO2: 1158 ppm  Temp: 30.97 °C  RH: 55.97 %
CO2: 1204 ppm  Temp: 30.95 °C  RH: 56.19 %

CO2 went from 981 to 1204 ppm, temperature stayed around 31 °C, and humidity rose from about 53.7% to 56.2%. That confirms the setup produces changing output. It does not tell us why the concentration rose, what the true room value was, or whether the temperature offset was right.

Carry that distinction into the product interface. Show warming-up, unavailable and stale-data states rather than a plausible fixed number after a failed read. A timestamp or a clear update indicator helps the team tell a live result from a disconnected sensor during testing.

Give the sensor access to the room, not the processor's warm pocket

Sensirion's SCD4x design-in guide recommends placing the sensor near a suitable opening, limiting trapped air around it and keeping it away from heat sources. It also covers turbulence, vibration and direct sunlight. More airflow is not automatically better: putting the sensor straight in a fan's stream creates a different problem from a sealed case.

For a first case prototype, make the sensor position easy to change. Compare the open assembly with the proposed closed case, keeping firmware, measurement mode and room conditions as similar as practical. Record temperature and CO2 after the device has settled; do not adjust offsets right after handling the board.

The design-in guide suggests a thermal settling period before comparing temperature with a reference. A fixed temperature offset can correct a steady bias, but not every change caused by a screen brightening or a radio switching on. The sensor's temperature-offset setting adjusts its temperature and humidity outputs; it is not a CO2 calibration control.

A five-second update interval also does not mean the sensor fully responds to a room change in five seconds. The specification gives a typical CO2 response time of 60 seconds to reach 63% of a step change, under its stated test conditions, and a finished enclosure may slow that further. Test the behavior you plan to show users rather than inferring it from the refresh rate.

Choose a calibration policy that fits the room

Automatic self-calibration depends on assumptions about the air the sensor sees. The specification assumes regular exposure to its low-concentration reference condition. A space that stays occupied, or has persistently elevated CO2, may not meet that assumption. Turning the feature on is an installation decision, not a guarantee that readings will correct themselves.

Forced recalibration is a different procedure: it needs a known reference concentration and the specified operating sequence. Do not force a reading to a convenient number just because two unverified monitors disagree. For an early prototype, document the environment, allow settling and compare with a suitable reference before deciding whether recalibration is justified.

Low-power operation changes the experiment too. We ran ordinary periodic measurement, not the sub-milliamp average case in the specification, which depends on widely spaced single measurements. If you switch modes for battery life, repeat the response and temperature checks in that mode.

Before refining the final case, aim for three pieces of evidence: stable communication, a reference comparison in the assembled device, and a documented response to a change in the surrounding air. Our bench setup covers the first. The other two are what turn a sensor display into a monitor people can read with confidence, and we have not yet run them.