Get Started with Altium Upverter, Sign Up Now.

A while ago, I reached out to a YouTube channel which I support on Patreon to ask if the user required any custom electronics for his projects. He recently got back to me and we have a new project! We’re going to build an environmental monitoring and control system. He is building an experimental Mars base in the middle of the desert, and needs a custom system to monitor and control carbon dioxide (CO2) levels inside, primarily in the area he will be using for growing crops. The plants will consume CO2 as they grow, and animals (such as humans) living in the habitat will produce CO2 as they breathe. If CO2 levels rise too high, it could become dangerous, so air will need to be pumped through CO2 scrubbers, and if CO2 levels get too low, then CO2 will need to be released from a tank.
These were his only requirements, but I thought it would be fun to also include traditional environmental sensors, such as temperature, humidity and index of air quality. Furthermore, to display readings, it would be nice to use a 5-7” TFT capacitive touch screen to give something big and beautiful to look at.
Our specifications and requirements are fairly broad, which gives a lot of leeway for creativity as we go through the design. As with my other project articles, we will be planning and building this as we go. When mistakes are made we will learn from them together, and we will go through the thought process together when we encounter scope creep or find we need to modify the design.
Requirements and Specifications
Required functionality:
- Read CO2 levels from the atmosphere.
- Maintain CO2 levels utilizing CO2 scrubbers and tanked gas.
- Display current and historical CO2 levels on a display.
Nice to have:
- Temperature monitoring.
- Humidity monitoring.
- Index of Air quality monitoring.
- Networking for multiple sensors in multiple areas of the habitat.
Part Selection
The most critical part of this design is whether or not we can find a CO2 sensor that will meet the requirements. Everything in the design relies on being able to sense CO2 levels accurately and reliably. The other sensors are more because I love collecting data, and it makes sense to build a full environmental monitoring system.
Carbon Dioxide Sensor
As usual, I start out at DigiKey because I’m most experienced with digging through and filtering DigiKey’s data. The other major suppliers all have great filtering mechanisms too, however, as I’m most familiar with DigiKey, I look at them first.
I’m looking for a gas sensor, so naturally we’re looking in the Sensors, Transducers > Gas Sensors category for in-stock parts that have an Active part status. If I need to make more of these devices months or years down the road, I don’t want to pick a part which is already obsolete or not recommended for new designs, and may not be available once current stocks run out. I’m filtering for anything that includes CO2 as a gas type parameter, then sorting by price.
Sensirion – SCD30
The cheapest result I found is the SCD30. Its datasheet looks pretty good, and it’s an I2C based sensor which is fantastic for getting accurate measurements from. This is definitely a good candidate; I’ve used Sensirion sensors in the past, and they left quite a positive impression on me. They have been easy to interface with and performed to the advertised specifications.
The dev kit for the SCD30 is quite expensive. While not necessary, a dev kit can provide a nice working implementation that is good for attaching a logic analyzer to if there are difficulties getting your own code to work with the sensor.
Amphenol – T6713
With a bit of a jump in price, the T6713 is a nice shiny gold sensor that’s a bit smaller than the SCD30, and works over a wider temperature range. It has higher precision, and has a self calibration routine built in to ensure optimal accuracy as long as the ambient carbon dioxide levels drop to around 400ppm a few times a week. Amphenol also have other types of sensors that do not need self-calibration, but are not as accurate.
My main concern for this sensor is it’s advertised high power consumption. I haven’t been told to optimize for power consumption, but if it does become a requirement in the future, it could rule out this sensor, especially if real world current draw is as high as the advertised figures. My experience with gas sensors in the past makes me feel as though turning the sensor on just to make a measurement will not give me as accurate readings as leaving it on all the time, because gas sensors typically like to be on all the time to run calibration routines and to keep the sensor elements activated. I don’t know what the internals of this sensor are, or if the calibration data is stored in non-volatile memory internally, so I can’t be sure my past experience applies to this sensor. When selecting parts, you typically try to reduce engineering risk, and get your new project off the ground as quickly as possible. This can very much make past experience with similar sensors influence the choice of parts in your newer projects.
A secondary concern for this unit is the self calibration, which also makes it accurate. With the sensor being installed in a closed habitat, it could completely skew the calibration data. The sensor is expecting levels to drop to the global average of around 400ppm, and uses the low point of its readings in a given period as a calibration reference. If we are artificially creating a low point by using CO2 scrubbers, or the crops that are growing consume CO2 bringing the levels below 400ppm, it could take the calibration too low. Likewise, if the environment never reaches 400ppm in a week, with elevated CO2 levels continuously present, it could easily skew the calibration to a higher percentage. The CO2 levels being too low is not great for the crops, and likewise, the CO2 level calibration shifting too high could be very dangerous to anyone living in the habitat. With this in mind, the sensor will need to be tested in an elevated CO2 level environment for at least a week to see what happens to the readings.
The dev kit, on DigiKey at least, is cheaper than the sensor itself. This is not the case at any other supplier, so perhaps it’s a temporary glitch. The fact the dev kit is cheaper than the sensor is pretty exciting, STMicroelectronics do this a lot with their ARM dev kits which makes them really affordable to start a project with. I love this model, as it makes trying out a device so much easier than dev kits costing hundreds of dollars, and makes it much more likely for a device to end up being used in my product.
Based on the dev kit prices, I’m going to give the Amphenol T6713 a try in this project. If it doesn’t meet the expectations, I’ll switch to the Sensirion SCD30 as my second choice. As we’re only building a couple of these units, the unit cost for the sensor is far outweighed by software development time. I’m providing this device for free, but my time still has value to me.
Microcontroller
I rarely use a microcontroller outside the ARM Cortex range, so I’m looking for an ARM Cortex M0 or M3 which has a dev kit (ideally one I already own), lots of RAM for graphics, USB and a decent number of pins for running a parallel display.
For this project, I feel as though MikroElectronica’s IDE might be the best option, due to the VisualTFT option for designing user interfaces quickly. So the microcontroller I choose needs to be supported by mikroC PRO for ARM. For dev kits I already own, this means I’m looking at a controller from STMicroelectronics, as I already have most dev boards they produce.
The cost of the microcontroller is pretty negligible in terms the total cost of this project. So as mentioned before, ST’s habit of offering an expensive microcontroller on a cheap dev board is definitely going to encourage me to use an over-the-top option for a microcontroller just for ease of use. If I was planning to build hundreds or thousands of these units instead, I’d be looking to optimize for price.
Since I’m not certain of my processing requirements, I’m going to start with an STM32F413 dev board, and look at switching to another processor if I find I need more or fewer resources as we go through the breadboard stage. The code compiled with mikroC will work on any supported platform, and could also be ported to a PIC or AVR just by switching IDE.
I specifically mentioned fewer resources as there are some interesting options for displays which could heavily influence the amount of resources required.
Display
As with the microcontroller, I need to find a display that has a controller supported by MikroElectronica’s VisualTFT software. The options cover the vast majority of the displays on the market, so it’s not particularly restricting to a choice.
MikroElectronica’s store has a good range of displays at reasonable prices, so to keep things simple for this project, I’m just going to order a display from their range. Again, we’re not optimizing for component cost on this project, we’re optimizing for minimal development time. Using a display that has a good datasheet and is known to integrate well with the development environment will potentially save me a significant amount of time over choosing a display from an online marketplace which would save me 20-30% of the cost of the display, or a 10% reduction in the total project cost.
I mentioned earlier that perhaps we will not need much memory depending on the display option. Well, the FT813 display controller is the reason behind that. It’s a display controller that allows you to build up a user interface, including touch screen capabilities, via SPI. One feature that really attracts me to the FT813 is the integrated ability to draw a bar graph. It might not seem like a huge deal, but when displaying environmental data, being able to offload the render and display of historical data could save a lot of programming time and a lot of memory.
So with that in mind, we will be using the FT813 display option from Riverdi, a European company that builds displays in Europe. They have a nice model with a bezel, and capacitive touch that has caught my eye, the Riverdi Display 5” UXB.
If we end up finding a reason not to use that, then a display based on the SSD1963 with capacitive touch would be the next choice. The TFT Proto 5 Capacitive touch screen display is only a few dollars cheaper and works over a parallel connection. A quick look through the SSD1963 shows that we’ll need to build the image in memory to send to the display the old fashioned way. This would need 9,216,000 bits of memory if we buffered the entire frame at once! Since we won’t find a microcontroller with that much memory on-chip, we would have to either implement external memory, or render line by line. This is where VisualTFT could come into play, allowing us to take care of a lot of the rendering effort with very little engineering effort.
Environmental Sensors
On my nice-to-have list, I have a few environmental properties to monitor, and after looking through sensors, I finally found the recently released Bosch BME680. It’s relatively cheap, and has all of the functionality I want built into one tiny package. Compared to other sensors that implement an Index of Air Quality output, this is but a small fraction of the cost of just an IAQ sensor. I’d be very interested in this device purely for the temperature and humidity sensors, and while I always love playing with a new sensor, having IAQ seals the deal for me. If it doesn’t work out the way I’m hoping for, I have a bin of temperature/humidity modules that can stand in for it. Then, we can skip the IAQ metric if we find during breadboarding that this device is a pain to deal with. Nevertheless, given that it’s from Bosch, that’s pretty unlikely.
Networking
I’m skeptical of the need for wireless networking on this device. It would be great to have a network of sensors throughout the habitat that can monitor the environmental conditions in each ‘room’ and use fans and ducting to shuffle air around. This would allow high CO2 air to be shuffled over to the crops, and low CO2 air from the crops to be moved out to where the high CO2 air is coming from. In reality though, I feel as though this ducting could impact on the available space within the habitat, as well as add a lot of complexity to the installation. The habitat is going to be relatively small, with very small openings between each room that would be negatively impacted by having ducting in the opening. A more practical alternative would be to simply have a couple of fans just slowly moving air around the entire habitat continuously.
Due to these reasons, adding some form of sensor networking is very low on my priority list. There is no internet or cellular connectivity in the desert location where the sensor will be operating, so logging to a nice cloud platform is out of the question. Therefore, I’m going to leave networking in the nice-to-have column, and if a reasonable use case can be made for it, we will investigate modules for it in the future.
It’s very easy to design a technical solution to a problem with very simple means, so before we head down that route, I want to ensure it’s necessary, no matter how fun it is to build networks of sensors!
Top Level BOM
Now that we have finally selected all the components, we will begin to test them in the next article using a breadboard. Our high level BOM of components to test is:
- Amphenol – T6713
- STMicroelectronics STM32F413
- Bosch BME680
- Riverdi Display 5” UXB based on FT813
As we test these components, we will determine whether they are suitable to be used for our environmental monitoring system or not. If the devices we test do not meet our requirements, then we will order alternative components to test instead. Then, once we have finished all the testing, we can proceed to schematic capture and layout.
Next Time
In the next article, we will use breakout boards and the dev kit for each of the high level components to determine whether they are going to meet the requirements of the project. This process should get us a fairly good skeleton firmware prepared as well as confirming the choices for each component. We will know what pins on the microcontroller we are going to use, which will ensure the PCB we design has a very high probability of success on the first iteration of the design process. In the meanwhile, if you want to gain more insight into why I made my decisions in this specific order, you can feel free to check my Guide to Starting a New Project.
You can sign up for free and get access to the best browser-based PCB editor, schematic editor, and component database. Visit Upverter today to learn more.