co2 sensors to measure co2 levels in a car

Gas Sensing Solutions investigates levels of CO2 on car journeys

Ever wondered why long car journeys make you feel tired and sleepy? Is it the boredom of endless, never changing motorways or perhaps something else? Carbon Dioxide sensor specialists, Gas Sensing Solutions, wondered if it could be a build-up of CO2 gas, because at levels of 1000 ppm and above people can become drowsy and lethargic. So they took a CO2 datalogger from their gas sensor range on a road trip to find out how CO2 levels changed throughout the journey.

co2 sensors to measure co2 levels in a car

Why can car journeys make you feel sleepy?

Dr David Moodie, Technical Manager at GSS, explained, “This follows on from our trip to Asia where we used our CO2 datalogger to measure CO2 gas levels on planes, trains and taxis. We were surprised that levels were the worst in taxis – peaking at an astonishing 10000 ppm on one journey – so we decided to check the levels on our own road trip in the UK.”

datalogger to measure co2 in a car

Measure CO2, temperature & humidity in a car

Before the datalogger took to the road, it was first used to test CO2 levels in a stationary car. This would show the impact on CO2 levels with a group of 4 people in a confined space. The engine was switched off and the windows kept closed to avoid any flow of fresh air inside the vehicle. The datalogger showed that when the passengers got inside the car, the CO2 level was 1000 ppm. It then rocketed to almost 4000 ppm in just 15 minutes. At that stage, the atmosphere inside the cabin had become extremely stuffy and unpleasant.

Graph showing CO2 levels in a stationary car

Graph showing CO2 levels in a stationary car

Next came the road trip. The first car journey involved two people travelling to the supermarket. The CO2 from their exhaled breath increased the concentration of CO2 in the car cabin to around 1400 ppm. Surprisingly, it only took about forty-five minutes to reach this level, which shows how quickly CO2 levels can rise. The datalogger was then left in the car overnight with the windows closed. The graph shows just how long it takes for the CO2 to disperse from a closed car, taking until around 9am the next day to drop down to nearer ambient levels of CO2.

graph showing CO2 levels in car recorded with a datalogger

CO2 levels recorded with a datalogger

The second car journey recorded four people travelling non-stop from Wales to Scotland. With four people, the level of CO2 shot up even faster, reaching 2000 ppm in about twenty minutes. This is the level where CO2 symptoms can start to cause loss of concentration, headaches and sleepiness for example. Fortunately, they opened the windows to bring in fresh air from outside, which reduced the CO2 to more acceptable, ambient levels within an hour.

Dr David Moodie, added, “Our real-world datalogger measurements show how CO2 levels can rapidly build up in an enclosed space with several occupants – and in a relatively short space of time too.  The results on both journeys exceeded The World Health Organisation* guideline that CO2 levels should be below 1000 ppm.” 

Datalogger details

The datalogger used in the experiment measures CO2 concentration, air pressure and temperature, along with relative humidity every few minutes. This unit was designed and built by GSS and it uses one of its low power, ambient air, CozIR®-A sensors. GSS’s unique LED technology at the heart of its sensors means that it has a very low power consumption, unlike many other CO2 sensors that need mains power. This enables battery-powered CO2 monitoring products to be created, such as this datalogger, that is able to record over a 2-week period without needing a change of battery.

co2 datalogger for measuring co2 levels

GSS CO2 datalogger with a CozIR sensor inside

Dr David Moodie, concluded, “This ability to be battery powered for long periods has opened up a whole new range of design possibilities for CO2 monitors. Now it’s possible to have handheld breath monitors with high speed sensing for people with respiratory conditions, portable leak detection instruments, handheld MAP analysers, and wireless air quality monitors for IoT applications. These are just a few examples of what is achievable, the possibilities really are endless.”

Drowsy driving facts and stats

According to a 2005 poll by the American National Sleep Foundation, 60% of adult US drivers – about 168 million people – said that they have driven a vehicle while feeling drowsy in the past year. More than one-third, (37% or 103 million people), have actually fallen asleep at the wheel. Of those who have nodded off, 13% say they have done so at least once a month. According to data from Australia, England, Finland, and other European nations, drowsy driving represents 10 to 30 percent of all crashes. More details at and

A paper on ‘Modelling CO2 concentrations in vehicle cabins’, which focusses on the build-up of CO2, can be found at:

In an article entitled ‘The Drowsy Driving Off Switch’, Air Quality Consultant Dale Walsh found that recycling the air in a car cabin causes CO2 levels to rise rapidly. In his experiment, it took an hour for a level of 2500 ppm to be reached when recycling the air with only one occupant in the car. The article is available at:


How to monitor CO2 levels with a BBC micro:bit and a bitty data logger

Written by Martin Woolley |

Visualising the Invisible!

I was recently contacted by a professional educator, based in Alberta, Canada called Jennifer Ferguson. Jennifer (@FergeeksonGirl ‏ on Twitter) works for a charitable, education and outreach organization called Let’s Talk Science (@LetsTalkScience) and has been using Bitty Data Logger.

The reason Jennifer made contact was to talk about her current project, Living Space, an education initiative developed with the Canadian Space Agency, and to ask for some assistance.

Living Space is concerned with monitoring key environmental conditions, including carbon dioxide (C02) levels. Jennifer wanted to be able to connect a Carbon Dioxide sensor to a micro:bit and to communicate its readings to Bitty Data Logger over Bluetooth so that the data could be visualised, logged and shared.

C02 Monitoring

C02 monitoring is widely used in all sorts of applications, many of them really important, some of them surprising. Examples include heating, ventilation and air conditioning (HVAC) systems, large scale city environmental monitoring, and aspects of food production, including monitoring of plant cultivation environments and improved food storage. It’s used in laboratory incubators for monitoring cell cultures, and in healthcare for things like breath analysis applications where the sensor has to deliver results very rapidly, at around 20 measurements per second. Breath analysis data allows for monitoring conditions such as asthma. And of course, a C02 sensor being a sensor, it’s something you’d expect to find in larger scale connected systems which we might file under the umbrella term “Internet of Things (IoT)”.

Jennifer was working with an impressive sensor, the CozIR®-A made by Scottish company GSS (Gas Sensing Solutions). Some models, such as this one can take temperature and humidity readings as well as C02 measurements.

GSS CozIR®-A low power ambient air CO2 sensor

CozIR®-A ambient air CO2 sensor

Let’s start by getting to know the CozIR®-A sensor.

Connecting a micro:bit to the CozIR®-A Sensor

The CozIR®-A sensor has a number of pins on its underside. The important ones are GND,  3.3V power and serial receive (RX) and transmit (TX) pins. Yes, the interface is a UART interface, which allows serial communication, one bit at a time using two of the pins, one for transmitting bits and one for receiving. To connect the CozIR®-A sensor to a micro:bit, you make connections like this:

CozIR®-A Micro:bit
3V3 3V
TX RX (pin 1)
RX TX (pin 0)

Note how TX on the CozIR®-A is connected to RX on the micro:bit and RX to TX. This makes sense if you think about it. Data transmitted from the sensor has to be received by the micro:bit. Data transmitted by the micro:bit has to be received by the sensor.

Here’s what a micro:bit connected to a GSS CozIR®-A sensor looks like:


micro:bit connected to CozIR®-A CO2 sensor

close-up of the micro:bit connected to CozIR®-A CO2 sensor

Close-up of micro:bit with connections

GSS CozIR®-A CO2 sensor with connection

Close-up of GSS CozIR®-A CO2 sensor

Communicating with the CozIR®-A Carbon Dioxide Sensor

The GSS CozIR®-A sensor uses a simple protocol for sending and receiving data and commands over the UART connection with a microcontroller like our micro:bit. All commands and data consist of ASCII characters only and they’re all, always terminated with carriage return, line feed characters i.e. \r\n or ASCII characters 0x0D and 0x0A.

The software guide that comes with the GSS CozIR®-A sensor is very good, and it doesn’t take long to understand the protocol and pick out those commands and responses that are required for your purposes.

There are three operating modes defined. Mode 0, Command Mode stops the sensor from making measurements. It will respond to commands when it receives them, but otherwise is more or less dormant. Mode 1, Streaming Mode has the sensor making and reporting measurements every 500ms by default. Mode 2, Polling Mode makes measurements in the background but does not report them unless it receives an appropriate command from the connected micro:controller.

To request a particular mode #, the command K #\r\n must be sent. So for polling mode, the command is K 2\r\n. Note the space character between “K” and “2”.

For the best, most accurate readings, the sensor needs to be calibrated. The protocol supports calibrating the sensor in a number of ways, including in a known gas concentration, which is the recommended approach or, for those of us without a supply of a suitable reference gas, in fresh air.

Requesting fresh air calibration is achieved by sending the command G\r\n to the sensor.

Micro:bit and the CozIR®-A Sensor

Jennifer had already put together a MakeCode application which could acquire sensor readings from the CozIR®-A and display them on the micro:bit’s LED display. Her application made use of a handy custom block written by Simon Monk of Monk Makes that took care of the nitty gritty details of talking to the sensor, which made her application very easy to read. Here’s the original code which she sent to me:

MakeCode application code for co2 monitoring

MakeCode original code

The application starts by configuring the micro:bit serial communications system to use pins 0 and 1 from the edge connector instead of using the USB connector for serial data. It then sits in an infinite loop, calling one of three custom block functions to obtain a C02, temperature or humidity reading, depending on the value of a variable called mode. The mode variable can be changed by pressing button A so that you can switch from C02 to temperature to humidity readings at the click of a button. Values returned by the custom block are simply displayed on the micro:bit LED grid.

The CozIR®-A Custom Block and Serial Communications

The CozIR®-A custom block which the Let Talk Science application uses, works like this.

There are a number of functions which the application using the block will call, such as the function C02(). Functions like this one send a command to the sensor (in this case Z \r\n) by writing to the serial interface, wait for 200ms and then return the value of a variable which should now contain the latest measurement of the requested type.

    export function Co2(): number {



return co2



How the variable gets assigned the latest measurement, is explained by looking at another part of the custom block’s code. Responses to all commands are received from within an event handler, serial.onDataReceived which is called whenever there’s data waiting to be read from the serial port, as will be the case when a command has been processed. The response data gets read into a string variable, examined to see what type of response it is and then values extracted and assigned to the appropriate variable. For example, C02 readings always start with a Z then a space and then the value in parts per million (ppm). So this code checks for a response that starts with “Z” and then extracts the associated value:

response = serial.readUntil(serial.delimiters(Delimiters.NewLine))


value_str = response.substr(3, 5)

let value = parseInt(value_str)

// basic.showString(response.charAt(1))

if (response.charAt(1) == ‘Z’) {

let co2_uncompensated = value

co2 = co2_uncompensated + (altitude * 556) / 10000


As you can see above, it’s the variable c02 that gets returned by the Co2() function.

The Micro:bit Event System

The BBC micro:bit lets software components talk to each other using event objects. An event is just data which indicates that something in particular has happened and has an associated value or sub-type. Software components can both generate events and indicate that they’re interested in being notified about particular types of event happening elsewhere in the system, when they occur. For example, I might write some code that wants to know when either of the micro:bit’s buttons is pressed. The software component in the micro:bit firmware that is responsible for handling the buttons, known as a driver, generates events whenever buttons get pressed. All my code has to do to receive these events is to register its interest in this type of event using a micro:bit function, and specify what I want to happen when such an event takes place. In the MakeCode programming system, we’re given ready-made blocks for this purpose, such as the onButtonPressed block.

onButtonPressed block code

onButtonPressed block code.

Including the onButtonPressed block in my code, simply means “please tell me if a button gets pressed and execute this code when this happens”.

Events are said to travel along a message bus which you can think of as being like a pipe that events flow along, with some software components injecting event messages into the pipe and others syphoning off copies and processing them.

Technically, events are 32-bit numbers with the first 16 acting as an event identifier (ID) which tells us what type of event it represents and the second 16 acting as a sub-type or an associated value which can be as large as 65535.

Communicating with Bitty Data Logger

Bitty Data Logger uses the micro:bit event system. One of the nice things about the event system is that software components that generate or process events do not have to be inside the micro:bit! They can be connected to the micro:bit over Bluetooth using something called the Event Service. All MakeCode applications which use the Bluetooth package, automatically have the event service built into them, meaning that events can be used for bidirectional communication between the micro:bit and the other device, connected over Bluetooth.

Various event types are used by Bitty Data Logger. These are the ones which were useful in communicating CozIR®-A CO2 sensor data:

Event ID 9020 9030
Event Name Pin Selection Data
Direction of Communication bitty data logger to micro:bit micro:bit to bitty data logger
Purpose Let’s bitty data logger tell the micro:bit which pins on its edge connector to read data from before transmitting it over Bluetooth. Each 9030 event has a value which combines a pin number with a value. This is how up to three different types/sources of data from an external device, connected to the micro:bit, can be communicated to bitty data logger.
Data Format Bits 0, 1 and 2 are used to select pins 0, 1 and 2 for sampling.

For example:

00000010 means pin 1 should be read.

00000111 means pins 0, 1 and 2 should all be sampled.

Bits 0-9 contain value. Bits 15-14 contain a pin no. So a single event value, indicates both the pin that the data comes from and the data sampled from that pin.

In MakeCode, to be notified whenever the 9020 Pin Selection event is sent over Bluetooth from Bitty Data Logger, and to set some flags indicating which of pins 0, 1 and 2 have been selected in the app, this is all we need to do:

MakeCode application code

MakeCode application code.

To formulate a 9030 data event and send it to the smartphone application over Bluetooth, I usually place the code in a MakeCode function block which I can call from elsewhere, like this:

MakeCode function block

MakeCode function block.

It’s that easy!

Changing the Let’s Talk Science code to work with Bitty Data Logger

To adapt Jennifer’s code to work with Bitty Data Logger, I decided to cheat a little. I decided to pretend that C02 readings were associated with pin 0, temperature readings with pin 1 and humidity readings with pin 2. Of course, all of these readings are being returned over the micro:bit’s pin 1 which is receiving serial data from the sensor’s TX pin, but let’s not quibble. Pretending that the three sensor data types come from different pins, allows us to transmit and classify the three types of data seperately so that Bitty Data Logger can capture and chart the data in the usual way.

Reading data from the sensor is performed in a Forever block and only happens if we’ve accepted a Bluetooth connection, indicated by a variable which gets set when a connection is established or lost, in these event handlers from the MakeCode Bluetooth package:

Accept a Bluetooth connection

Accept a Bluetooth connection.

We then request one or more of the three sensor data types, depending on the pins that were set in the Pin Selection event.

Request co2 sensor data types.

Request sensor data types.


The GSS Carbon Dioxide sensor is great for all sorts of science projects and has great relevance to a range of real world issues. As always, Bitty Data Logger allows phenomena to be visualised and analysed, which is a big help in furthering a deeper understanding.

Give it a try! Bitty Data Logger is in the Apple App Store and Google Play.


The GSS Carbon Dioxide sensor is great for all sorts of science projects and has great relevance to a range of real world issues. As always, Bitty Data Logger allows phenomena to be visualised and analysed, which is a big help in furthering a deeper understanding.

Give it a try!

Bitty Data Logger is in the Apple App Store and Google Play:

Full Solution


<div style=”position:relative;height:0;padding-bottom:70%;overflow:hidden;”><iframe style=”position:absolute;top:0;left:0;width:100%;height:100%;” src=”” frameborder=”0″ sandbox=”allow-popups allow-forms allow-scripts allow-same-origin”></iframe></div>



<div style=”position:relative;height:0;padding-bottom:70%;overflow:hidden;”><iframe style=”position:absolute;top:0;left:0;width:100%;height:100%;” src=”” frameborder=”0″ sandbox=”allow-popups allow-forms allow-scripts allow-same-origin”></iframe></div>

Contact the author

Martin Woolley | Developer Relations Manager, EMEA at Bluetooth SIG



How a CO2 sensor can help to improve personal safety

The stuffy feeling that you get in a crowded room is not lack of oxygen but your body reacting to high levels of CO2. The normal level of CO2 is around 400 parts per million (ppm) but as people breath out, CO2 levels can rapidly rise to 2,000 ppm. You breath out a hundred times more CO2 than you breath in and even more if you are exerting yourself. As the concentration of CO2 rises so does the stuffy, drowsy feeling and it becomes harder to concentrate; at even higher levels, it has a narcotic effect and then causes unconsciousness.

There are many workplaces where levels of CO2 can be high enough to cause health issues but it is often overlooked as it can’t be seen or smelt. For example, CO2 is used in the food industry to keep food fresher for longer. CO2 puts the fizz in drinks and the CO2 cylinders are often stored in pub and restaurant basements where a CO2 leak can build up as it is heavier than air. This raises the possibility of pockets of higher concentration CO2 and so the best solution is to monitor the exposure of the individual personnel themselves rather than the general atmosphere in a room.

What needed is a small portable CO2 monitor/alarm that can be worn for long periods of time. However, almost all CO2 sensors need a lot of power and time to achieve stability so they have to be mains powered and therefore are not suitable for a wearable solution. The power is needed to heat up a source of infrared (IR) that is passed through the sample gas. CO2 molecules have a distinctive absorption in the 4.2 to 4.4 micron range so the more that is absorbed, the greater the concentration of CO2. This measuring technique is called Non-Dispersive Infra Red (NDIR).

There is one exception to this. Gas Sensing Solutions (GSS) is unique in that the company uses proprietary LEDs that it makes itself as the IR source. Being LEDs means that they use very little power when on and are almost instantly on and off further cutting down power consumption. As a result, its CO2 sensors can be powered by a battery for up to ten years. A further benefit of LEDs is that they are solid state and very rugged, enabling them to be used in challenging environments.

An example of this technology is use in wearable, battery-powered CO2 monitors is on the International Space Station. CO2 build up has to be carefully monitored as NASA has already established that high levels of CO2 can compromise the astronauts’ ability to work. Also, the poor circulation of the air due to lack of gravity can easily result in pockets of high CO2 concentration. The solution would be to provide each astronaut with a wearable CO2 monitor. Supported by GSS distributor, SST Sensing, NASA designed and made personal CO2 monitors using GSS sensors, which were used on the ISS to gather data.

Photograph provided of inside the International Space Station (ISS), courtesy of NASA.

NASA has found that crewmembers develop CO2 related symptoms at lower CO2 levels than would be expected terrestrially. Since 2010, operational limits have been controlled to an average of 4.0 mmHg or below as driven by crew symptomatology. However, crewmembers have reported symptoms starting as low as 2.3 mmHg that are due to CO2. Between 2.3-2.7 mmHg, fatigue and full headedness were reported. Between 2.7 and 3.0 mmHg, errors occurred in procedures. And above 3.0-3.4 mmHg, headaches were reported. It was also noted that crewmembers varied in their sensitivity to CO2 levels. This evidence indicated to NASA that an operational level of between 0.5 and 2.0 mmHg may maintain health and performance, which they want to research further:

Many industries require their workers to enter enclosed spaces such as bulk food stores, mines, submarines and tunnels, where environmental monitoring is critical to safety and so the use of a personal CO2 monitor with an alarm could save lives.

Collaboration on a smart building energy management system

Property on the cusp of a tech revolution 

by Mark Begbie / November 30, 2017/ FutureScot

Have you ever returned to work from lunch to find lethargic colleagues sipping coffee, or even dozing at their desk? If you work in an office, you most likely have. It’s the well-known afternoon slump – often thought to be the result of over-indulgent meals or the consequence of a morning’s hard work.

That, however, is a misconception – one that has a real impact on productivity for countless businesses and, collectively, the entire economy. It’s one of the many enduring problems faced in offices across the world that are being tackled by technology coming out of Scotland.

A new generation of property technology companies, or proptech as they’re coming to be known, are emerging across the country. One by one, their technologies will change commercial property for the better, whether it’s how much office space a business leases, how a clinic manages its rooms, or enabling automated control of buildings.

One of them is Cumbernauld-based Gas Sensing Solutions (GSS), which is taking on the post-lunch snooze. Part of the reason it’s such a problem is that modern building regulations have focused on energy efficiency, which has the effect of reducing the proportion of fresh air getting in. This can lead to a build-up of carbon dioxide in buildings through the day – making occupants increasingly tired.

To tackle the issue, GSS worked with Glasgow Caledonian University and CENSIS to develop a smart building energy management system which continuously monitors air quality, predicts a looming rise in CO2, and takes action to improve it. The system can even estimate how many people – if any – are in a room and adapt its behaviour to make the occupants more comfortable whilst maintaining energy efficiency, by adjusting ventilation and temperature.

Yet, productivity isn’t just an issue for staff – it can be a challenge for buildings or equipment too. In these cases, it’s more often referred to as availability or utilisation – a perennial problem for organisations seeking to achieve the best value and service delivery from their facilities.  With 500-million sq. ft. estate and its almost countless moveable assets, the National Health Service is no stranger to this.

Analysis suggests that many facilities, including those in the NHS, could deliver significantly more if there was a better way to monitor and manage their use. Scottish start-up Beringar is taking this problem head on, by developing a non-intrusive sensor, and associated analytics, to understand facility and asset utilisation. The company is already working with the NHS to improve its understanding of how its buildings and equipment, such as hospital beds and crash trolleys, are used.

Transmitting data wirelessly using a “LoRaWAN” long range, low power, wide-area network – a type of Internet of Things (IoT) network – the sensor replaces traditional methods of measuring and assessing the use of buildings, such as clipboard surveys. It accurately counts the number of people in a room, recording occupancy levels, and identifies trends in the way areas are used, without sending an image of the people.

While the NHS could be the biggest beneficiary of this technology, it could also be used in a range of other scenarios, including higher education, leased offices and by construction firms. In fact, several of Scotland’s universities are already seeing the benefits of the IoT.

In Inverness, for example, a consortium of organisations – including CENSIS, Stream Technologies, and SPICA Technologies – installed LoRaWAN connected indoor environmental-monitors at the £13m An Lòchran building on Inverness Campus. The building is jointly owned by Highlands and Islands Enterprise, the University of the Highlands and Islands, and Scotland’s Rural College.

Monitoring a range of data – temperature, humidity, CO2 levels, noise, and light – the network has helped its owners and occupants make better decisions about how they manage the building, through data visualisation and analytics. For example, they could tell which rooms were occupied, which weren’t, and adjust conditions remotely to make them more comfortable.

Combined, these three company collaborations demonstrate the colossal changes that could be on the way for property owners and occupiers. The ability to monitor the occupancy levels of rooms across an entire estate could be transformative for a university or other large organisation, while keeping CO2 levels in check could lift worker productivity.

These are just some of the ways in which technology will change commercial property as we know it. Between them, they could allow organisations to make smarter decisions with their space, boost productivity, and cut unnecessary costs for occupiers and landlords. There are serious benefits for everyone to realise if they implement it the right way.

Property is on the cusp of a tech revolution; it’s now up to the industry to embrace it.

Mark Begbie, business development director at CENSIS.