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 http://drowsydriving.org/about/facts-and-stats/ and https://www.sleepfoundation.org/sleep-topics/drowsy-driving

A paper on ‘Modelling CO2 concentrations in vehicle cabins’, which focusses on the build-up of CO2, can be found at: https://www.engr.ucr.edu/~heejung/publications/2013-CO2-model.pdf

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: https://www.americanasafety.com/associates/docs/publications/The%20Drowsy%20Driving%20Off%20Switch.pdf

CozIR®-A CO2 sensor used to evaluate LoRaWAN and sensor applications

A customer of Gas Sensing Solutions (GSS Ltd) based in Budapest, Hungary has built a sensor panel device using the CozIR®-A CO2 sensor.

ChipCAD has incorporated the CozIR®-A in their Micromite GPS LoRa MOTE design.  The sensor measures up to 1% CO2 concentrations, and is designed for ambient air applications.

The Micromite device is targeted at design engineers to quickly evaluate LoRaWAN and its sensor applications.

The ChipCAD article is available here:

http://micromite.chipcad.org/home/micromite-mote-szenzorpanel 

The full application spec can be read here:

Micromite-LoRa-Mote_GPS-Sensor-Multicast_Specification-4v00

Connections

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

Written by Martin Woolley | http://www.bittysoftware.com

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
GND GND
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:

Connections

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 {

serial.writeString(“Z\r\n”)

basic.pause(200)

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))

//basic.showString(response)

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.

Conclusion

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.

http://www.bittysoftware.com/apps/bitty_data_logger.html

Conclusion

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:

http://www.bittysoftware.com/apps/bitty_data_logger.html

Full Solution

https://makecode.microbit.org/_5hEKs3FgR7he

Editor

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

Link

https://makecode.microbit.org/_5hEKs3FgR7he

Editor

<div style=”position:relative;height:0;padding-bottom:70%;overflow:hidden;”><iframe style=”position:absolute;top:0;left:0;width:100%;height:100%;” src=”https://makecode.microbit.org/#pub:_5hEKs3FgR7he” 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

http://www.bittysoftware.com

https://bittysoftware.blogspot.com/

@bittysoftware 

 

Innovative sensor technology assists NASA with vital wearable CO2 monitoring equipment

Within a self-contained system where humans are respiring, there will be a build up toxic CO2 levels over time…

As a consequence, in any form of spacecraft where humans are present, effective mechanisms for removing CO2 and resupplying oxygen need to be implemented. However, operational necessities still dictate that these will only be efficient enough to keep the CO2 levels down to a certain extent.

As air moves differently in such locations, without the influence of gravity involved. Heat does not rise and this in turn leads to significantly less mixing of air taking place. The occupants onboard the International Space Station (ISS) are thus exposed to greater levels of CO2 during their time onboard than the rest of us experience. Down here on Earth it represents just 0.03% of the air’s content (equating to a partial pressure of 0.23 mmHg). NASA has set a long-duration spacecraft maximum allowable CO2 concentration that is more than double that figure, at 0.7% (a partial pressure of 5.3mmHg).

Though extensive terrestrial studies have shown that this increased level will have no effect on the continued good health of those exposed to it, there must be some acknowledgement of the fact that crew members onboard the ISS still regularly experience symptoms of acute CO2 toxicity – such as headaches or lethargy.

It is generally accepted that human adaptations to microgravity conditions will cause astronauts in space to become more sensitive to elevated CO2 levels. This can result not only in physical discomfort, but also impinge on their cognitive skills and reaction times – thereby potentially leading to safety risks. On average crew members stay on the ISS for a period of around 6 months, so having a good grasp of the ongoing implications is clearly of great value.

With operational practicalities meaning that it is not possible (either technically or financially speaking) to remove enough CO2 to replicate normal conditions here on Earth, the ISS has to function with relatively high ambient CO2 concentrations present in the air. Yet its occupants have to live and work in an acceptable environment.

NASA scientists have, for many years, wanted to embark on a thorough investigation of how elevated CO2 levels impact on ISS crew members’ ability to carry out their allotted tasks, but it has taken a long time for them to be in a position to employ a method for acquiring data to a high enough degree of precision. Given that, as already mentioned, air does not mix well without the influence of gravity, wall-mounted sensors had proved themselves to be an unsuitable means by which to get an accurate reflection of a crew member’s exposure to CO2. What was needed instead were wearable CO2 sensors.

There were several key criteria that a wearable CO2 sensor would have to meet. These were as follows:

  1. It would need to support a prolonged battery life – so that operation could be sustained for an extensive period without recharging being required.
  2. For wearer comfort and convenience, the sensor would have to be compact and have a low mass.
  3. A simple data interface would also be important, so as to make the information acquired easy to access, while at the same time keeping the system development process as short and uncomplicated as possible.

After a comprehensive survey of what products were on the market, the scientists working in NASA’s Technology Transfer Program decided on the best option. A solution from Scottish sensor manufacturer SST Sensing Ltd developed with its long-established engineering partner Gas Sensing Solutions (GSS) was specified accordingly. The two companies liaised with NASA during the prototyping phase, providing detailed performance information on the industry-leading ExplorIR®-W CO2 sensor so that this device could be used with maximum effectiveness in space agency’s personal CO2 monitors.

Once they had been supplied, the NASA team charged with execution of the project then constructed a custom-designed baseboard around each ExplorIR®-W sensor. This hardware provided all the necessary power regulation, processing, data storage and wireless connectivity. The team also designed a housing that could be 3D printed and easily clipped on to crew member’s clothing (with the sensors being worn on the back of their collars).

Thanks to the highly advanced optoelectronics employed by the ExplorIR®-W gas sensors, these low power, high speed non-dispersive infra-red (NDIR) devices can cover measurements down to ppm CO2 levels (with a range of 0 to 5000ppm and a ±5% sensor accuracy). They comfortably support an operational lifespan of 10 years. Pivotal to their suitability for this application was their power saving capabilities – with devices just drawing 3.5mW at 2 samples/sec acquisition rates. This means that they are 50 times less power hungry than standard NDIR sensor options currently on the market. Another advantage was the ease of connectivity – with a convenient serial connection facilitating data transfer.

Through these personal CO2 monitors, it will be possible for simple and unobtrusive tracking of the astronauts’ individual CO2 exposure to be undertaken over an extended period of time. Astronauts will be able to view their own data straight away via a custom iPad app. Furthermore, all the datasets obtained from crew members will subsequently be compiled together and utilized by researchers to get a better understanding of the long-term effect of heightened CO2 exposure during space travel. Not only could this prove highly beneficial to the ISS crew, but also for potential future missions to Mars.

The personal CO2 monitors that were developed for this project were transported to the ISS back in the spring, with the crew completing proof-of-concept demonstrations soon after. The process of gathering data is now underway, with initial analysis due to take place towards the end of the year.

For more information about GSS CO2 sensors, including technical specifications, measurement ranges and response times, please click here.

Media contact:

Nigel Robson, Vortex PR.  nigel@vortexpr.com  +44 1481 233080

 

Evaluating made easy!

Professional CO2 sensor Evaluation Kit now available.  Everything you need to start making real time CO2 measurements.

Kit contains:

  • CO2 sensor…you select one from our range
  • USB connecting cable
  • USB stick containing evaluation software and documentation

Click here for more information, or to place an order, contact our sales team on
+44 (0) 1236 781 900 or info@gassensing.co.uk