Data transmission method of lightweight communication protocol system

Abstract

The invention discloses a data transmission method of a lightweight communication protocol system, and relates to the field of data transmission, the system comprises a communication module, an identification module, an analysis module and an output module; the communication module is used for receiving data, the identification module is used for identifying data types, the analysis module is used for identifying the data, and the output module is used for outputting according to the data types. In the invention, a simple data format is adopted, a unique byte 0 * 80 is used as a protocol packet header, and redundant control bytes such as length fields, frame headers, frame tails, function codes and the like in a traditional protocol are abandoned. According to the simplified design, the transmission load is greatly reduced, and the complexity of processing logic is reduced, so that the protocol system can perfectly adapt to low-power-consumption embedded equipment with limited resources.

Description

Technical Field

[0001] The present invention relates to the field of data transmission, and in particular to a data transmission method of a lightweight communication protocol system. Background Art

[0002] In field operations, such as power operation and maintenance, forest inspections, geological surveys, emergency rescue, and border patrols, workers are often in areas without public network coverage or where communication conditions are extremely unstable. Traditional security monitoring and alarm systems that rely on cellular networks (such as 4G / 5G) or Wi-Fi are difficult to operate stably in such environments, and may suffer from problems such as untimely data transmission, link interruptions, and high false alarm rates.

[0003] To improve communication coverage and system reliability, some solutions have attempted to build low-bandwidth communication links using Beidou short messages, LoRa spread-spectrum communications, and Zigbee ad hoc networks, using custom protocols to transmit personnel status and report SOS alarm signals. However, most of these protocols are derived from general-purpose communication protocol stacks (such as MQTT and Modbus) and still have the following technical limitations in terms of structural complexity, transmission efficiency, and false alarm control:

[0004] First, the protocol structure is redundant and has numerous fields, usually including length fields, frame headers, frame trailers, function codes and other control bytes, resulting in heavy transmission load and complex processing logic, making it unsuitable for use in resource-constrained low-power embedded devices.

[0005] Second, the data content lacks semantic distinction, and all communication information is uniformly processed as raw payload, which cannot automatically identify professional communication data and ordinary text information, increasing the system analysis cost and the risk of misjudgment.

[0006] Third, the SOS alarm judgment mechanism is simply designed, and most adopt the "single trigger alarm" strategy, which is prone to false alarms due to electromagnetic interference, operational errors or transient abnormalities, affecting the system credibility and alarm effectiveness.

[0007] Fourth, although existing verification methods such as CRC and FCS have error correction capabilities, they have high computational complexity and large resource consumption, which is not conducive to deployment and operation in lightweight communication equipment.

[0008] In summary, the existing technology still lacks a communication protocol solution with a lightweight structure, accurate recognition, efficient processing and low false alarm rate in data transmission and SOS signal recognition in weak signal environments in the wild. Summary of the Invention

[0009] In view of this, the present invention aims to propose a data transmission method for a lightweight communication protocol system to solve the problems in the prior art.

[0010] To achieve the above object, the technical solution of the present invention is achieved as follows:

[0011] The present invention proposes a data transmission method of a lightweight communication protocol system, wherein the system includes a communication module, an identification module, a parsing module, and an output module;

[0012] The communication module is used to receive data, the identification module is used to identify the data type, the parsing module is used to identify the data, and the output module is used to output according to the data type;

[0013] The method comprises the following steps:

[0014] S1, receives data streams from external devices through the communication module;

[0015] S2, the recognition module constructs a data format with the unique byte 0x80 as the protocol packet header, extracts the first byte of the data and performs protocol judgment;

[0016] S3, the parsing module identifies the data type of the protocol content based on the data flag field;

[0017] S4: For the identified SOS data, a time window redundancy judgment mechanism is activated to determine whether it is caused by occasional false alarms or interference;

[0018] S5, the confirmed protocol data is output according to the type.

[0019] Furthermore, the data enters the communication module in the form of a byte stream for buffering.

[0020] Furthermore, when the first byte of the data is 0x80, the recognition module determines that the data stream is a data packet that complies with the protocol format and transfers it to the parsing module for type analysis;

[0021] If the first byte is not 0x80, the data is considered to be general text information and directly enters the text output channel.

[0022] Furthermore, the data flag field includes 0x01, 0x02 and 0x03, which respectively correspond to the personnel status, general SOS and special SOS in the data type.

[0023] Furthermore, the personnel status data field contains two bytes, which are the total number of people in the task and the number of people online;

[0024] The general SOS data field is a single-byte event code corresponding to a predefined event;

[0025] The special SOS data field is followed by a variable-length ASCII string.

[0026] Furthermore, the data flag fields are combined in sequence and a check field is added at the end of the data packet;

[0027] The check field is calculated by summing all bytes except the check field in unsigned integer format and taking the hexadecimal value of the lowest 8 bits of the result.

[0028] Furthermore, the time window redundancy judgment mechanism includes:

[0029] A 10-second time window is set; when the SOS signal from the same terminal reaches 3 times within the time window, the alarm is considered valid; if the trigger threshold is not reached, the SOS alarm is considered invalid.

[0030] Furthermore, the output module is one or a combination of a buzzer, an LED indicator device and a terminal display screen.

[0031] Compared with the prior art, the present invention has the following advantages:

[0032] This invention adopts a concise data format, using the unique byte 0x80 as the protocol packet header, eliminating the redundant length field, frame header, frame trailer, function code, and other control bytes found in traditional protocols. This streamlined design significantly reduces the transmission load and the complexity of the processing logic, making the protocol system ideally suited for resource-constrained, low-power embedded devices. In field operations, equipment often needs to operate for extended periods of time with limited energy supplies. This method effectively reduces device power consumption, extends its service life, and improves its reliability and stability in harsh environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which constitute part of the present invention, are provided to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are provided to explain the present invention and do not constitute an undue limitation of the present invention. In the accompanying drawings:

[0034] Figure 1 Schematic diagram of the overall structure of the system of the present invention;

[0035] Figure 2 Flow chart of the method of the present invention. DETAILED DESCRIPTION

[0036] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0037] In the description of the present invention, it should be noted that the terms "upper," "lower," "inner," and "back" and other terms indicating orientations or positional relationships are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limitations on the present invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0038] Furthermore, in the description of the present invention, unless otherwise expressly defined, the terms "mounted," "connected," "connect," and "connector" should be interpreted broadly. For example, these terms may refer to fixed, removable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediary; or internal communication between two components. Those skilled in the art will appreciate the specific meanings of these terms in the present invention based on the specific circumstances.

[0039] The following will refer to the attached Figure 1 and Figure 2 The present invention is described in detail with reference to the embodiments.

[0040] In general, the present invention proposes a data transmission method for a lightweight communication protocol system, wherein the system includes a communication module, an identification module, a parsing module, and an output module;

[0041] The communication module is used to receive data, the identification module is used to identify the data type, the parsing module is used to identify the data, and the output module is used to output according to the data type;

[0042] The method comprises the following steps:

[0043] S1, receives the data stream sent by the external device through the communication module, and the data enters the communication module in the form of byte stream for buffering;

[0044] S2, the recognition module extracts the first byte of the data to determine the protocol;

[0045] S3, the parsing module identifies the data type of the protocol content based on the data flag field;

[0046] S4: For the identified SOS data, a time window redundancy judgment mechanism is activated to determine whether it is caused by occasional false alarms or interference;

[0047] S5, the confirmed protocol data is output according to the type.

[0048] The identification module constructs a data format with the unique byte 0x80 as the protocol packet header, which is used to identify whether the data packet is protocol data. When the first byte of the data is 0x80, the identification module determines that the data stream is a data packet that conforms to the protocol format and forwards it to the parsing module for type analysis;

[0049] If the first byte is not 0x80, the data is considered to be general text information and directly enters the text output channel.

[0050] In this embodiment, a concise data format is adopted, with the unique byte 0x80 as the protocol packet header, eliminating the redundant length field, frame header, frame trailer, function code, and other control bytes found in traditional protocols. This streamlined design significantly reduces the transmission load and the complexity of the processing logic, making the protocol system perfectly adaptable to resource-constrained, low-power embedded devices. In field operations, equipment often needs to operate for long periods of time with limited energy supplies. This method effectively reduces device power consumption, extends its service life, and improves its reliability and stability in harsh environments.

[0051] The recognition module extracts the first byte of the data to determine the protocol, quickly distinguishing between protocol data and general text messages. Packets that conform to the protocol format are forwarded to the parsing module for further type analysis; general text messages are directly sent to the text output channel. This differentiated processing avoids the cumbersome process of uniformly processing all data as raw payloads, significantly reducing system parsing costs and improving data recognition accuracy and efficiency. Even in weak signal conditions in the field, it can quickly and accurately process received data, ensuring the timely delivery of critical information.

[0052] For identified SOS-type data, this method uses a time-windowed redundant judgment mechanism. This mechanism effectively avoids false alarms caused by factors such as electromagnetic interference, operational errors, or transient anomalies. By repeatedly detecting and judging SOS signals within a time window, a valid SOS alarm is only confirmed if the signal continuously meets the alarm conditions within the specified time. This reduces the false alarm rate, improves system reliability and alarm effectiveness, and provides more reliable safety protection for field workers.

[0053] In practice, the communication module is in a continuous listening state. When an external device sends data, the data enters the communication module in the form of a byte stream. The communication module first buffers the received byte stream for processing by subsequent modules. This ensures the integrity and order of the data, providing a foundation for subsequent identification, parsing, and output.

[0054] The identification module extracts the first byte of data from the communication module's cache and performs protocol analysis. The identification module constructs a data format using the unique byte 0x80 as the protocol packet header, which identifies whether a data packet is protocol data. If the first byte of the data is 0x80, the identification module determines that the data stream conforms to the protocol format and forwards the packet to the parsing module for type analysis. If the first byte is not 0x80, the data is considered general text information and is directly routed to the text output channel. This enables rapid differentiation between protocol data and general text information, improving data processing efficiency.

[0055] After receiving the protocol-compliant data packets from the identification module, the parsing module identifies the data type of the protocol content based on the data flag field. Different data flag fields correspond to different data types. By analyzing the data flag field, the parsing module can accurately determine the specific data type, providing a basis for subsequent output processing.

[0056] When the parsing module identifies the data as SOS data, the system activates the time window redundant judgment mechanism to determine whether the SOS alarm is an effective alarm.

[0057] The confirmed protocol data is output according to its type. For different types of data, the output module will guide them to the corresponding output channel.

[0058] The above-mentioned data flag field includes 0x01, 0x02 and 0x03, which respectively correspond to the personnel status, general SOS and special SOS in the data type.

[0059] In this embodiment, the data flag field is clearly divided into three data types: 0x01, 0x02, and 0x03, corresponding to personnel status, general SOS, and special SOS, respectively, so that the system can classify different types of data more accurately and meticulously. In field operation scenarios, different types of data have different importance and processing priorities. For example, personnel status information is crucial for understanding the health status and location of operators; general SOS alarms may indicate a routine emergency; special SOS alarms may correspond to more serious situations that require special rescue resources. Through this precise classification, the system can take targeted processing measures based on different data types to improve the efficiency and accuracy of emergency response.

[0060] It's important to note that the output module directs different types of data to corresponding output channels. For example, personnel status information might be output to the monitoring center's management interface, allowing managers to understand the status of field workers in real time. Equipment status information might be output to the terminal devices of maintenance personnel, facilitating timely maintenance and management. Valid SOS alarm signals are output with the highest priority to the emergency response center, ensuring that relevant personnel can quickly initiate rescue measures. This stage ensures accurate data output, meeting the needs of diverse application scenarios.

[0061] Furthermore, the personnel status data field contains two bytes, which are the total number of people on the task and the number of people online, respectively; the general SOS data field is a single-byte event code corresponding to a predefined event; the special SOS data field is followed by a variable-length ASCII string.

[0062] In this embodiment, through this configuration, critical information about personnel status can be quickly transmitted with minimal data volume in weak signal environments outdoors. This reduces the data transmission burden on resource-constrained communication equipment, improving both efficiency and reliability. Furthermore, the total number of personnel and the number of people online are fundamental and crucial information for field operations management. They enable monitoring personnel to quickly understand the size of the operation team and the current availability of personnel, providing strong support for subsequent decision-making.

[0063] Typically, the SOS data field uses a single-byte event code corresponding to predefined events. This design allows for quick identification of the event type upon receiving an SOS alert. Predefined event codes cover common emergency situations, such as injuries, equipment failures, and encounters with wild animals. Single-byte coding reduces data transmission volume and speeds up alert information delivery, enabling emergency responders to quickly identify the event type and take appropriate rescue measures.

[0064] The special SOS data field is followed by a variable-length ASCII string. This design allows for flexible communication of detailed descriptive information in special emergency situations. For example, in special situations such as major natural disasters and severe casualties, rescue workers can use ASCII strings to describe the on-site situation in detail, including the type of disaster, number of injured, specific location, and required rescue resources. This provides the emergency response center with more comprehensive and accurate information, facilitating the development of more effective rescue plans. The variable-length ASCII string design enables the system to adapt to these complex and changing scenarios without being restricted by fixed data formats. Rescuers can freely enter relevant information based on the actual situation, ensuring the completeness and accuracy of the information.

[0065] Based on the above settings, the data flag fields are combined in sequence and a check field is added to the end of the data packet. The check field is calculated by summing all bytes except the check field as unsigned integers and taking the hexadecimal value of the lowest 8 bits of the result.

[0066] Adding a checksum field can enhance the integrity verification of data transmission. In field operation scenarios, the communication environment may be unstable and susceptible to interference. The addition of a checksum field provides a reliable security barrier for data transmission.

[0067] The above-mentioned time window redundancy judgment mechanism includes:

[0068] A 10-second time window is set; when the SOS signal from the same terminal reaches 3 times within the time window, the alarm is considered valid; if the trigger threshold is not reached, the SOS alarm is considered invalid.

[0069] In field operations, communication signals can be subject to various interferences, such as electromagnetic interference and terrain obstructions, causing devices to occasionally issue erroneous SOS signals. By setting a 10-second time window and requiring three SOS signals within that window for an alarm to be considered valid, false alarms caused by occasional interference or misoperation can be significantly reduced. For example, if a device briefly issues an SOS signal due to static electricity, the system will deem it an invalid alarm because it has not reached the three-time trigger threshold, thus avoiding unnecessary waste of emergency response resources.

[0070] It should be further explained that the output module is one or a combination of a buzzer, an LED indicator device and a terminal display screen.

[0071] Different field operation scenarios may require different alarm notification methods. For example, LED indicators and terminal displays are more effective during nighttime operations or in dimly lit environments. In contrast, buzzers are more effective in scenarios where personnel are dispersed and it's difficult to focus on the display. The output module utilizes a combination of various devices, allowing for flexible configuration based on specific scenarios and needs, ensuring effective alarm communication in all situations.

[0072] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A data transmission method for a lightweight communication protocol system, characterized in that: The system includes a communication module, an identification module, a parsing module, and an output module; The communication module is used to receive data, the identification module is used to identify the data type, the parsing module is used to identify the data, and the output module is used to output according to the data type; The method comprises the following steps: S1, receives data streams from external devices through the communication module; S2, the recognition module constructs a data format with the unique byte 0x80 as the protocol packet header, extracts the first byte of the data and performs protocol judgment; S3, the parsing module identifies the data type of the protocol content based on the data flag field; S4: For the identified SOS data, a time window redundancy judgment mechanism is activated to determine whether it is caused by occasional false alarms or interference; S5, the confirmed protocol data is output according to the type.

2. The data transmission method of a lightweight communication protocol system according to claim 1, characterized in that: Data enters the communication module in the form of byte stream for buffering.

3. The data transmission method of a lightweight communication protocol system according to claim 2, characterized in that: When the first byte of the data is 0x80, the recognition module determines that the data stream is a data packet that conforms to the protocol format and transfers it to the parsing module for type analysis; If the first byte is not 0x80, the data is considered to be general text information and directly enters the text output channel.

4. The data transmission method of a lightweight communication protocol system according to claim 3, characterized in that: The data flag field includes 0x01, 0x02 and 0x03, which respectively correspond to the personnel status, general SOS and special SOS in the data type.

5. The data transmission method of a lightweight communication protocol system according to claim 4, characterized in that: The personnel status data field contains two bytes, which are the total number of people on the task and the number of people online. The general SOS data field is a single-byte event code corresponding to a predefined event; The special SOS data field is followed by a variable-length ASCII string.

6. The data transmission method of a lightweight communication protocol system according to claim 5, characterized in that: Combine the data flag fields in order and add a check field at the end of the data packet; The check field is calculated by summing all bytes except the check field in unsigned integer format and taking the hexadecimal value of the lowest 8 bits of the result.

7. The data transmission method of a lightweight communication protocol system according to claim 1, characterized in that: The time window redundancy judgment mechanism includes: A 10-second time window is set; when the SOS signal from the same terminal reaches 3 times within the time window, the alarm is considered valid; if the trigger threshold is not reached, the SOS alarm is considered invalid.

8. The data transmission method of a lightweight communication protocol system according to claim 1, characterized in that: The output module is one or a combination of a buzzer, an LED indicator device and a terminal display screen.

Images