One-to-many node wireless communication protocol

Abstract

The invention provides a one-to-many node wireless communication protocol, which comprises the following steps that: a slave node repeatedly sends a function request message to a master node at a first set time interval until a response message is received; the slave node executes a corresponding function according to the function number, when the state changes, an execution state message is stored in a first-in first-out (FIFO) cache queue, and the execution state message in the FIFO cache queue is repeatedly sent to the master node every second set duration until a confirmation message is received; the slave nodes send heartbeat messages to the master node at intervals of third set time; and the master node polls and receives the messages from the slave nodes at intervals of fourth set time. By constructing a complete communication framework of hierarchical confirmation, periodic reporting, state caching and polling processing, the technical effects of reliable data transmission, real-time state synchronization and node manageability and controllability in a one-master multi-slave scene are realized, and the method is suitable for application scenes with relatively high requirements on communication reliability, such as industrial control and networking of the Internet of Things.

Description

Technical Field

[0001] This application relates to the field of electronic information technology, specifically to a one-to-many node wireless communication protocol. Background Technology

[0002] With the widespread application of wireless communication technology in industrial control, the Internet of Things (IoT), and smart devices, reliable data communication between one-to-many nodes has become a critical requirement for many systems. Especially in scenarios such as distributed monitoring, remote control, and data acquisition, there is often a need for data interaction between a master node and multiple slave nodes, requiring communication protocols to possess high reliability, real-time performance, and scalability.

[0003] Currently, there are several networking solutions on the market based on wireless communication modules such as ZigBee, LoRa, and Wi-Fi. For example, a certain company provides a wireless communication module that supports connection to a host computer via a UART interface and enables data transmission between nodes based on the ZigBee physical layer.

[0004] However, existing technical solutions still suffer from problems such as lack of a complete application layer protocol framework, insufficient data transmission reliability, limited real-time performance and synchronization, and imperfect address management and message recognition mechanisms when achieving one-to-many reliable communication; these problems urgently need to be addressed. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a one-to-many node wireless communication protocol.

[0006] This application provides a one-to-many node wireless communication protocol, including the following steps: The slave node repeatedly sends a function request message to the master node at a first set time interval until it receives a request response message carrying the function number from the master node. The slave node executes the corresponding function according to the function number, and when the state changes during the execution, it stores the execution status message in a first-in-first-out (FIFO) buffer queue, and repeatedly sends the execution status message in the FIFO buffer queue to the master node at a second set time interval until it receives a status confirmation message returned by the master node for the execution status message. The slave node sends a heartbeat message to the master node every third set time interval; The master node polls and receives messages from each slave node every four set intervals. When it receives a function request message, it returns a corresponding request response message to the slave node that sent the message according to the predefined address-function number mapping relationship. When it receives an execution status message, it outputs the content of the execution status message and returns a status confirmation message to the slave node that sent the message. When it receives a heartbeat message, it outputs the heartbeat information.

[0007] Furthermore, The function request message, execution status message, and heartbeat message all contain the address information of the sending slave node; The request-response message contains the function number assigned to the slave node; The status confirmation message contains the sequence number of the execution status message it confirms.

[0008] Furthermore, The slave node determines its unique address in the wireless communication network through discrete address lines set by hardware; the master node's address in the wireless communication network is fixed at 0.

[0009] Furthermore, Before sending a message to a slave node, the master node sets the destination address of the wireless communication module to the address of the slave node by setting an instant destination address command.

[0010] Furthermore, The fourth set duration is 25 milliseconds; the first set duration and the second set duration are both 200 milliseconds; the third set duration is 1 second.

[0011] Furthermore, The master node and slave node use DIP switches to set the communication channels they use, and the networks of different channels are independent of each other.

[0012] Furthermore, The wireless communication network is built based on the ZigBee protocol.

[0013] The advantages and positive effects of this application are: This technical solution ensures that the slave node can reliably obtain the function instruction to be executed by repeatedly sending function request messages at a first set time interval until it receives a response from the master node, thus avoiding the node function from stopping due to a single communication failure. By storing the status message in a FIFO queue when the execution status changes and repeatedly sending it at a second set time interval until the master node confirms the status information, reliable reporting and orderly processing of status information are achieved, preventing status loss or out-of-order processing. By sending heartbeat messages from slave nodes at set intervals of three, the master node can monitor the online status of each slave node in real time, thereby improving system maintainability and fault detection capabilities. By polling the master node every fourth set interval to receive and classify various messages, a unified and efficient message scheduling mechanism is built to support ordered communication and real-time response in one-to-many scenarios. Attached Figure Description

[0014] Figure 1 A topology diagram of a one-to-many node wireless communication protocol provided in an embodiment of this application; Figure 2 A flowchart of the host computer software for a one-to-many node wireless communication protocol provided in an embodiment of this application; Figure 3 The flowchart of the slave node host computer software for the one-to-many node wireless communication protocol provided in the embodiments of this application is shown. Detailed Implementation

[0015] To enable those skilled in the art to better understand the technical solution of this application, the application will be described in detail below with reference to the accompanying drawings. The description in this section is only exemplary and explanatory, and should not be used to limit the scope of protection of this application.

[0016] Please refer to Figures 1-3 This embodiment provides a one-to-many node wireless communication protocol, including the following steps: The slave node repeatedly sends a function request message to the master node at a first predetermined time interval until it receives a request response message carrying a function number returned by the master node; the slave node executes the corresponding function according to the function number, and during execution, when the state changes, it stores the execution status message in a first-in-first-out (FIFO) buffer queue, and repeatedly sends the execution status message in the FIFO buffer queue to the master node at a second predetermined time interval until it receives a status confirmation message returned by the master node for the execution status message; the slave node sends a heartbeat message to the master node at a third predetermined time interval; the master node polls and receives messages from each slave node at a fourth predetermined time interval; when a function request message is received, it returns a corresponding request response message to the slave node that sent the message according to a predefined address-function number mapping relationship; when an execution status message is received, it outputs the content of the execution status message and returns a status confirmation message to the slave node that sent the message; when a heartbeat message is received, it outputs heartbeat information.

[0017] In this embodiment, after the slave node is powered on and completes initialization, it repeatedly sends a function request message to the master node at first set intervals. This message is used to request the master node to execute an instruction for a certain function. The slave node continues to send this message until it receives a request response message returned by the master node. The request response message carries the function number assigned to the slave node by the master node, which is used to indicate the specific function that the slave node should execute next.

[0018] In this embodiment, the slave node enters the corresponding function execution process according to the received function number; during the execution process, if its status changes, an execution status message is generated and stored in a first-in-first-out (FIFO) buffer queue; this queue is used to temporarily store all execution status messages that have not yet been acknowledged by the master node.

[0019] In this embodiment, the slave node repeatedly sends the execution status message in the FIFO buffer queue to the master node at second set intervals. After each transmission, if a status confirmation message is received from the master node for the status message within a set time, the message is removed from the queue and the repeated transmission stops. If no confirmation is received, the slave node continues to repeat the transmission after the set time until a confirmation is received.

[0020] In this embodiment, during the operation of the slave node, regardless of whether it is in the function execution state, a heartbeat message is sent to the master node every third set time interval to indicate its online status and normal operation to the master node.

[0021] In this embodiment, after the master node is powered on, it polls and receives messages from each slave node every four set intervals. The master node maintains a predefined address-function number mapping table, which specifies the correspondence between the address of each slave node and the function number it should execute.

[0022] When the master node receives a function request message from a slave node, it looks up the mapping table based on the slave node's address, obtains the corresponding function number, and returns a request response message carrying the function number to the slave node.

[0023] When the master node receives an execution status message from a slave node, it outputs the status content in the message (e.g., displays it on the user interface or logs it) and returns a status confirmation message to the slave node.

[0024] When the master node receives a heartbeat message, it outputs heartbeat information (such as updating the last active time of the slave node) to monitor the online status of the slave node.

[0025] In a preferred embodiment, the function request message, execution status message, and heartbeat message all contain the address information of the sending slave node; the request response message contains the function number assigned to the slave node; and the status confirmation message contains the sequence number of the execution status message it confirms.

[0026] In this embodiment, all uplink messages sent from the slave node to the master node explicitly include the slave node's own address information in the message content.

[0027] Specifically, Function request message: The message contains a one-byte field to store the address of the sender slave node.

[0028] Execution status message: The message contains not only the status content, but also a one-byte sender slave node address.

[0029] Heartbeat message: The message contains a one-byte sender slave address.

[0030] With the above design, when the master node receives any uplink message, it can directly parse "which slave node this message came from" from the message content, thereby realizing the differentiation and management of multiple slave nodes without relying on the underlying network address; this provides a basis for the master node to perform targeted responses and status tracking.

[0031] In this embodiment, the downlink messages sent by the master node to a specific slave node are designed with the content format clearly conveying instructions or confirming completion: Request-response message: When the master node responds to a function request from a slave node, the request-response message it sends contains a "function number" (occupying one byte) assigned to that slave node; this function number directly indicates the specific function module that the slave node should enter and execute next.

[0032] Status confirmation message: When the master node confirms that it has received an execution status report from a slave node, the status confirmation message it sends contains a "sequence number" field (occupying one byte). This sequence number comes from the execution status message it confirmed and is used for precise matching on the slave node side, indicating that the master node has successfully received and processed the specific status report.

[0033] In this embodiment, the above message format constitutes the basic framework of application layer communication of this protocol: All uplink messages come with their own source address, which makes the polling processing logic of the master node uniform and efficient. Only the message content needs to be parsed to find out the message source and query the corresponding predefined strategy (such as address-function number mapping).

[0034] Downlink messages carry explicit instructions (function numbers) or acknowledgments (sequence numbers), enabling slave nodes to unambiguously understand the master node's intent and perform corresponding operations or update their local transmission status.

[0035] Through this structured message format design, this protocol builds a set of upper-layer identification, addressing and acknowledgment mechanisms on the basis of transparent transmission provided by wireless networks such as ZigBee, effectively supporting a reliable and orderly communication process in one-to-many scenarios.

[0036] In a preferred embodiment, the slave node determines its unique address in the wireless communication network through discrete address lines configured by hardware; the address of the master node in the wireless communication network is fixed at 0.

[0037] In this embodiment, in the system to which this protocol is applied, each slave node device has a discrete address setting mechanism in its hardware design.

[0038] Specifically, the device has a set of physical address lines (such as hardware lines that can be set via rotary switches, DIP switches, or jumper caps). Different combinations of physical states of these address lines correspond to different binary address values. For example, if an 8-bit DIP switch is used, 256 independent address settings can be provided.

[0039] During the device power-on initialization phase, the host computer software or firmware of the slave node reads the physical status of these address lines, converts them into the corresponding network communication address, and uses this address as the unique identifier of this node in the entire wireless network. Once this address is set, it remains unchanged during device operation, thereby ensuring that each slave node has a unique and fixed network identity.

[0040] In this embodiment, unlike the slave nodes, the address of the master node in the wireless communication network is not set by a similar hardware switch, but is fixed to a specific value at the protocol level; in this embodiment, this value is agreed to be 0; this fixed address serves as the convergence point address of the entire network, and when all slave nodes send uplink messages, their underlying wireless communication modules default to sending data to the master node with address 0.

[0041] In this embodiment, the protocol achieves the following through an allocation scheme of "slave node hardware addressing and master node address fixed at 0": Plug and play and avoidance of conflicts: The node addresses are physically isolated, and the uniqueness of the address can be ensured through hardware settings during installation, without the need for complex network address allocation protocols, thus avoiding address conflicts.

[0042] Simplified network logic: The fixed address of the master node simplifies the concepts of network routing and discovery, making it particularly suitable for star networks with a simple structure and a fixed number of nodes.

[0043] Stable and reliable: The address set by the hardware is not easily changed due to software errors or network disturbances, providing a stable communication foundation.

[0044] In a preferred embodiment, before sending a message to a slave node, the master node sets the destination address of the wireless communication module to the address of the slave node by setting an instant destination address command.

[0045] In this embodiment, the master node needs to have the ability to send messages to any specified slave node in the network; however, in the underlying wireless network, the module usually needs to know the exact destination address of each frame of data in order to perform correct radio frequency transmission and routing; therefore, the application layer protocol must provide a method to transform the intention of "need to send to slave node A" into the operation of "set the destination address to A" for the wireless module.

[0046] In this embodiment, the protocol utilizes the existing "set instant destination address command" of the wireless communication module to achieve the above requirements; this command is one of the underlying interface commands provided by the module supplier, used to temporarily change the destination network address used by the module when it sends data next time.

[0047] Before sending any application-layer message to a specific slave node, the master node software must perform the following steps: Step 1: Determine the target slave node address; this address comes from the context within the master node software; for example, when it is necessary to reply to a function request from a slave node, the target address is the source address that the master node just parsed from the message reported by that slave node.

[0048] Step 2: Invoke the setting command; the master node sends a "set instant destination address command" to the local wireless communication module connected to it through its serial port (such as UART), and sets the parameter of the command to the target slave node address determined in Step 1.

[0049] Step 3: Send application layer data; After the setup command is executed successfully, the master node then sends the actual application layer message data frame that needs to be sent downlink to the wireless module via the serial port; At this time, the wireless module will automatically use the previously set instantaneous destination address as the sending target of this frame data.

[0050] In this embodiment, by adopting the "set address first, then send" process, this protocol achieves: Precise point-to-point downlink communication: Ensuring that every downlink message accurately reaches the intended slave node is the foundation for reliable command issuance and status confirmation.

[0051] Dynamic and flexible address management: The master node can switch dialogue objects at any time according to the communication context, without having to maintain a fixed data link for each slave node, which simplifies the connection state management of the master node.

[0052] Tight integration with hardware functions: It makes full use of the existing control commands of the underlying wireless module, and achieves simplicity and efficiency in the design of the application layer protocol. It does not need to repeatedly carry the destination address in the application layer data frame (the destination address is already guaranteed by the underlying layer), thus improving communication efficiency.

[0053] Avoid address confusion: A clear, real-time setting mechanism prevents messages from being mistakenly sent to the wrong slave node due to address caching or remnants.

[0054] In a preferred embodiment, the fourth set duration is 25 milliseconds; the first set duration and the second set duration are both 200 milliseconds; and the third set duration is 1 second.

[0055] In a preferred embodiment, the master node and slave node set the communication channel they use via a DIP switch, and the networks of different channels are independent of each other.

[0056] In this embodiment, a DIP switch is integrated into the hardware design of each node device (including the master node and each slave node) to which this protocol is applied. The switch is an independent physical component, usually consisting of several bits (e.g., 4 bits or 8 bits) of miniature toggle switches, which are installed on the operable parts of the device housing or on the internal circuit board. Each bit of the switch represents a binary bit, and the combined state of all bits represents an integer value. This hardware switch is dedicated to setting the wireless communication channel number used when the device is working.

[0057] In a preferred embodiment, the wireless communication network is built based on the ZigBee protocol.

[0058] In this embodiment, the implementation of this protocol relies on a wireless communication module conforming to the ZigBee protocol standard integrated in each network node device. This module is a complete hardware and software solution, typically including a radio frequency transceiver, a microprocessor, and a complete ZigBee protocol stack software embedded within it. The host computer or main controller of the node device connects to this ZigBee module through a serial communication interface (such as UART) to send data to it or receive data from it. All application layer message interactions defined in this protocol are ultimately converted into radio frequency signals conforming to the ZigBee standard and transmitted in the air via these ZigBee modules.

[0059] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of textual expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A one-to-many node wireless communication protocol, applied to a wireless communication network including one master node and multiple slave nodes, characterized in that, The method comprises the following steps: The slave node repeatedly sends a function request message to the master node every first set time interval until a request response message carrying a function number returned by the master node is received; The slave node executes a corresponding function according to the function number, and in the execution process, when a state changes, stores an execution state message in a first-in-first-out (FIFO) cache queue, and repeatedly sends the execution state message in the FIFO cache queue to the master node every second set time interval until a state confirmation message returned by the master node for the execution state message is received; The slave node sends a heartbeat message to the master node every third set time; The master node polls messages from each slave node every fourth set time; when a function request message is received, according to a predefined address-function number mapping relationship, returns a corresponding request response message to the slave node sending the message; When an execution state message is received, outputs the content of the execution state message and returns a state confirmation message to the slave node sending the message; when a heartbeat message is received, outputs the heartbeat information.

2. The one-to-many node wireless communication protocol according to claim 1, wherein The function request message, the execution state message and the heartbeat message each contain address information of the sending slave node; The request response message contains a function number allocated to the slave node; The state confirmation message contains a sequence number of the execution state message confirmed thereby.

3. The one-to-many node wireless communication protocol according to claim 1, wherein The slave node determines its unique address in the wireless communication network through a discrete address line set by hardware; and the address of the master node in the wireless communication network is fixed as 0.

4. The one-to-many node wireless communication protocol according to claim 1, wherein Before sending a message to a slave node, the master node sets the destination address of the wireless communication module as the address of the slave node through an instant destination address command.

5. The one-to-many node wireless communication protocol according to claim 1, wherein The fourth set time interval is 25 milliseconds; the first set time interval and the second set time interval are both 200 milliseconds; and the third set time interval is 1 second.

6. The one-to-many node wireless communication protocol according to claim 1, wherein The master node and the slave node set the communication channel used thereby through a dial code switch; and networks of different channels are independent of each other.

7. The one-to-many node wireless communication protocol according to any one of claims 1-6, wherein The wireless communication network is constructed based on the ZigBee protocol.

Images