Vehicle-mounted controller data packet sending method and receiving method
By generating data packets in a specific format and using a CRC check algorithm, the problem of data packet identification and integrity between vehicle controllers is solved, achieving efficient data transmission.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- DONGFENG MOTOR GRP
- Filing Date
- 2023-11-21
- Publication Date
- 2026-07-21
AI Technical Summary
In the field of low-cost communication protocol applications, data packets between vehicle controllers cannot effectively identify frame headers, frame tails, and the length of the complete data packet, and there are data mutation errors, making it difficult to extract data packets correctly.
By generating data packets with a specific format and inserting checksums into the data packets, the integrity of the data packets is ensured by using the CRC checksum algorithm, enabling rapid extraction and automatic removal of corrupted data.
It enables rapid extraction of complete data packets under high throughput conditions, improves the real-time performance and throughput of data transmission, and meets the high-speed, low-cost communication requirements of vehicle ECUs.
Smart Images

Figure CN117544691B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data transmission, specifically relating to a method for sending and receiving data packets from an onboard controller. Background Technology
[0002] In the field of data transmission and reception between automotive ECUs, if the two or more communicating parties have multiple layers of the OSI model, there is generally no difficulty in data parsing, such as with the CAN bus.
[0003] The CAN bus transceiver can automatically identify the frame header and frame end, and automatically identify the integrity of the data.
[0004] However, for low-cost communication protocol applications, such as communication between motor controller signal boards and power boards, only the OSI physical layer and TTL serial port protocol are typically used. All data in this protocol is represented as ordinary bytes and lacks the automatic identification function of the OSI link layer. Therefore, it faces the following application challenges:
[0005] 1. When multiple data packets accumulate together, it becomes impossible to effectively identify the frame header, frame tail, and the length of the complete data packet. For example, if each data packet is 10 bytes, the receive buffer has 2000 bytes, and it contains corrupted data, it is very difficult to extract all the complete data packets.
[0006] 2. Abrupt errors during data transmission and reception. Summary of the Invention
[0007] The purpose of this invention is to provide a method for transmitting and receiving data packets from an on-board controller, which can ensure rapid extraction of data packets under high throughput conditions and automatically remove corrupted data.
[0008] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:
[0009] A method for transmitting data packets from an onboard controller.
[0010] Generate a first data packet, wherein the first data packet contains N bytes, N≤127;
[0011] Extract the high 4 bits and low 4 bits of each byte in the first data packet, multiply them by 16 to form 2N new bytes, and arrange them in order to form the second data packet;
[0012] Insert a byte with a value of 2N+1 before the first byte of the second data packet to form the third data packet;
[0013] The lower four bits of the last byte in the third data packet are assigned the value 2 to form the fourth data packet;
[0014] The first verification algorithm is executed in the fourth data packet. The specific steps of the first verification algorithm are as follows: except for the inserted byte with a value of 2N+1, CRC check is performed on the 1st to 2Nth bytes to generate a 1-byte check code. The high four bits and low four bits of the check code byte are multiplied by 16 respectively to form 2 bytes, which are added to the end of the fourth data packet to form the fifth data packet. The fifth data packet is sent out periodically.
[0015] A signal transmitting end for an on-board controller is also provided, including a signal transmitting ECU, which is invoked to complete the on-board controller data packet transmission method described above.
[0016] A method for receiving vehicle controller data packets is also provided, wherein a fifth data packet is generated by the vehicle controller data packet sending method described above; this receiving method includes:
[0017] It periodically receives the fifth data packet and stores it in its own buffer;
[0018] Read the byte data in its own buffer in sequence. When the least significant bit of the current byte is detected to be 1, it is considered that a frame header has been detected. The high 7 bits of the current byte are taken out and multiplied by 2. The number of bytes obtained is 2N.
[0019] The second verification algorithm is executed. The specific steps of the second verification algorithm are as follows: read 2N consecutive bytes, and when the lowest two bits of the last byte are 2, continue to read 2 bytes and extract the high four bits of these 2 bytes to form the high four bits and low four bits of a new byte. Use the new byte as the first CRC check code. At this time, the second verification algorithm ends.
[0020] The first and second verification algorithms are executed sequentially on the received 2N bytes to obtain the second CRC checksum. The first and second CRC checksums are compared. If they are equal, the data packet is considered complete and correct.
[0021] It also includes the following steps: if 2N consecutive bytes have not been read, then continue scanning and reading.
[0022] The process also includes the following steps: read 2N consecutive bytes and if the least significant two bits of the last byte are not 2, then consider the consecutive byte data to be corrupted, discard the consecutive byte data, and wait to detect the next byte with the least significant bit 1.
[0023] A signal receiving terminal for an on-board controller is also provided, including a signal receiving ECU, which is invoked to complete the on-board controller data packet receiving method as described above.
[0024] It also includes: if the signal receiver has not read 2N consecutive bytes, then continue scanning and reading.
[0025] It also includes: when the signal receiver reads 2N consecutive bytes and the least significant two bits of the last byte are not 2, the data segment is considered corrupted, the segment is discarded, and the receiver waits to detect the next byte with the least significant bit 1.
[0026] A vehicle is also provided, including a signal transmitting end of an on-board controller as described above and a signal receiving end of an on-board controller as described in any of the preceding claims.
[0027] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0028] This invention can effectively extract complete data frames from the buffer queue, significantly improving the data throughput and real-time performance of traditional serial communication, eliminating the need for a "request-response" model. It can also enable low-cost serial communication to achieve performance levels comparable to real-time buses, meeting the high-speed, low-cost communication requirements of vehicle ECUs. Attached Figure Description
[0029] Figure 1 This is a flowchart illustrating the data packet transmission method for the vehicle controller in an embodiment of the present invention.
[0030] Figure 2 This is a flowchart illustrating the data packet receiving method for the vehicle controller in an embodiment of the present invention. Detailed Implementation
[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.
[0032] The technical solution of this invention is as follows:
[0033] Example 1:
[0034] like Figure 1 As shown, a method for transmitting data packets from an onboard controller is described.
[0035] Generate a first data packet, wherein the first data packet contains N bytes, N≤127;
[0036] Extract the high 4 bits and low 4 bits of each byte in the first data packet, multiply them by 16 to form 2N new bytes, and arrange them in order to form the second data packet;
[0037] Insert a byte with a value of 2N+1 before the first byte of the second data packet to form the third data packet;
[0038] The lower four bits of the last byte in the third data packet are assigned the value 2 to form the fourth data packet;
[0039] The first verification algorithm is executed in the fourth data packet. The specific steps of the first verification algorithm are as follows: except for the inserted byte with a value of 2N+1, CRC check is performed on the 1st to 2Nth bytes to generate a 1-byte check code. The high four bits and low four bits of the check code byte are multiplied by 16 respectively to form 2 bytes, which are added to the end of the fourth data packet to form the fifth data packet. The fifth data packet is sent out periodically.
[0040] And a signal transmitting end of an in-vehicle controller, including a signal transmitting ECU, wherein the signal transmitting ECU is invoked to complete the above-described in-vehicle controller data packet transmission method.
[0041] Example 2:
[0042] like Figure 2 As shown, a method for receiving vehicle controller data packets generates a fifth data packet using the vehicle controller data packet sending method described in Embodiment 1; this receiving method includes:
[0043] It periodically receives the fifth data packet and stores it in its own buffer;
[0044] Read the byte data in its own buffer in sequence. When the least significant bit of the current byte is detected to be 1, it is considered that a frame header has been detected. The high 7 bits of the current byte are taken out and multiplied by 2. The number of bytes obtained is 2N.
[0045] The second verification algorithm is executed. The specific steps of the second verification algorithm are as follows: read 2N consecutive bytes, and when the lowest two bits of the last byte are 2, continue to read 2 bytes and extract the high four bits of these 2 bytes to form the high four bits and low four bits of a new byte. Use the new byte as the first CRC check code. At this time, the second verification algorithm ends.
[0046] The first and second verification algorithms are executed sequentially on the received 2N bytes to obtain the second CRC checksum. The first and second CRC checksums are compared. If they are equal, the data packet is considered complete and correct.
[0047] It also includes the following steps: if 2N consecutive bytes have not been read, then continue scanning and reading.
[0048] The process also includes the following steps: read 2N consecutive bytes and if the least significant two bits of the last byte are not 2, then consider the consecutive byte data to be corrupted, discard the consecutive byte data, and wait to detect the next byte with the least significant bit 1.
[0049] And a signal receiving end for an on-board controller, including a signal receiving ECU, which is invoked to complete the on-board controller data packet receiving method as described above.
[0050] It also includes: if the signal receiver has not read 2N consecutive bytes, then continue scanning and reading.
[0051] It also includes: when the signal receiver reads 2N consecutive bytes and the least significant two bits of the last byte are not 2, the data segment is considered corrupted, the segment is discarded, and the receiver waits to detect the next byte with the least significant bit 1.
[0052] The specific implementation steps are as follows:
[0053] Assume the signal receiving end (signal receiving ECU, specifically the motor controller signal board) is responsible for receiving, and the signal sending end (signal sending ECU, specifically the motor controller power board) is responsible for sending, with one-way communication.
[0054] For the signal transmitter, assume that the first data packet K1 sent by the signal transmitter contains N bytes, where N≤127.
[0055] The first step is to extract the high 4 bits and low 4 bits of each of the N bytes in K1, and then multiply them by 16 to form 2N new bytes, which are called the second data packet K2.
[0056] The second step is to insert a new byte with a value of N*2+1 before the first byte of K2, which is called the third data packet K3.
[0057] The third step is to assign the value 2 to the lower four bits of the last byte of K3, which is called the fourth data packet K4.
[0058] The fourth step involves performing a CRC check on bytes 1 (indexed from 0) to 2N of the new K4, generating a one-byte checksum. The high four bits and low four bits of this checksum byte are then multiplied by 16 to form two byte arrays, which are appended to the end of K4. This processed byte array is called the fifth data packet, K5.
[0059] The signal transmitter periodically sends K5.
[0060] For the signal receiver, it needs to parse the data in its own buffer. Generally, data will continuously be coming into the buffer.
[0061] The fifth step is for the signal receiver to read the bytes of data in its own buffer one by one. If the least significant bit of the current byte is 1, it is considered that a frame header has been detected. The high 7 bits of the byte are taken out and multiplied by 2, which is the number of bytes of data packet sent by the signal sender (excluding CRC check bytes). The value of this value is set to 2N.
[0062] The sixth step is for the signal receiver to read 2N consecutive data bytes and check that the lower four bits of the last byte in the 2N byte array are 2. If 2N bytes have not been read, the scanning continues.
[0063] If the last byte of the received 2N-byte array has a lower four-bit value that is not equal to 2, the data is considered corrupted and discarded entirely, waiting for the next byte (frame header) with the lowest bit set to 1.
[0064] If the signal receiver successfully receives a byte array of 2N consecutive bytes, and the lowest two bits of the last byte are 2, then the signal receiver continues to read two more bytes, extracts the high four bits of the first and second bytes respectively, and makes them the high four bits and low four bits of a new byte. This new byte is the first CRC checksum M1 received by the signal receiver from the signal sender.
[0065] The signal receiver uses the same verification algorithm as the signal transmitter to calculate the second CRC check code M2 for the 2N bytes and compares it with the above M1. If they are equal, the data packet is considered complete and correct.
[0066] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for transmitting data packets from an on-board controller, characterized in that, Generate a first data packet, wherein the first data packet contains N bytes, N≤127; Extract the high 4 bits and low 4 bits of each byte in the first data packet, multiply them by 16 to form 2N new bytes, and arrange them in order to form the second data packet; Insert a byte with a value of 2N+1 before the first byte of the second data packet to form the third data packet; The lower four bits of the last byte in the third data packet are assigned the value 2 to form the fourth data packet; The first verification algorithm is executed in the fourth data packet. The specific steps of the first verification algorithm are as follows: except for the inserted byte with a value of 2N+1, CRC check is performed on the 1st to 2Nth bytes to generate a 1-byte check code. The high four bits and low four bits of the check code byte are multiplied by 16 respectively to form 2 bytes, which are added to the end of the fourth data packet to form the fifth data packet. The fifth data packet is sent out periodically.
2. A signal transmitting end for an on-board controller, characterized in that, It includes a signal transmitting ECU, which is invoked to complete the vehicle controller data packet transmission method as described in claim 1.
3. A method for receiving data packets from an on-board controller, characterized in that, The fifth data packet is generated using the vehicle controller data packet transmission method as described in claim 1; the receiving method includes: It periodically receives the fifth data packet and stores it in its own buffer; Read the byte data in its own buffer in sequence. When the least significant bit of the current byte is detected to be 1, it is considered that a frame header has been detected. The high 7 bits of the current byte are taken out and multiplied by 2. The number of bytes obtained is 2N. The second verification algorithm is executed. The specific steps of the second verification algorithm are as follows: read 2N consecutive bytes, and when the lowest two bits of the last byte are 2, continue to read 2 bytes and extract the high four bits of these 2 bytes to form the high four bits and low four bits of a new byte. Use the new byte as the first CRC check code. At this time, the second verification algorithm ends. The first and second verification algorithms are executed sequentially on the received 2N bytes to obtain the second CRC checksum. The first and second CRC checksums are compared. If they are equal, the data packet is considered complete and correct.
4. The method for receiving data packets from an on-board controller according to claim 3, characterized in that, It also includes the following steps: If 2N consecutive bytes have not been read, the scanning and reading will continue.
5. The method for receiving data packets from an on-board controller according to claim 3, characterized in that, It also includes the following steps: If 2N consecutive bytes are read and the least significant two bits of the last byte are not 2, then the consecutive byte data is considered corrupted, the consecutive bytes are discarded, and the system waits to detect the next byte with the least significant bit set to 1.
6. A signal receiver for an on-board controller, characterized in that, It includes a signal receiving ECU, which is invoked to complete the vehicle controller data packet receiving method as described in claim 3.
7. The signal receiving terminal of an on-board controller according to claim 6, characterized in that, Also includes: If the signal receiver fails to read 2N consecutive bytes, it will continue scanning and reading.
8. The signal receiving terminal of an on-board controller according to claim 6, characterized in that, Also includes: When the signal receiver reads 2N consecutive bytes and the least significant two bits of the last byte are not 2, it considers the consecutive byte data to be corrupted, discards the consecutive bytes, and waits to detect the next byte with the least significant bit being 1.
9. A vehicle, characterized in that, It includes a signal transmitting end of an on-board controller as described in claim 2 and a signal receiving end of an on-board controller as described in any one of claims 6-8.