Design of wireless wide area Internet of Things application system based on LORA
[Copy link]
This paper adopts LORA point-to-point communication and corresponding software design, and uses the aggregation node + communication module on the cloud to replace the LORA base station to design a wide-area wireless Internet of Things application. It designs terminal nodes, aggregation nodes and server platform software, and realizes an economical and practical solution for wireless wide-area Internet of Things applications with a small number of nodes.
1 Overall Design
A typical IoT application system based on LoRa sends data to a LoRa base station through a LoRa terminal, and then the LoRa base station uploads the data to the cloud through a gateway [3][4]. The application system designed in this paper adopts the point-to-point communication method of LoRa terminals, adds a Wi-Fi communication module to the terminal that serves as the aggregation node, and completes the data upload to the cloud through the Wi-Fi module. This method is more cost-effective and easier to deploy. We then design our own server platform to obtain monitoring data through the API interface of the cloud platform. The system architecture is shown in Figure 1.
2 Hardware System Design
2.1 LORA terminal node hardware design
The terminal node is composed of MCU, sensor unit, power module, LoRa communication module, SWD debugging module, etc. The MCU uses the STM32 F103 series chip, which is widely used and low-cost. The Lo Ra communication unit mainly uses Semtech's SX1278 radio frequency chip to realize the transmission of Lo Ra data. The overall structure is shown in Figure 2.
2.2 LORA aggregation node hardware design
The LORA aggregation node is responsible for collecting sensor data and uploading the data to the cloud. In terms of hardware structure, it has an additional WIFI module (or 4G module) compared to the terminal node. The other structures are the same as the terminal node and will not be repeated here.
3 Software System Design
The software system includes terminal node software and aggregation node software. The aggregation node is connected to the cloud platform ( Gizwits IoT cloud platform [5]) through a communication module, and the system's WEB application end is quickly developed based on the cloud platform.
3.1 Terminal node and aggregation node software design
The terminal node collects sensor data and sends the collected data to the aggregation node in a point-to-point manner. The data message sent by the terminal node to the aggregation node contains the terminal node number, sensor type and other information. After receiving the message sent by the terminal node, the aggregation node checks the node number, sensor type and other information in the message and reports them to the IoT cloud platform through the communication module. The software flow charts of the terminal node and the aggregation node are shown in Figures 3 and 4.
Since all terminal nodes and sink nodes use point-to-point communication, a communication protocol between terminal nodes and sink nodes must be designed so that the sink node can identify the data sent by each terminal node. We designed a simple protocol format. The data format of the protocol is shown in Table 1.
Figure 1: System overall structure diagram
Figure 2: Terminal node hardware structure diagram
In order to improve the reliability of data communication, we only use the addresses shown in Table 2 for the 2-byte address encoding.
That is, except for the aggregation node, the address coding of each terminal node can only be 2n, which can accommodate 16 terminal nodes. Redundancy makes it easier for nodes to check whether the address coding transmission is wrong. This is costly, and the address coding method can be modified according to the actual communication conditions of the actual deployment environment to improve the efficiency of communication. The coding of sensor types can refer to the address coding method, so that 8 different types of sensors can be deployed. If more than 8 sensor types need to be deployed, the sensor type coding method can be changed according to the actual communication conditions or the length of the sensor type field can be increased. For the data check code, we use the arithmetic sum of the data + data field length. In the deployment test of the system, the simple communication protocol we designed can support the stable operation of the system.
3.2 Server Platform Design
We connected the device to the Gizwits A iot development platform . Based on Gizwits's Open API interface, we designed the system's server platform. Our server platform is designed based on Springboot[6]. The platform modules include: user management module, device management module, and data presentation module. The functions of the platform can be further expanded.
(1) The user management module implements functions such as user registration, login, modification, and deletion on this server. It uses the Shiro framework for permission management and completes functions such as creation and login of Gizwits users by calling Gizwits’ user management API.
(2) The device management module implements functions such as device binding and unbinding by calling the Gizwits Cloud binding management API.
(3) The data presentation module sets a scheduled task, which will periodically obtain information such as device status and sensor data from Gizwits Cloud and save it to the local database, and present the data on the Web through the Echarts visualization library.
4 Conclusion
The current price of LORA base stations generally ranges from several hundred yuan to thousands of yuan. This study uses LORA aggregation nodes matched with corresponding software designs to replace LORA base stations to achieve long-distance wireless communication. In applications with a small number of monitoring nodes (less than 10), it can significantly reduce hardware costs and is an economical and practical LORA application solution.
Table 1: Data format of the protocol
Table 2: 2-byte address encoding
Figure 3 Terminal node program flow chart
Figure 4: Aggregation node program flow chart
|