Hydraulic flatbed trailer main longitudinal beam safety fusion source coding method and device

Abstract

This invention provides a method and apparatus for safety fusion source coding of the main longitudinal beam of a hydraulic flatbed trailer. Based on the characteristics of important safety parameter signals from the hydraulic sensors of the hydraulic flatbed trailer, a base-64 encoding method is used, and the code length is calculated. Then, Huffman coding is used, and the code length is calculated again. The base-64 encoding code length is compared with the Huffman encoding code length. If the base-64 encoding code length is less than or equal to the Huffman encoding code length, the base-64 encoding is output; otherwise, the Huffman encoding is output. This invention overcomes the deficiency of Huffman coding in terms of low coding rate for shorter data and employs a fusion source coding strategy. The two methods complement each other, achieving more stable wireless communication of important safety parameters of the main longitudinal beam of the hydraulic flatbed trailer.

Description

Technical Field

[0001] This invention provides a method and apparatus for safety fusion source coding of the main longitudinal beam of a hydraulic flatbed trailer, belonging to the field of data communication technology. Background Technology

[0002] The development of modern equipment manufacturing, energy, and chemical industries has led to increasingly larger and more bulky integral equipment. Increasing the number of trailer axles to meet the load-bearing capacity of roads and bridges has become a common technical requirement in the highway heavy transport industry.

[0003] Hydraulic flatbed trailers are used for transporting large and oversized equipment. In the scenario of wireless safety monitoring of their main longitudinal beams, the vibration frequency may exceed 30Hz under the excitation of uneven road surface. If the wireless transmission of important safety parameter signals of the hydraulic sensors of the hydraulic flatbed trailer is not coded with source code, communication will be congested and the real-time monitoring cannot be guaranteed.

[0004] CN105450232A provides an encoding and decoding method, as well as an encoding and decoding device. The encoding method includes: acquiring data to be encoded, the data to be encoded being a binary string; encoding the data to be encoded according to a base-64 encoding rule to obtain encoded data corresponding to the data to be encoded, the encoded data being a base-64 encoded string, wherein the base-64 encoding rule uses the following 64 characters: 0-9, @, AZ, _, az. This encoding method, while saving storage space by shortening the length of the data to be encoded, also has stronger compatibility because all characters in the character set used in the encoding method of this embodiment can be used as filenames under Linux and Windows operating systems, and the characters "@" and "_" can be directly used in shell and regular expressions, and are compatible with code statements in common languages ​​such as C / C++ / Java. However, this method has the following drawbacks: 1. It does not design a dedicated encoding method based on the codeword distribution characteristics of hydraulic sensor signals; 2. It fails to solve the problem of how to separate the data. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a safety fusion source coding method and device for the main longitudinal beam of a hydraulic flatbed trailer, which enables more stable wireless communication and visualization of important safety parameters of the main longitudinal beam of the hydraulic flatbed trailer.

[0006] This invention employs a BLE-based safety fusion source coding method for the main longitudinal beam of a hydraulic flatbed trailer. Based on the characteristics of important safety parameter signals from the hydraulic sensors of the hydraulic flatbed trailer, a base-64 encoding method is proposed to compensate for the low coding rate of Huffman coding for shorter data. Furthermore, a fusion source coding strategy is proposed, with the two complementing each other to achieve more stable wireless communication of important safety parameters of the main longitudinal beam of the hydraulic flatbed trailer.

[0007] The specific technical solution is as follows:

[0008] The safety fusion signal source coding method for the main longitudinal beam of a hydraulic flatbed trailer is based on the characteristics of important safety parameter signals from the hydraulic sensors of the hydraulic flatbed trailer. It employs 64-bit encoding and calculates the code length, followed by Huffman encoding and calculating the code length again. The 64-bit code length is compared with the Huffman code length. If the 64-bit code length is less than or equal to the Huffman code length, the 64-bit code is output; otherwise, the Huffman code is output.

[0009] The specific method and algorithm for base-64 encoding are as follows:

[0010] n 64进制 =-(n 10进制 +32)n 10进制 <64

[0011] When the ADC sample value is less than 64, the corresponding 64-based number is only one character, so it is necessary to directly take the opposite number of this character.

[0012]

[0013] When the ADC sample value is greater than or equal to 64 and less than 4096, the corresponding base-64 number is 2 characters. The lower-order character of the corresponding base-64 number needs to be reversed.

[0014] The specific method of Huffman coding includes the following steps:

[0015] (1) First, count the number of codeword types appearing in the data packet.

[0016] To count the number of codeword types, we can transform the problem into counting the number of times an element appears repeatedly in a data packet. Using two pointers, we compare each element in the data packet sequentially from beginning to end. If a match is found, we count the repetition and then exit the second pointer's traversal. Finally, we return the difference between the number of elements in the data packet and the number of repetitions, thus completing the count of codeword types.

[0017] (2) Count the occurrences of each element in the data packet. Sort the elements by weight from largest to smallest and assign a number to each counted codeword. Compare the weights of each codeword pairwise, take the codeword with the largest weight, assign it the largest number, remove the codeword with the largest number, and repeat the pairwise comparison to take the codeword with the largest weight and assign it the next largest number. In this way, the sorting is completed when all weights have been removed.

[0018] (3) Using dynamic encoding requires a second traversal of the data to determine the static encoding through exhaustive search.

[0019] (4) A total of three parts of data need to be output in sequence: the length of the input data codeword table, the input data codeword table, and the encoding of the input data.

[0020] Before encoding, list the codewords in ascending order of frequency. Prefix the codeword table with the codeword table length to facilitate decoding by separating the codeword table from the encoding.

[0021] The encoding table needs to be encoded into one character every 8 bits, and the code word table length and code word table are concatenated beforehand to output the string that will be used for wireless communication.

[0022] A safety fusion source coding device for the main longitudinal beam of a hydraulic flatbed trailer, comprising an encoding device and a decoding device;

[0023] The encoding device uses the ESP32-C3 chip as the main control core, has a 2.4GHz radio frequency, and uses BLE low-power Bluetooth to communicate wirelessly with the decoding device;

[0024] The decoding device uses the RK3399 chip as the main control core and is based on the Android system. Attached Figure Description

[0025] Figure 1 This is a flowchart of the fusion source coding method of the present invention;

[0026] Figure 2 This is a flowchart of the 64-base encoding of the present invention.

[0027] Figure 3 This is a flowchart of the fast Huffman coding of the present invention.

[0028] Figure 4 This is a schematic diagram of the device structure of the present invention. Detailed Implementation

[0029] The specific technical solutions of the present invention will be described with reference to the embodiments.

[0030] like Figure 1The flowchart shown illustrates a BLE-based safety fusion source coding method for the main longitudinal beam of a hydraulic flatbed trailer. Based on the characteristics of important safety parameter signals from the hydraulic sensors of the hydraulic flatbed trailer, a 64-bit encoding method is used, and the code length is calculated. Then, Huffman encoding is used, and the code length is calculated again. The 64-bit code length is compared with the Huffman code length. If the 64-bit code length is less than or equal to the Huffman code length, the 64-bit code is output; otherwise, the Huffman code is output.

[0031] This code is easy to implement using high-level computer languages ​​such as C or Java. It is fast to encode, has low computational complexity, and is suitable for operation on relatively low-performance chips.

[0032] Depending on the trailer axle load (100–350 kN), the vibration frequency ranges from 10 to 30 Hz. According to the Nyquist sampling theorem, to recover the original signal from a discrete sequence without distortion, the sampling frequency must be at least twice the maximum frequency of the signal. To ensure signal accuracy, it is generally desirable for the sampling frequency to be at least five times the maximum frequency of the signal.

[0033] F s >5f max

[0034] This means that it needs to wirelessly transmit 5 times × 30Hz × 3 channels of hydraulic sensor data per second. Since the unencoded data is 5 bytes, it needs to transmit 2250 bytes of data per second. Actual testing showed that the ESP32-C3 can send 4 data packets per second, and each data packet requires 562.5 bytes of data. This exceeds the 512-byte MTU (Maximum Transmission Unit) limit of BLE Low Energy Bluetooth.

[0035] To address the problem that communication without source coding can cause congestion and compromise the real-time performance of wireless monitoring, and considering that the data only contains 11 codewords, this invention proposes a data encoding method that combines base-64 encoding with fast Huffman coding.

[0036] 64-bit encoding:

[0037] Huffman coding requires appending the code table string to the encoded data, which diminishes its efficiency advantage when dealing with small amounts of data. Therefore, a base-64 encoding method is proposed, complementing Huffman coding. The base-64 encoding flowchart is shown below. Figure 2 As shown.

[0038] The principle of base-64 encoding is as follows:

[0039] A char array is used to hold hydraulic data acquired by the hydraulic sensor from the 13-bit ADC. The data consists of integers ranging from 0 to 4095, separated by commas. Wireless communication is achieved via a serial port simulated by Bluetooth. The char type ranges from -128 to 127; however, only the 10 ASCII codes from '0' to '9' are used, leaving the other 246 char types unused, resulting in data encoding redundancy.

[0040] ASCII is a character set with 128 elements, including the numbers 0-9, uppercase and lowercase English letters, commonly used English symbols, and control characters such as newline, carriage return, and tab. Each character corresponds to a code point, which maps to a number ranging from decimal 0 to 127. The maximum code point value of ASCII is 127, requiring only 7 bits to represent all characters.

[0041] However, when mainstream computers read and write character sequences, whether it's the `char` type in C or the `byte` type in Java used on Android, they use bytes (8 bits) as the basic unit. 8 bits can represent decimal values ​​from -128 to 127. However, there is no corresponding character mapping for negative numbers from -128 to -1. In engineering applications, the 8th bit is often directly padded with 0, resulting in a waste of one bit.

[0042] The 64-base encoding strategy is as follows:

[0043] To improve the maximum data transmission rate, it is necessary to address the underutilization of ASCII codes. A C-based encoding strategy for 64-ary data compression and segmentation was designed and implemented, along with a corresponding Java-based decoding strategy for the Android platform. This strategy utilizes the underutilized negative number range of ASCII codes and the 64 positive number ranges.

[0044] 64 code points are selected from the positive number range of ASCII code to represent base-64 numbers. However, the following situations should be avoided:

[0045] (1) The character corresponding to code point 0 is interpreted as an empty character. In C language, the char type array uses the '\0' empty character to indicate its end, which will cause the character array to end prematurely, thus producing unexpected errors. This should be avoided.

[0046] (2) The characters corresponding to code points 1 to 31 are interpreted as “newline”, “carriage return”, etc., which can cause ambiguity and should be avoided.

[0047] (3) The character corresponding to code point 127 is interpreted as "delete", which is ambiguous and should be avoided.

[0048] After discarding the above code points, the range of code points that can be used to represent base-64 numbers is 32 to 126, a total of 95 code points. Code points 32 (”) to 95 (′_′) are used to represent base-64 numbers.

[0049] ASCII code only needs 7 bits to represent all characters, so its unused highest bit is defined as the data separator bit. That is, the unused negative number range is used to represent the separation position of adjacent ADC sampled data.

[0050] The 64-base encoding algorithm is as follows:

[0051] The specific algorithm implementation is as follows:

[0052] n 64进制 =-(n 10进制 +32)n 10进制 <64

[0053] When the ADC sample value is less than 64, the corresponding 64-based number is only one character, so it is necessary to directly take the opposite number of this character.

[0054]

[0055] When the ADC sample value is greater than or equal to 64 and less than 4096, the corresponding base-64 number is 2 characters. The lower-order character of the corresponding base-64 number needs to be reversed.

[0056] in It is a random character with an ASCII code of -128 to -1, used to contain data information while also representing a separator between the current data and the next data.

[0057] 64-base encoding result:

[0058] Using this encoding strategy, the value range of the char type is fully utilized. Each sensor data is compressed from five bytes of "4095," (64~4095) to... Two bytes, "63," (0~63) three bytes compressed to With one byte, the number of data bytes is reduced to three-fifths to one-third of the original.

[0059] Fast Huffman Coding Algorithm:

[0060] Huffman coding is the minimum redundancy coding for data. Because it has the shortest average code length, it is considered the optimal communication coding. [9] .

[0061] In communication, different arrangements of 0s and 1s can be used to represent different characters, a process called binary encoding. If each character appears with a different frequency, binary encoding of varying lengths can be used. Characters with higher frequency are assigned shorter encodings, while those with higher frequency are assigned longer encodings, thus minimizing the overall code length of the characters.

[0062] While minimizing code length, it's also crucial to avoid multiple interpretations; that is, the code for any character cannot be a prefix of the code for another character, such as encoding 0 as a prefix of encoding 01. Therefore, a binary tree can be used to design binary prefix codes. Using the frequency of each character as the weight, a Huffman tree can be designed where each left branch is 0 and each right branch is 1, resulting in a coding table composed of the codes for all leaf nodes. The flowchart for Fast Huffman Coding is shown below. Figure 3 As shown.

[0063] Specifically, it includes:

[0064] (1) Statistics

[0065] In wireless transmission, data packets are sent as strings. The 11 codewords (0-9 and comma) do not all appear in every data packet. If all 11 codewords are assigned encoding, it cannot be guaranteed that a complete binary tree can be constructed for each data packet, resulting in encoding redundancy. Therefore, it is necessary to first count the number of codeword types appearing in the data packets.

[0066] To count the number of codeword types, we can transform the problem into counting the number of times elements appear repeatedly in a data packet. We can use two pointers to compare each element in the data packet sequentially from beginning to end. If a match is found, we count the repetition and then exit the second pointer's traversal. Finally, we simply return the difference between the number of elements in the data packet and the number of repetitions to complete the count of codeword types.

[0067] (2) Sorting

[0068] Secondly, it is necessary to count the occurrences of each element in the data packet. Then, sort them according to their weights from largest to smallest, and assign a number to each counted codeword.

[0069] The design concept is as follows: compare the weights of each codeword pairwise, take the codeword with the highest weight, assign it the highest sequence number, remove the codeword with the highest sequence number, and then compare the weights pairwise again, take the codeword with the highest weight, and assign it the second highest sequence number. In this way, when all weights have been removed, the sorting is complete.

[0070] (3) Code table

[0071] The mainstream Huffman coding schemes include dynamic coding, static coding, and fixed code table schemes.

[0072] (a) Dynamic coding requires constructing a weighted Huffman tree, and the encoding of each codeword needs to be determined based on the Huffman tree above it. Although it can achieve the best coding efficiency, it requires repeatedly constructing the Huffman tree and repeatedly calculating the encoding corresponding to each codeword based on the codeword distribution of each data packet, which consumes a lot of resources.

[0073] (b) Static coding does not require constructing a Huffman tree. Instead, it exhaustively enumerates an encoding table based on the characteristics of the Huffman tree. The encoding table is then assigned encodings of varying lengths from high to low frequency for each character, thus obtaining the Huffman code for the string. Static coding avoids the repeated process of constructing the Huffman tree, resulting in lower resource consumption. Due to its faster encoding speed, it is also known as Fast Huffman Coding.

[0074] (c) Fixed code tables also do not require the construction of Huffman trees or the repeated calculation of the encoding corresponding to each codeword. Instead, each codeword corresponds to a fixed encoding. It consumes the least resources, and no codeword table needs to be transmitted during communication, only the encoding needs to be transmitted. However, because it lacks statistics on codeword frequency, its encoding efficiency is higher than dynamic and static encoding only in a few cases, such as when the data volume is small, there are many types of codewords, and the codeword frequency is balanced.

[0075] Hydraulic sensor data consists of 11 codewords, a relatively small number with a maximum code length of only 6 bits. Considering the algorithm is being run on a relatively low-performance chip, dynamic encoding would require a second data traversal, resulting in high computational time complexity. To minimize resource consumption and algorithm computation time, a static encoding approach can be used to determine the encoding through exhaustive search.

[0076] (4) Output

[0077] The data needs to be output in three parts in sequence: the length of the input data codeword table, the input data codeword table, and the encoding of the input data.

[0078] Since the frequency of each codeword varies with each data packet transmission, it is necessary to list the codewords in ascending order of frequency before encoding. Furthermore, because the total number of codeword types also varies, a codeword table length needs to be prefixed to facilitate the separation of the codeword table from the encoding during decoding.

[0079] The encoding table needs to be encoded into one character every 8 bits, and the code word table length and code word table are concatenated beforehand to output the string that will be used for wireless communication.

[0080] The present invention also provides a safety fusion source encoding device for the main longitudinal beam of a hydraulic flatbed trailer, including an encoding device and a decoding device;

[0081] To meet the requirements of hydraulic signal acquisition and wireless communication for a specific model of hydraulic flatbed trailer (approximately 30 meters long), an encoding device was designed using the ESP32-C3 chip as the main control core. This device possesses sufficient hardware performance, low power consumption, and 2.4GHz radio frequency capability, and communicates wirelessly with the decoding device using BLE low-power Bluetooth.

[0082] To visualize key safety parameters of the main longitudinal beam of a hydraulic flatbed trailer, an RK3399 chip was used as the main control core, and a decoding device based on the Android system was designed. A communication diagram between the encoding and decoding devices is shown below. Figure 4 As shown.

Claims

1. A method for secure fusion source coding of hydraulic flatbed trailer main longitudinal beam, characterized in that, According to the characteristics of the important safety parameter signals of the hydraulic sensor of the hydraulic flatbed trailer, 64-ary coding and code length statistics are adopted, and then Huffman coding and code length statistics are adopted; the code length of the 64-ary coding is compared with the code length of the Huffman coding, if the code length of the 64-ary coding is less than or equal to the code length of the Huffman coding, the 64-ary coding is output, otherwise the Huffman coding is output; The specific method of the 64-ary coding is as follows: ； When the ADC sampling value is less than 64, the 64-ary number corresponding to the ADC sampling value is only one character, so the opposite number of the character is directly taken; ； When the ADC sampling value is greater than or equal to 64 and less than 4096, the 64-ary number corresponding to the ADC sampling value is two characters, and the opposite number of the low character of the 64-ary number is taken.

2. The method of claim 1, wherein, The specific method of the Huffman coding includes the following steps: (1) The number of code word types in the data packet is counted first; If the number of code word types is counted, the problem can be converted into counting the number of repeated elements in the data packet; two pointers are used to compare each element of the data packet from front to back, if the elements match, the repeated number is recorded once, and then the second pointer is jumped out of the traversal; finally, the difference between the number of data packet elements and the number of repeated elements is returned, which can complete the counting of the number of code word types; (2) The number of occurrences of each element in the data packet is counted, and the weights are sorted from large to small, and each counted code word is given a number; the weights of each code word are compared with each other, and the code word with the maximum weight is taken, and the maximum sequence number is assigned; the weight of the maximum sequence number is removed, and the code word with the maximum weight is taken again, and the second largest sequence number is assigned; in this way, when the weights are all removed, the sorting is completed; (3) Dynamic coding needs to traverse the data twice, and determine the static coding by exhaustion; (4) A total of three parts of data need to be output in turn: input data code word table length, input data code word table, and coding of input data; Before coding, list the code words from low to high according to the frequency of occurrence; prefix a code word table length in front of the code word table to facilitate the separation of the code word table and the code during decoding; The coding table needs to be coded as a character every 8 bits, and the code word table length and the code word table are concatenated in front of it, which can output the string used for wireless communication.

3. A safety fusion source coding device for a hydraulic flatbed trailer main longitudinal beam, characterized by, The hydraulic flatbed trailer main longitudinal beam safety fusion source coding method of claim 1 or 2 is used to realize the hydraulic flatbed trailer main longitudinal beam safety fusion source coding method of claim 1 or 2; It includes a coding device and a decoding device; The coding device uses an ESP32-C3 chip as the main control core, is provided with a 2.4GHz radio frequency, and uses BLE low-power Bluetooth to wirelessly communicate with the decoding device; The decoding device uses an RK3399 chip as the main control core and is based on an Android system.

Images