Here we list the technologies used and justify why we chose to use them.

Research here: https://docs.google.com/document/d/10VE9JVAf2EToZlwPcisKHPzI0QM7LUKEtz-x0vRxqYc/edit?usp=sharing

LoRa Board

Our project uses LoRaWAN technology to communicate with TheThingsNetwork and our API service. To do this, a device that has LoRa capabilities is needed to send and receive data for LoRa-based communication.

The previous CO2 team used a LoRa Radio Node TB:IOTMCU which is a more compact, single-purpose board designed for LoRaWAN. However, at the end of their term, they concluded that using a TTGO LoRa32 board would be better for the project as it is a more feature-rich, versatile board with an ESP32, OLED display, WiFi capabilities, and is easy for debugging and data visualization.

We've been using the LilyGo TTGO LoRa32 T3 V2_1.6.1 923mHz model (TTGO161 for short) as these were the models provided for us based on the research done by the previous team. We've found it easy to connect to TTN using these boards even with limited documentation.

However, the TTGO161 model is quite expensive and not commonly used compared to other TTGO boards. With this in mind, we researched models that were cheaper, just as effective, well documented, compatible with other technologies used, and easy to plug-n-play when substituting the TTGO161. We're still undergoing research at the moment, but most options are at least $25 for one unit.

We'd like to use our current model, but may have to revert back to using the TB:IOTMCU Radio Nodes if they're cheaper, despite the limited functionality.

CO2 Sensor

In-depth research was performed to understand how CO2 works, how to measure it, and different model options for sensors. For more info, read about our CO2 Assessment & Strategies research.

The sensor used by previous teams has been the MHZ19B, an NDIR CO2 sensor. This sensor reads CO2 data and has worked as intended. However, according to our research, while relatively inexpensive, has some drawbacks, including potential inaccuracy at low CO2 levels, sensitivity to other gases, and a need for proper calibration and handling to avoid damage. Additionally, using an unstable power source can cause the sensor to malfunction or break, which is not suitable for how the sensors have been set up (power off when PCs are turned off). We also use its temperature sensor readings to display temperature on the website, which is not ideal as these temp readings are for sensor calibration purposes only and not an accurate measure of room temperature. These sensors have been inconsistent, unstable, and difficult to troubleshoot in our experience, so a new sensor is needed.

We decided on using either an NDIR (Non-Dispersive Infrared) or PAS (Photo-acoustic Spectroscopy) type sensor as these sensors offer the accuracy and price range desirable for our project. After further research, we decided on a model from the SCD4x range. Our ideal sensor the SCD41 sensor as it offered a higher reading range and better accuracy compared to the SCD40 model, but is more expensive.

So, the SCD40 is the model we decided on as it met the requirements for our use case, offers a decent price, more stability and data consistency, and does not require manual calibration/handling.