Building a Hill Fire Detection IoT with LoRa Part 2: Details of the system
We will talk about the details of the IoT system. Hope you have a deeper understanding in the project after reading. If you want to know more about the basic idea of this project OR want to download the project attachments, you can direct to Part 1: Introduction.
There are four major components in this IoT system and they are sensor nodes, gateways, internet servers and the end-users (e.g. Fire Department and the public etc.). A star network topology is adopted in the connection between sensor nodes and gateways. Many sensor nodes are distributed on the hill evenly and are connected to the gateways for pushing data to the internet servers. To overcome the terrain, a long-range communication signal modulation LoRa is adopted for sensor nodes. It provides a wide range of flexibility for the distribution and deployment of sensor nodes. After collecting data, gateways push the data to the Internet by MQTT communication protocol through cellular network (but we use Wi-Fi in this demo). Data is then stored in the internet server, ThingsBoard, and is visualized in an online dashboard. Also, gateways issue alarms to users through Telegram instantly if they determine fire occurs somewhere.
It illustrates how the system reacts when fire is detected. Sensors deployed in the hill collect flame, temperature, humidity and gas data periodically. Each of them sends data to the gateway only when changes or outstanding events occur. The gateway automatically determines whether fire occurs or not and estimates the location of fire from analyzing received sensors’ data. When the gateway suspects somewhere is on fire, alarms are sent to the Fire Department through Telegram and data is visualized in an online dashboard for recording. All data is accessible for users.
Block Diagram and Logic Diagram
A self-designed sensor node powered by STM32F103 processing unit. Flame sensor, temperature sensor, gas sensor, humidity sensor as well as a LoRa shield (I-NUCLEO-LRWAN1) (143-8573) are placed on-board.
The pin mapping of the LoRa shield (I-NUCLEO-LRWAN1) is different from the definition of the original project code I-CUBE-LRWAN by STMicroelectronics. You may download the attachment in Part 1: Introduction to prevent this annoying stuff, or you may try the methods in GitHub proposed by USI® (the manufacturer of this LoRa shield).
The main control is powered by a 32-bit STM32F103RBT6 microcontroller. It is a fast MCU and is low cost, but is power-consuming. It can be replaced by a STM32L series MCU, which mainly offer ultra-low-power 32-bit MCUs to extend the battery life.
Different data transmission methods like ADC, one-wire interface and I2C are adopted in sensors. Flame sensor and MQ2 gas sensor output analogue signals to the ADC channel of STM32F103 MCU. The temperature sensor communicates with MCU by one-wire interface. UART is used to connect STM32F103 MCU and the LoRa shield (I-NUCLEO-LRWAN1) (143-8573) .
The program flow of STM32F103 MCU is shown in the above diagram. There are 2 flows in the program running at the same time: The main loop run by the main core processor (Arm Cortex®-M3 processor), and an Interrupt service by the Direct Memory Access Controller (DMA).
The DMA controller is used to sample and store 4 ADC sensor data. A Timer 2 is set to trigger the DMA controller so that MCU can sample 4 ADC channels in a constant period of time without using the resource of the main core processor. Meanwhile, the main core processor (main loop) just needs to focus on checking the status of DMA controller (i.e. the status of DMA interrupt flag) and storing 4 ADC data from DMA controller once its finished data sampling. In this way, “using a DMA controller can offload a processor and either reduce power consumption, or boost the processor performance, or a combination of both”, according to a document from arm Developer website. Also, the main loop always acquires data from the temperature sensor. All data is sent to the LoRa shield (I-NUCLEO-LRWAN1) (143-8573) from STM32F103 MCU by UART at the end of the main loop.
More information on Direct Memory Access Controllers (DMA) can be found at https://developer.arm.com/ip-products/system-ip/system-controllers/direct-memory-access-controllers
The program flow of the LoRa shield (I-NUCLEO-LRWAN1) (143-8573) is more complicated. Actually, an STM32L0 MCU and an SX1272 LoRa transceiver are separately embedded on this LoRa shield (I-NUCLEO-LRWAN1) (143-8573) , so that this LoRa shield not only can transmit data through LoRa transceiver but also can communicate with other devices in different protocols. There are 3 flows in the program executing in the STM32L0 MCU: the main loop, an I2C Interrupt service and a DMA Interrupt service. I2C Interrupt is used to collect humidity data directly. DMA Interrupt is used to receive data from STM32F103 MCU through UART. At the same time, data is sent to SX1272 transceiver to transmit data through LoRa in the main loop.
In the design of this project, the LoRa Development Kit B-L072Z-LRWAN1 (134-5557) acts as a transceiver to receive data from the LoRa shield, and it forwards the data back to the Raspberry Pi through UART. The Raspberry Pi 3 Model B+ is used as the processing unit of the gateway, where a Wi-Fi transceiver is built-in. Because of the lightweights, lower power consumption and greater hardware interface extension ability, it is more suitable than a notebook as the main core of the gateway and makes the development of our prototype more flexible.
The logic flow chart illustrates how the gateway (Raspberry Pi) reacts. Python libraries, like Teleport and MQTT Python client, are imported to enable Telegram alarm function and real-time data forwarding feature (function uploading sensor data to ThingsBoard). Normally, the gateway just forwards data from sensors to ThingsBoard. A dedicated online dashboard in ThingsBoard is created for data visualization. All users can access the data and dashboard, so any third party can acquire data from the system for their self-developed applications.
In Part1: Introduction, the attached Python program of this project is modified from the example Temperature upload over MQTT using Raspberry Pi and DHT22 sensor.
If gateway suspects fire occurs somewhere after processing the sensor data, an alarm will be issued in Telegram. Alarms generated by the gateway and received by a smartphone in Telegram is shown in below figure.
Last but not least, a short video helps us tell the result of this project. You can see that the gateway can still communicate with the sensor node, although they are separated by 5 floors and far away from the location of the gateway. It's thanks to the LoRa’s long-range capability and its high sensitivity of more than -137 dBm. Also, the data keeps uploading to the online dashboard instantly.
1. Building a Hill Fire Detection IoT with LoRa
2. Connecting XinaBox IoT with Zerynth to Cloud
3. XinaBox Weather Station with ubidots Cloud
CommentsAdd a comment
Hello Sir, thanks for great project. I have two B-L072Z-LRWAN1 kits. I want to send a sensor data to another kit. I have not any gateway for now. I have used ping-pong example but i can't add I2C or ADC setting because project not compatible with CubeMX. Do you have any advice for me? Thank you!
@Selim1 Yes, the project can only run in IDE like uVision, because the project originally comes from ping-pong example. CubeMX is not able to run. If you want to enable I2C or ADC functions by yourself, you can generate those needed functions in CubeMX first and merged the relevant functions and .h files or .c files etc. into the original pingpong example.