Method for transmitting data among different system devices

Abstract

The invention discloses a method for transmitting data among different system devices, which comprises the following steps that: a TLV frame consists of a frame header, a tag, length data length, value data and CRC (Cyclic Redundancy Check) check and is represented by hexadecimal, a frame header 0xFD is added in front of each frame of data, a machine B judges whether the first byte of the received data is the frame header or not, data analysis is carried out, and the data is transmitted to the machine B; according to the method, the processing of the next normal message cannot be influenced by the previous error message, the problem that all the messages are wrong due to the error of one frame can be solved through a mechanism of adding the frame header, a CRC check value is added to the last of each frame of data, once the error of one frame of data occurs, the CRC check of a receiving party must be wrong, and the processing efficiency of the receiving party is improved. In this way, the next frame of data can be analyzed, the processing of frame header and tail CRC verification is added, the data length is accommodated and expanded to two bytes, the longest 65000 + byte data can be represented, and most of Internet of Things data interaction scenes can be covered.

Description

Technical Field

[0001] The present invention relates to the technical field of data transmission, and in particular to a method for transmitting data between different system devices. Background Art

[0002] At present, the solutions closely related to this patent mainly focus on data transmission protocols based on the TLV encoding mechanism. This encoding method uses a clear type identifier (Tag) to distinguish data types and uses a length field (Length) to indicate the number of bytes of the subsequent specific data value (Value), thereby constructing a structured data representation method. TLV encoding is widely used in scenarios that require efficient parsing and reliable data transmission, such as financial transactions, Internet of Things communications, and real-time data monitoring.

[0003] However, the existing TLV protocol has the following objective disadvantages, which limit its performance and application scope in specific application scenarios: 1. Imperfect error handling mechanism: During data transmission, data loss, corruption, or format errors may occur due to network fluctuations, equipment failures, etc. The existing TLV protocol may lack a perfect mechanism for error handling and cannot effectively identify and handle these problems, resulting in the reliability and stability of data transmission being affected.

[0004] 2. Limited interoperability: Although the TLV encoding method has a certain degree of universality, different systems or manufacturers may use different encoding rules, data structures, and error handling mechanisms when implementing the TLV protocol. Such differences may limit the interoperability between different systems and increase the complexity and cost of data exchange.

[0005] 3. High resource consumption: In some cases, the existing TLV protocol may introduce unnecessary complexity and redundant information in the encoding and decoding process due to excessive focus on data integrity and structural clarity. This may lead to more consumption of computing resources and bandwidth resources during data transmission and processing, reducing the overall performance of the system.

[0006] Currently, no effective solution has been proposed for the problems in the related technologies. Summary of the invention

[0007] In view of the problems in the related art, the present invention proposes a method for transmitting data between different system devices to overcome the above technical problems existing in the existing related art.

[0008] To this end, the specific technical solution adopted by the present invention is as follows: A method for transmitting data between different system devices, the method comprising: Step 1. The TLV frame consists of a frame header, tag, length data length, value data, and CRC checksum, expressed in hexadecimal: Step 2, frame header: fixed value is 0xFD; Step 3, tag: field to distinguish frame type; Step 4, length: the length of the data area value; Step 5, value: data area, variable length, controlled by the length field; Step 6, CRC: data frame verification, ranging from the frame header to the data area.

[0009] As a further solution of the present invention, the frame header indicates the beginning of a frame, and the protocol content of the subsequent data is matched one-to-one from this byte, and ends with the CRC check value of the last two bytes.

[0010] As a further solution of the present invention, after the receiving party completes the reception, it checks the data except the CRC at the end, and obtains the same result as the received CRC check value, indicating that there is no problem with the data received this time and can be used for further processing.

[0011] As a further solution of the present invention, a frame header 0xFD is added before each frame of data.

[0012] As a further solution of the present invention, the data sent by machine A again is: 0xFD 0x01 0x02 0x14 0x30 0xFD 0x02 0x02 0x47 0x33. Now the data received by machine B is: 0x02 0x14 0x30 0xFD 0x02 0x02 0x47 0x33.

[0013] As a further solution of the present invention, a CRC check value is added at the end of each frame of data, and the data length is expanded to two bytes, which can represent a maximum of 65000+ bytes of data.

[0014] The beneficial effects of the present invention are as follows: a frame header 0xFD is added before each frame of data, and the B machine will determine whether the first byte of the received data is a frame header, and then perform data parsing, so that the previous error message will not affect the processing of the next normal message. By adding a frame header mechanism, the problem that one frame error causes all messages to be wrong can be solved. A CRC check value is added at the end of each frame of data. Once a frame of data is wrong, the receiving party will definitely make an error during the CRC check. In this way, the next frame of data will be parsed, and the processing of the frame header and the end CRC check is added. The data length is expanded to two bytes, which can represent a maximum of 65,000+ bytes of data, which is sufficient to cover most IoT data interaction scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0016] Figure 1 is a flow chart of a method for transmitting data between different system devices according to an embodiment of the present invention; Figure 2 4 is a system diagram of a method for transmitting data between different system devices according to an embodiment of the present invention. DETAILED DESCRIPTION

[0017] To further illustrate each embodiment, the present invention provides drawings, which are part of the disclosure of the present invention and are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these contents, ordinary technicians in the field should be able to understand other possible implementations and advantages of the present invention. The components in the figures are not drawn to scale, and similar component symbols are generally used to represent similar components.

[0018] According to an embodiment of the present invention, a method for transmitting data between different system devices is provided.

[0019] Please refer to the instruction manual Figure 1-2 According to an embodiment of the present invention, a method for transmitting data between different system devices includes: Step 1. The TLV frame consists of a frame header, tag, length data length, value data, and CRC checksum, expressed in hexadecimal: Step 2, frame header: fixed value is 0xFD; Step 3, tag: field to distinguish frame type; Step 4, length: the length of the data area value; Step 5, value: data area, variable length, controlled by the length field; Step 6, CRC: data frame verification, ranging from the frame header to the data area.

[0020] A frame header 0xFD is added before each frame of data. In this way, the data sent by machine A again is: 0xFD0x01 0x02 0x14 0x30 0xFD 0x02 0x02 0x47 0x33. Now the data received by machine B is: 0x020x14 0x30 0xFD 0x02 0x02 0x47 0x33. The data (0xFD 0x01) is lost. Then machine B will determine whether the first byte of the received data is the frame header, and then parse the data. Because 0x02 0x14 0x30 does not contain the frame header 0xFD, it will discard these error messages and continue to look for the next message starting with 0xFD (0xFD 0x02 0x020x47 0x33), in this case, the previous error message will not affect the processing of the next normal message. By adding the frame header mechanism, the problem of one frame error causing all messages to be wrong can be solved.

[0021] A CRC checksum value is added at the end of each frame of data. Once a frame of data is wrong, the receiver will definitely make an error during the CRC check, and will then parse the next frame of data.

[0022] By adding frame header and end CRC check processing, the data length is expanded to two bytes, which can represent a maximum of 65,000+ bytes of data, sufficient to cover most IoT data interaction scenarios.

[0023] The above are only preferred embodiments of the present invention and are 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 protection scope of the present invention.

Claims

1. A method for transmitting data between different system devices, characterized in that: The method comprises: Step 1. The TLV frame consists of a frame header, tag, length data length, value data, and CRC checksum, expressed in hexadecimal: Step 2, frame header: fixed value is 0xFD; Step 3, tag: field to distinguish frame type; Step 4, length: the length of the data area value; Step 5, value: data area, variable length, controlled by the length field; Step 6, CRC: data frame verification, ranging from the frame header to the data area.

2. A method for transmitting data between different system devices according to claim 1, characterized in that: The frame header indicates the beginning of a frame. From this byte, the subsequent data is matched with the protocol content one by one, and ends with the CRC check value of the last two bytes.

3. A method for transmitting data between different system devices according to claim 1, characterized in that: After the receiver completes the reception, it checks the data except the CRC at the end, and obtains the same result as the received CRC check value, indicating that there is no problem with the data received this time and can be used for further processing.

4. The method for transmitting data between different system devices according to claim 1, characterized in that: A frame header 0xFD is added before each frame of data.

5. A method for transmitting data between different system devices according to claim 4, characterized in that: The data sent by machine A again is: 0xFD 0x01 0x02 0x14 0x30 0xFD 0x02 0x02 0x47 0x33. Now the data received by machine B is: 0x02 0x14 0x30 0xFD 0x02 0x02 0x47 0x33.

6. A method for transmitting data between different system devices according to claim 1, characterized in that: A CRC checksum is added at the end of each frame of data, and the data length is expanded to two bytes, which can represent a maximum of 65,000+ bytes of data.

Images