Globally, buildings represent 40% of total energy usage [1], with air heating and water heating contributing to over 50% of the total energy usage in residential buildings [4].
In our home city of Winnipeg, Canada, the climate is much colder than average, which further increases the demand for heating in buildings. It has been shown that in colder climates, energy use increases considerably in residential buildings, accounting for up to 60% of the total usage in a country such as Norway [1]. In Winnipeg, the vast majority of energy use in buildings (i.e. 99%) is through natural gas, and this natural gas use from buildings contributes to over 30% of the city’s annual carbon emissions [2][3].
Hence, our goal for this build is to devise a line-powered product that can help to make energy use in smart buildings more efficient.
The next sections in this report discuss the product concepts, system design, and the features we managed to achieve with our prototype build.
ConceptTo achieve more efficient energy use in buildings, we wanted to create a product that allows system designers to monitor air quality parameters in a building. We identified that systems that need to do this are limited by how many sensors you could put on the product itself.
For this reason, the novel concept we have introduced with this project is in its configurability. The Polymath IoT Sensor system consists of a controller module and a sensor cluster module. The controller module can be connected to one of various sensor modules, allowing a wide range of parameters to be monitored such as temperature sensors, gas sensors (e.g. CO2, methane), pressure sensors, and water quality sensors.
For this competition, our focus was on developing a controller + sensor module capable of detecting key characteristics, specifically:
- Indoor room temperature
- Indoor room occupancy
- Indoor air quality
We identified these as useful characteristics in a smart building as it would allow systems to efficiently determine which rooms demand more or less heating and ventilation. For example, if the occupancy in a room is empty, or if the air in a room is already fresh, then a system can close vents and windows to avoid using any further resources for that room.
The main novelty of this solution is in its configurability - for this contest we’ve focused on a specific use case. However, by using multiple Polymath systems in a building with different attached sensor modules, multiple instances of this module can be used to streamline system design and implementation.
In addition, the existing products for smart buildings consist of a single domain-specific sensor, and the data needs to be pushed up to a central system for processing [6]. The potential use of SensiML in our product improves data efficiency over the network because the classification of data can be done on the board itself, hence less raw data needs to be processed off the board.
Results Pt. 1 -- SummaryThe results we have achieved and will be presenting are as follows:
1. Completed system architecture designs.
2. A prototype build of the product demonstrated on breadboards. This prototype build is capable of:
- Collecting data from the attached sensor cluster.
- Publishing collected data to BLE Characteristics.
- Entering a training mode to collect sensor data over BLE for SensiML.
3. Hardware design for a “production” build of the product. Note that this design has not been demonstrated to function in practice.
Due to challenges in getting parts in time for this PCB, it was not able to be fully populated and tested. However a fully functioning prototype was built to demonstrate the features.
Results Pt. 2 -- System ArchitectureThe Polymath IoT Sensor consists of two modules that are hosted on two separate PCBs.
The controller module is a two-micro system, with a master controller and slave controller that communicate over UART.
The master controller uses the EOS-S3 micro on the Quickfeather board, and is in charge of:
- Interacting with the slave controller over UART to read raw sensor data.
- Interacting with the Bluetooth module to publish processed sensor data and transmit training data. This is done by interacting with an NRF51 over UART, using the Adafruit Bluefruit LE UART Friend module [7].
- In addition, the hard UART on the EOS-S3 is used as a debug/console UART during development.
The master controller takes advantage of the FPGA fabric on the EOS-S3 to instantiate two additional UART IPs to cover the three different UART connections needed for the controller. The master controller software was developed in Eclipse, and uses the FreeRTOS and HAL libraries made available in the QORC SDK to implement the application logic [10].
The slave controller uses the STM32F micro, and acts as a breakout board for interfacing with all of the sensors on the product. Due to availability, the prototype build uses an STM32L47RG Nucleo development board as the slave controller [8]. The software was developed using the STM32CUBE IDE development platform, making it easy to transfer the code over to the STM32F micro in the production hardware.
The slave controller also interfaces directly with the WS2812 LED part, which acts as the Polymath IoT Sensor’s status LED.
The sensor module for this product contains the following sensors.
- BME680: This sensor is used to collect temperature, pressure, and humidity characteristics. The prototype build incorporates the Bosch Sensortec Environmental Cluster (BSEC) library and hence the software is built to also collect CO2, TVOC, and Indoor Air Quality (IAQ) Index information, which is not included in the published Bluetooth data.
- MICS-VZ-89TE: This sensor is used to collect CO2 and VOC (Volatile Organic Compounds) readings. It consists of a varying gas resistance when exposed to a varying concentration of the above-mentioned gases and sends bytes of data over I2C.
The CO2 value is calculated as follows:
The VOC value is calculated as follows:
- B5W-LD0101: This sensor is used to collect dust sensor readings to assist with detecting indoor air quality. Not included in the prototype build.
- HC-SR04: This sensor is used to collect proximity readings in order to support detecting room occupancy. Not included in the prototype build.
Description of why the parameters are collected:
CO2 - The levels of carbon dioxide is an important parameter to collect in the context of a building. High levels of CO2 if often attributed to a leak in the heating system and can have serious health consequences if people are exposed for lengthy periods.
VOC - Due to some buildings still having old inefficient heating system, volatile organic compounds are produced in HVAC system as a result of incomplete combustion of alkanes in the furnace. It is therefore important to monitor any anomalous PPM of VOCs as that gives an insight if there's a malfunction in the heating system or a leak somewhere in the building. Exposure to high levels of VOCs lead to health problems such as breathing problems, irritation of eyes, etc.
An image of the architecture is shown below:
An image of the functioning prototype build can be seen below.
Refer to the schematics section for a detailed description of the connections.
Refer to the Build Instruction sections for a more detailed description of all of the hardware and software.
Bluetooth Data
While the software is running, data from the sensors can be observed over Bluetooth with the Adafruit Bluefruit Connect Android App [11]. The mapping from service and characteristic UUIDs to actual data are as follows.
The Service UUID representing the Polymath Air Cluster is: 03-FA-FF-00-05-D5-4F-8D-B6-C7-17-9E-FC-E9-49-4D
The UUIDs corresponding to each parameter on the cluster are:
The published characteristic data can be viewed on the Bluefruit Connect Android App.
Video Demonstration
A video demonstration of the Bluetooth functionality can be seen below.
This is a demonstration of the Polymath IoT prototype board. Here is what is on the video:
1. At the beginning the product is in normal operating mode (solid green LED).
2. We open the Bluefruit Bluetooth Android app, connect to the product, and then wait for a few seconds for the volatile organic compound (VOC) data to settle (due to our previous attempt). The VOC is the fifth Bluetooth characteristic in the service (UUID: 03-FA-00-05-05-D5-4F-8D-B6-C7-17-9E-FC-E9-49-4D).
2. We spray alcohol onto a tissue and then blow it onto the MICS-VZ-89TE sensor, which will detect this as VOC.
3. We refresh the Bluetooth data on the app and can see the VOC data becomes non-zero, indicating the VOC was detected.
Training Data
While it is running, training data can be collected over Bluetooth with a Python script in the polymath-iot repository like so.
In the Polymath console (115200 bps on the hard UART of the Quickfeather), issue a command to initiate training:
Run the Python script like so:
Once the training session is completed the shortcut “Ctrl-C'' can be used to disconnect from the device. The training data is stored in a single CSV file in the same working directory as the script, suitable for import into SensiML Data Capture Lab.
The Polymath controller module was designed as a 4 layer board with 2 connectors exposing the interfaces to connect sensor modules to it. This makes the design modular. The high level block diagram below highlights the main components of the PCB.
All the files required to manufacture this PCB can be found here : https://github.com/rahmant3/polymath-iot/tree/develop/hardware
DESIGN DETAILS
The design consists of 2 sources of inputs which is either from USB MINI type connector or a barrel type connector. This gives the user the possibility to plug in power banks to the circuit via the USB connector or power it via the AC grid using a 12V power adapter. The user has the option to plug in both the adapter and the power bank.
In order to handle the backflow of current from one power source to another, the following power steering circuit was used.
The regulators chosen were LDOs as the current drawn is limited to only 300 mA peak. There are 2 LDOs used which provide a 5 V rail and a 3.3V rail. These LDOs have a low drop out and a high PSSR which ensures that there's minimal noise on the circuit.
A debug UART interface to the ST Micro was exposed using a 6 pin header and this header could be connected to a terminal on a PC using an FTDI cable for debugging and testing.
The STM32F401RE was chosen as the Microcontroller to used in this case as it has all the peripherals needed for this project and a development board was readily available.
The SWD and JTAG interface was made available via a TC-2050 tag-connect footprint and this is what is used to flash the application code onto the controller.
The communication peripherals available on the ST were exposed using two 20 pin connectors. The exposed signals are as follows:
The QUICKLOGIC board features such as UART, I2C ,SYS RESET and Programming interface were used in this design.
A 4 layer PCB design was made to implement all the interfaces.
As mentioned in this report , due to challenges in getting parts in time for this PCB, it was not able to be fully populated and tested. However a fully functioning prototype was built to demonstrate the features.
Prototype Build Instruction Pt. 1 -- Hardware RequiredCollect the following materials as per the hardware components list:
- QuickFeather development board
- STM32L47RG Nucleo board
- BME680 breakout board
- MICS-VZ-89TE breakout board
- WS2812B LED
- BlueFruit LE UART Friend breakout board
Solder headers onto the BME680 breakout board, the MICS-VZ-89TE breakout board, the WS2812B LED, and the BlueFruit LE UART Friend breakout board so that they can be placed on breadboards.
Prototype Build Instruction Pt. 2 -- Software RequiredComputer setup is described below.
Download the Github repository for the full source code used in this project. This will be needed in order to rebuild the required binaries.
https://github.com/rahmant3/polymath-iot
To build Quickfeather software (master controller):
1. WSL (Windows Subsystem for Linux) must be installed. Note that Linux is only used for building the project with Make -- otherwise we will just use regular Windows 10 (e.g. Python, pip, etc).
2. The GCC-ARM toolchain must be installed to WSL like below.
- Download "gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2" tarball from: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
- Extract the tarball to /usr/share.
sudo tar xvjf gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux.tar.bz2 -C /usr/share/
3. (Optional) To build the FPGA logic, the Quicklogic FPGA toolchain must be installed to WSL like below.
- Download "Symbiflow_v1.3.1.gz.run" to the source directory from: https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain/releases/tag/v1.3.1
- From the source directory, issue the following commands.
export INSTALL_DIR="$PWD/source/qorc-sdk/quicklogic-fpga-toolchain/install" bash Symbiflow_v1.3.1.gz.run
4. Python 3.6 or higher is needed to reprogram the application (install a Windows version).
- TinyFPGA must be installed to the system. See the instructions here: https://github.com/QuickLogic-Corp/TinyFPGA-Programmer-Application
To build STM32 software (slave controller):
1. STM32CubeIDE (V1.6.1 used) must be installed: https://www.st.com/en/development-tools/stm32cubeide.html
2. Users must download the BSEC library files from Bosch: https://www.bosch-sensortec.com/software-tools/software/bsec/
The following files must be placed into the “stm32\PolymathSlave_STM32L476\App\bme680” folder.
- bsec_datatypes.h
- bsec_interface.h
- bsec_integration.h
- bsec_integration.c
- libalgobsec.a (from normal_version\bin\gcc\Cortex_M4)
Place the "Required Hardware" parts (aside from the Nucleo board) onto breadboards, and wire the parts together as per the below schematic image.
It is assumed the Nucleo board is powered via USB (i.e. from a laptop), and that 3.3 V and Ground from the Quickfeather are used as the power/ground sources for the parts. Make sure to connect ground from the Quickfeather and Nucleo board together so that they share a common ground.
In order to build the master controller software, issue the following from a Windows command line from the “quickfeather” folder.
wsl bash build_app.sh
You should observe the build begin to run, and at the end of the build an “app.bin” file should be built in the “polymath-iot\quickfeather\source\app\GCC_Project\output” folder.
In order to flash the software to the Quickfeather board, take the following steps:
1. Connect a micro USB from the Quickfeather board to the computer.
2. Press the “Reset” button on the Quickfeather board. The blue LED on the board should start blinking.
3. While the blinking is in process, press the “User” button on the Quickfeather board. This should cause the green LED to begin blinking.
4. Issue the following from a Windows command line from the root “polymath-iot” folder:
program_qf_app.bat
5. The console output should indicate whether the download occurred.
6. At this point if you reset the Quickfeather board, you should observe that when the application starts running, the green LED blinks at 1 Hz (50% duty cycle).
In order to build and upload the slave controller software to the Nucleo board, take the following steps:
1. Open STM32CubeIDE, selecting this stm32 folder as the root workspace.
2. Go to File -> Import.
3. On the Import window, select General -> Existing Projects into Workspace.
4. Add "PolymathSlave_STM32L476" to your workspace.
5. To build the project, go to Project -> Build All.
6. To upload the project, with the Nucleo Board connected to the computer, go to Run -> Run.
7. At this point if you reset the Nucleo board, you should observe that when the application starts running, the small green LED on LD2 blinks at 1 Hz (50% duty cycle).
Prototype Build Instruction Pt. 5 -- Prototype FunctionalityNormal Operation
With all of the hardware now connected and the software set up, you can exercise some of the features on the prototype product.
1. Connect a USB cable from the Nucleo board to the computer in order to provide power to the system.
2. Connect the USB to TTL adapter to the computer in order to gain access to the master controller's console commands.
3. Open a serial terminal (e.g. Putty) connected to the USB to TTL adapter, at 115200 bps.
4. Press the reset button on both the Nucleo board and the Quickfeather board.
5. On the serial terminal you should see the Quickfeather board startup, eventually stopping at a command terminal like below:
You should observe the diagnostic LED (the WS2812 part) blinking at 1 Hz (50% duty cycle) with an amber colour. This indicates the slave controller has not yet paired to the master controller.
Publishing Sensor Data Over Bluetooth
Follow the steps above in “Normal Operation” to confirm the system has started up as expected.
1. On the serial terminal, issue “ble” and then “register” to begin normal operating mode.
2. You should observe the diagnostic LED turn on at a solid green colour. This indicates the product has entered normal operating mode.
3. If the system has not started properly, at this point you will see the diagnostic LED blinking red.
4. In the console, you should see an output like this, indicating that data is being published to the target Bluetooth characteristics.
5. To test this, open the Bluefruit Android application, and look for the “PolymathSystem”. Press “Connect”.
6. Press “Info”.
7. Scroll down to the Air Cluster service (UUID: 03-FA-FF-00-05-D5-4F-8D-B6-C7-17-9E-FC-E9-49-4D). Tap the characteristics to view the hex data. It should represent plausible data.
For example, the second UUID (03-FA-00-02-05-D5-4F-8D-B6-C7-17-9E-FC-E9-49-4D) represents the detected temperature of the product, which should represent a plausible value.
Training Mode
The product has a training mode that allows a developer to collect data from the Polymath system over BLE. The output CSV file is suitable for use in the SensiML Data Capture Lab (DCL).
1. Follow the steps above in “Normal Operation” to confirm the system has started up as expected.
2. On the serial terminal, issue “ble” and then “training” to switch into training mode.
3. Open a command terminal, and issue the following Python command to run the training script (from the repository’s utils folder).
python polymath_data_capture.py
After some time required to connect to the system, you should observe data collection begin.
4. Once the training session is completed the shortcut “Ctrl-C'' can be used to disconnect from the device. The training data is stored in a single CSV file in the same working directory as the script, suitable for import into SensiML Data Capture Lab.
Importing Collected Data into DCL
The below steps explain how to import the training data into the SensiML Data Capture Lab.
1. You must make sure you create a free SensiML account here.
https://sensiml.com/plans/community-edition/
2. Download and install SensiML Data Capture Lab for Windows 10 (Community Edition) from here.
3. Install the Data Capture Lab, and then open it and login.
4. Click "New project..." and choose a name for the project.
5. Go to Edit > Import Device Plugin. Import the "dcl_import.ssf" file provided in the polymath-iot repository under the "quickfeather" folder.
6. Select "Simple Streaming Interface" in the dropdown.
7. Go to Import Files > CSV Files..., choosing the generated training files.
8. Click "Next" for the Sensor Columns.
9. Click "Done" for Rename Sensor Columns.
10. Click "Import" for Import Settings.
11. Press "+" for Sensor Configuration. We will have to set up the sensor parameters.
12. Choose "Polymath SimpleStream" as this is the device plugin we want to configure, and then click "Next".
13. Make sure the "Capture Source" is "Polymath-Air-Cluster", and then click "Next".
14. The sensor parameters are configured. Give the profile a name and then click "Next".
15. Click "Done" for Sensor Configuration.
16. Finally, on the left click the "Project Explorer" button, and choose one of the imported data files in the Project Explorer.
17. Now we can inspect and label the imported data in the Data Capture Lab.
We faced a few challenges while developing this project.
We had some practical challenges with getting our production hardware built and shipped. Due to part shortages, the initial parts we had picked for our first iteration of the design were not available, in particular, the micro for the slave controller and the part used for the Bluetooth communication were not available. The time and resource constraints due to this issue prevented us from demonstrating the Polymath software on the production hardware.
One parameter we attempted to detect was room occupancy. Our theory was that this could be detected with the proximity sensor on the cluster, as well as the CO2 sensor on the cluster. When testing with the CO2 sensors, on both the BME680 and the MICS-VZ-89TE we observed that the sensors required a calibration period (period of multiple hours) to start up and properly detect CO2 readings. In addition, the response time of the sensors was quite slow even after this period, and hence the CO2 readings were not very useful in detecting room occupancy. It is possible that this could be remedied by choosing a different sensor.
Future ConsiderationsThe production hardware can be improved in the following ways:
- Use Microcontroller and Bluetooth module from the prototype in the production hardware design.
- Use Hirose 40 Pin connectors to improve the size and fittings between the controller module and the sensor module.
- Improve the UART communication reliability between the slave controller and the master controller by incorporating the RTS and CTS pins.
The software can be improved in the following ways:
- Incorporate an ML model to detect air quality and room occupancy.
- Increase the flexibility of the software to support different sensor modules.
- Improve the UART communication reliability between the slave controller and the master controller by using the DMA peripheral on the ST Microcontroller.
[1] Nord, N. (2017). Building Energy Efficiency in Cold Climates. In Encyclopedia of Sustainable Technologies (pp. 149–157). Elsevier. https://doi.org/10.1016/b978-0-12-409548-9.10190-3
[2] City of Winnipeg. (2020, December 1). Climate Change. Climate Change - Sustainability - City of Winnipeg. https://winnipeg.ca/sustainability/ClimateChange.stm.
[3] Lawrynuik, S. (2020, July 25). Crisis? What Crisis? Winnipeg Free Press. https://www.winnipegfreepress.com/local/missing-the-target-571891542.html.
[4] Rolnick, D., & et al. (2019). (tech.). Tackling Climate Change with Machine Learning. Retrieved from https://www.climatechange.ai/paper
[5] Kazmi, H., Mehmood, F., Lodeweyckx, S., & Driesen, J. (2018). Gigawatt-hour scale savings on a budget of zero: Deep reinforcement learning based optimal control of hot water systems. Energy, 144, 159–168. https://doi.org/10.1016/j.energy.2017.12.019
[6] Metallidou, C. K., Psannis, K. E., & Egyptiadou, E. A. (2020). Energy Efficiency in Smart Buildings: IoT Approaches. IEEE Access, 8, 63679–63699. https://doi.org/10.1109/access.2020.2984461
[7] Townsend, K. (2015, May 1). Introducing the Adafruit Bluefruit LE UART Friend. Adafruit Learning System. https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-uart-friend.
[8] STMicroelectronics. (n.d.). NUCLEO-L476RG. https://www.st.com/en/evaluation-tools/nucleo-l476rg.html.
[9] QuickFeather Development Kit. QuickLogic Corporation. (n.d.). https://www.quicklogic.com/products/eos-s3/quickfeather-development-kit/.
[10] QORC-SDK. https://github.com/QuickLogic-Corp/qorc-sdk.
[11] Bluetooth Connect Android App. https://play.google.com/store/apps/details?id=com.adafruit.bluefruit.le.connect&hl=en_CA&gl=US
[12] STMicroelectronics. (2020, August 19). UM1724 User manual - ST. https://www.st.com/resource/en/user_manual/dm00105823-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf.
[13] https://www.canada.ca/en/health-canada/programs/consultation-residential-indoor-air-quality-guidelines-carbon-dioxide/document.html#a7.1
Comments