The SCD30 and the SCD4x, and Which One Your Product Wants
Two Answers to the Same Question
Sensirion's carbon dioxide line splits into two parts that look interchangeable in a catalogue and are not interchangeable in a design.
The SCD30 is a conventional optical sensor. It shines infrared through a gas cell and measures how much is absorbed at the wavelength carbon dioxide takes up, which is a well understood technique with decades behind it. That approach needs an optical path, so the part is comparatively large, and it needs the emitter running, so it draws real current.
The SCD4x, meaning the SCD40 and the SCD41, uses photoacoustic detection. The physics of the absorption is the same, but instead of measuring the light that survives the journey it measures the tiny pressure pulse produced when the gas absorbs a modulated beam. Because the detector is a microphone rather than an optical path, the whole sensor collapses to roughly a centimetre square, and the power profile becomes something a battery device can live with.
Between the two SCD4x variants, the practical difference is range and modes. The SCD41 is specified over a wider concentration range and offers a single-shot measurement, which is the mode that makes battery operation genuinely viable. If the device sleeps between readings, that is the part.
Pick On Power and Package, Not Accuracy
Both families are accurate enough for the things people actually do with carbon dioxide, so the specification comparison is rarely what should decide it.
If the device has mains power and space, the SCD30 is the easier component to be confident about. The optical technique is mature, the part is forgiving, and it happens to carry a humidity and temperature sensor on board that is not sitting inside a self-heating package.
If the device runs on a cell for years, the SCD30 is essentially out and the SCD41 in single-shot mode is what makes the product possible. Take a reading, sleep, and the average current lands somewhere a battery can sustain. Wall-mounted room sensors, desk units and anything retrofitted into an occupied building end up here for exactly this reason.
If the device is small, the SCD4x wins on volume alone. There are enclosures that simply cannot accommodate an optical cell, and no amount of preference changes that.
The one place the comparison does matter is at high concentration. Applications above the ordinary indoor range, controlled atmosphere storage, growing operations dosing carbon dioxide deliberately, fermentation, need to check the specified range of the part rather than assuming a sensor built for occupancy will cope.
The Self-Calibration Assumption
Every low-cost carbon dioxide sensor drifts, and essentially all of them offer an automatic correction that hides the drift by making an assumption about your building. Whether it is enabled out of the box varies by part, so check rather than assume, in both directions. Understanding the assumption itself is the single most valuable thing in this article.
The correction works like this: over a rolling window of days, the sensor tracks the lowest concentration it has seen, and it assumes that minimum represents outdoor air. Outdoor air is a known quantity, currently a little over 400 parts per million and climbing year on year, so the sensor nudges its baseline until that minimum reads as outdoor.
In a home or an office that empties overnight, this works beautifully and requires nothing from you. In a space that is never unoccupied, it is actively harmful. A ward, a control room, a server hall with people in it around the clock, a greenhouse being dosed on purpose, or a sealed room with poor ventilation never returns to outdoor concentration, so the sensor takes the lowest thing it saw, which might be 700 parts per million at four in the morning, and decides that is 420. Every subsequent reading is then several hundred parts per million too low, and it stays that way, and the data looks entirely plausible.
There are two honest ways out. Either make sure the sensor genuinely sees fresh air often enough for the assumption to hold, which for a portable or serviced device can mean a documented procedure of taking it outside periodically, or disable the automatic correction and perform a forced recalibration against a known reference on a schedule you own.
Whichever you choose, record it. A fleet where half the units are automatically correcting and half were manually calibrated eighteen months ago is a fleet whose numbers cannot be compared with each other, and that is usually discovered when somebody tries to rank buildings by air quality.
The automatic baseline is not a calibration. It is a guess that your building empties, and it is wrong in exactly the buildings where air quality matters most.
Pressure Compensation Is Not Optional
Both techniques measure how many molecules are in the beam's path, and how many molecules are in a given volume depends on pressure as much as on concentration. Feed the sensor the wrong ambient pressure and the reading is proportionally wrong.
For a device at sea level that never moves, the default is fine. For anything deployed at altitude the error is significant and systematic, and it is trivially avoidable because the correction is a single value written to the sensor at commissioning. A device installed in a mountain town or a high plateau without this set will read consistently and confidently wrong.
Where it becomes more than a one-time setting is on devices that move, and on installations where the weather genuinely matters. A tracker or a portable unit changing altitude should be fed a live pressure reading, which is a good reason to put a barometric sensor alongside. Weather-driven pressure swings at a fixed site are a smaller effect than altitude and are worth compensating if the application is precise.
The practical advice is to make the pressure or altitude value part of device provisioning rather than a firmware constant. A constant compiled in is a constant that will eventually be wrong for a unit somebody moved, and nobody will remember why that one building reads differently.
The Temperature Offset Nobody Sets
This is the single most common field mistake with the SCD4x and it is worth being blunt about.
The part carries its own temperature and humidity sensing, and it heats itself while measuring. The die therefore sits warmer than the room, and the temperature it reports is its own package temperature, not the air. Straight out of the box, in a typical enclosure, that reading can be several degrees high, and the humidity reported alongside is correspondingly low for the reasons covered in the humidity article.
The sensor provides a configurable temperature offset for exactly this. The manufacturer's default is a reasonable guess about a reference design, and it is a guess about a board that is not yours. The correct value depends on your enclosure, your power profile and how often you measure, and it has to be determined by putting the finished device next to a reference in a stable room and reading the difference once everything has settled.
Two consequences follow. First, if the product reports room temperature, that number should come from a separate sensor placed properly rather than from the carbon dioxide part, which is the cleaner design and costs about a euro. Second, if it must come from the SCD4x, the offset is a per-design calibration step, and the design cannot be changed afterwards without redetermining it. A revision that moves the sensor two centimetres or changes the reporting interval changes the answer.
Getting a Trustworthy Reading
A few operational details separate a fleet that behaves from one that does not.
Give the sensor time. All of these parts need a warm-up before the first reading is meaningful, and a device that transmits immediately on power-up will send one bad value every time it reboots. Discard the first few readings in firmware rather than explaining the spike later.
Let it see the room. The sensor needs air exchange with the space, not with the inside of a sealed case. Vent slots that create a path, and a position away from the direct exhalation of anyone sitting near it, because a sensor a foot from someone's face measures that person rather than the room.
And do not put it where the answer is already known to be wrong: beside a window that opens, above a radiator, in the supply air stream of the ventilation you are trying to control, or in a corridor if you are trying to characterise a meeting room.
When This Is the Wrong Sensor
Carbon dioxide answers one question well, which is whether a space has enough fresh air for the people in it. It is a poor proxy for several things people reach for it to do.
It says nothing about particulates, combustion products or chemical contamination. A room can be at a perfectly comfortable concentration and full of smoke, and particulate measurement is a different instrument entirely.
It cannot detect an unoccupied room quickly, because the concentration decays over tens of minutes. For fast presence detection it is the wrong physics and a motion sensor is the right one, with carbon dioxide supplying the quantity rather than the trigger.
And where the requirement is a safety measurement rather than a comfort one, in a cellar, a brewery, a cold store using carbon dioxide as a refrigerant, that is a certified gas detector with an alarm and a service schedule, not an air quality sensor.
What I Provide
I put these parts into devices, which means the decisions above are made in the design rather than found in the data: the variant chosen against the power budget, the offset determined on the real enclosure, the pressure value written at provisioning, and a calibration policy decided deliberately instead of inherited from a default.
Where a fleet is already out there and the numbers are being questioned, the fastest way to find out what is happening is to sit a few units beside a reference for a week and look at the disagreement. Baseline drift, a missing pressure correction and a self-heating offset all produce plausible-looking data and each has a different fix, which is why guessing between them tends to end in replaced hardware that was never faulty.
Does this describe your project?
If any of the above sounds like something you are dealing with, tell me about it. You will get a straight read on the right approach for your situation, and the first conversation costs nothing.
Start a conversationPrefer to see the finished thing first? There is one running on real devices
