CN112737739A - Method for multi-packet communication between two devices - Google Patents
Method for multi-packet communication between two devices Download PDFInfo
- Publication number
- CN112737739A CN112737739A CN202011566447.7A CN202011566447A CN112737739A CN 112737739 A CN112737739 A CN 112737739A CN 202011566447 A CN202011566447 A CN 202011566447A CN 112737739 A CN112737739 A CN 112737739A
- Authority
- CN
- China
- Prior art keywords
- frame
- data
- sending
- response
- entering
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1848—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/189—Transmission or retransmission of more than one copy of a message
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Abstract
The invention discloses a method for multi-packet communication between two devices, which comprises the steps of sending an instruction frame, sending a data frame and sending a response frame between the two devices; the instruction frame sending process is that A1 and two devices establish spp connection through Bluetooth; a2, a sender initializes the sending times of the same instruction frame to 0, determines the value of cla and ins according to the function to be realized, determines the length of the instruction frame to be sent, defaults serialNo to 0, starts FrameSeq frame sequence number to 0, fixes the total number of FrameSum frames to 1, and adds a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41; a3, calculating the frame header and the data bits of the instruction frame by modBudCRC16 to obtain CRC bits and the like. The advantages are that: the problem that when the Bluetooth SPP communication slave equipment responds to the master equipment, the master equipment has long data receiving waiting time, so that the interactive communication speed is slowed down in the using process is solved, the data volume sent by the master equipment at each time is increased through a self-defined communication protocol, and the response times of the slave equipment are reduced to improve the overall speed.
Description
Technical Field
The invention relates to the technical field of Bluetooth wireless communication, in particular to a method for multi-packet communication between two devices.
Background
Along with the arrival of intelligent science and technology wave, more and more electronic equipment has appeared in the life, and intelligent home equipment is more and more, and wherein many equipment have all used wireless communication technique, through bluetooth or wifi communication, make home equipment realize intelligent control. However, when the current bluetooth SPP communication slave device answers the master device, the master device has a long waiting time for receiving data, which results in a slow interactive communication rate during use.
Disclosure of Invention
The present invention is directed to a method for multi-packet communication between two devices, so as to solve the aforementioned problems in the prior art.
In order to achieve the purpose, the technical scheme adopted by the invention is as follows:
a method for multi-packet communication between two devices comprises the steps of sending an instruction frame, sending a data frame and sending a response frame between the two devices;
the command frame is sent in the process that,
a1, two devices establish spp connection through Bluetooth;
a2, a sender initializes the sending times of the same instruction frame to 0, determines the value of cla and ins according to the function to be realized, determines the length of the instruction frame to be sent, defaults serialNo to 0, starts FrameSeq frame sequence number to 0, fixes the total number of FrameSum frames to 1, and adds a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41; a3, performing modBudCRC16 calculation on the frame header and the data bits of the instruction frame to obtain CRC bits;
a4, sending an instruction frame through Bluetooth; clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
a5, waiting for the response data of the receiver, if the waiting time is over or the response frame is not in accordance with the requirement, if yes, judging whether the retransmission times is more than or equal to the first set times; otherwise, entering A6; if the retransmission times are larger than or equal to the first set times, quitting the transmission, and checking whether the Bluetooth connection is normal; otherwise, returning to A3;
a6, if the receiver receives the response data, checking whether the frame header is 0x 20; otherwise, returning to A5; if the frame header is 0x20, go to A7; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a7, judging whether the CRC passes, and if so, entering A8; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a8, checking whether the instruction received by the receiver is correct, and if so, entering A9; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a9, checking whether cla and ins of the sending frame and the response frame are consistent, if so, indicating that the sending is successful, returning to A1, and sending the next instruction frame by the sender; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
the data frame is sent in the process of,
b1, establishing spp connection between the two devices through Bluetooth;
b2, a sender initializes the sending times of the same data frame to 0, as the data frame is, cla is 0x02, ins is 0x01, the length len of the data frame to be sent is determined, serialNo is defaulted to 0, the starting of the FrameSeq frame number is 0, the total number of FrameSum frames is added with a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41;
b3, determining the total frame number FrameSum and the total data length, and if the total data length can be divided 990 completely, adding 0, and if the total data length cannot be divided completely, adding 1; when the data cannot be divided completely, the remaining data is less than 990 as 1 frame;
b4, obtaining data bit corresponding to the data frame according to the frame number of the data frame to be sent;
b5, performing modBudCRC16 calculation on the frame header and the data bits of the data frame to obtain CRC bits;
b6, sending data frames through Bluetooth, clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
b7, when the sending frame number is equal to the preset frame number or the last frame is sent, waiting for the response of the receiver; otherwise, continuing to send according to the frame sequence number;
b8, waiting for a response frame, clearing the timeout timer timeout, and starting timing; accumulating the sending times sendcount;
b9, waiting for the response data of the receiving party, if the waiting time is over or the response frame is not in accordance with the requirement, judging whether the retransmission times is more than or equal to a second set time; otherwise, entering B10; if the retransmission times are larger than or equal to the second set times, checking whether the Bluetooth connection is normal; otherwise, returning to B3;
b10, after receiving the response data, checking whether the frame header is 0x20, if so, entering B11; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b11, whether the CRC passes or not, if yes, entering B12; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b12, checking whether the cla and the ins of the sending frame and the response frame are consistent, and if so, entering B13; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b13, checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that all the packet Data are successfully transmitted, and entering B16; otherwise, it indicates that there are data frames which fail to be sent in the packet, and needs to retransmit these failed data frames, and enters B14;
b14, transmitting the failed data frames separately and sequentially;
b15, after the Data frame failed to be sent is sent separately, continuing to wait for the response frame, and checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that the Data of the packet is sent successfully, and entering B16; otherwise, quitting sending and checking the Bluetooth connection condition;
b16, checking whether the serial number of the sent data frame is equal to the total frame number, if yes, indicating that the data frame is completely sent; if not, the rest data frames are continuously sent until all the data frames are sent, and the next packet of data is sent.
The procedure for transmitting the response frame is that,
c1, the receiver receives the data through the Bluetooth communication callback process, and continues to receive after entering the queue;
c2, after taking out the data from the queue, the data processing process enters C3 for analysis;
c3, determining whether the header Tag of the frame data is 0x40 or 0x41, if yes, entering C4, if no, sending an illegal data response frame, namely setting cla to 0x30 and ins to 0x11, and sending the organization data through bluetooth;
c4, judging whether the received frame is a data frame or a command frame according to cla and ins, if cla is 0x20 and ins is 0x01, indicating that the frame is a data frame, and entering C7; otherwise, entering C5 for instruction frame;
c5, judging whether the CRC checks are consistent, if so, entering C6; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c6, returning cla and ins as they are, and returning state according to actual state; calculating CRC organization data and sending the CRC organization data through Bluetooth;
c7, if the received frame is a data frame, the received _ frame + + is accumulated, and the received frame number enters C8;
c8, judging whether the CRC passes, if so, entering C9; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c9, setting rec _ frame _ status of the frame to 1 according to the received _ frame, indicating that the frame is successfully received;
c10, judging whether the received frame number received _ frame is integral multiple of the set number or the last frame, if yes, entering C11; otherwise, returning to C2 for reparation;
c11, when receiving the frame with set number or the last frame, organizing the corresponding rec _ frame _ status [ ] as the data bit and then sending the data bit as the response frame through Bluetooth;
and C12, finishing the transmission of the current response frame and entering the transmission of the next response frame.
Preferably, the first set number of times is 2.
Preferably, the second set number of times is 2.
Preferably, the preset frame number is 5.
Preferably, the set number is 5.
The invention has the beneficial effects that: the problem that when the Bluetooth SPP communication slave equipment responds to the master equipment, the master equipment has long data receiving waiting time, so that the interactive communication speed is slowed down in the using process is solved, the data volume sent by the master equipment at each time is increased through a self-defined communication protocol, and the response times of the slave equipment are reduced to improve the overall speed.
Drawings
FIG. 1 is a diagram illustrating a process of sending an instruction frame according to an embodiment of the present invention;
fig. 2 is a schematic diagram of a data frame transmission process in an embodiment of the present invention;
fig. 3 is a schematic diagram of a transmission process of an acknowledgement frame in an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
In this embodiment, a method for multi-packet communication between two devices is provided, and the following explains the method for multi-packet communication between two devices in detail.
The communication protocol format between the first equipment and the second equipment is as follows:
wherein: the sending frame and the response frame all adopt a small-end mode; the sending frame comprises an instruction frame and a data frame; SerialNo is fixed to 0x 0000.
Instruction frame: and the functions of control inquiry and the like are completed, and the instruction data length is smaller. After each transmission, waiting for a response frame of the receiving end, and transmitting other instructions only after the response result shows success, or retransmitting the command, otherwise, if the retransmission fails twice, showing that the communication is abnormal, and needing to check the Bluetooth communication condition;
data frame: the data frame data amount is large. When in sending, the data is divided into 990Byte as one frame, each 5 frames form one packet, and finally less than 5 frames form one packet according to the actual frame number; sequentially transmitting the packet Data, waiting for a response frame of a receiving end after each packet is transmitted, and judging whether the Data of several frames in the packet are transmitted successfully or not according to Data bits Data [0] -Data [4] in the response frame, wherein the Data [ num ] result Data is 0 to indicate that the corresponding frame is failed to be transmitted and 1 to indicate that the corresponding frame is successfully transmitted; if the Data fails, the frame Data corresponding to num is combined into a packet for continuous retransmission, then the response result is waited again, and whether all the 5 frames are successfully transmitted is judged again according to the Data bits Data [0] -Data [4] in the response frame. After the two transmissions, the frame which is failed to be transmitted still exists, which indicates that the communication is abnormal and needs to be detected.
Second, instruction description
1. Sending frame descriptions
The sending frame comprises an instruction frame and a data frame, and can be distinguished through cla and ins control bits.
The format is as follows:
Tag(1B)+Len(2B)+SerialNo(2B)+FramSeq(2B)+FramSum(2B)+Cla(1B)Ins(1B)+Data+CRC(2B)
see the following Table
| Tag value | Instruction frame, sender sending |
| 0x40 | Instruction frame [ with or without data ]] |
| 0x41 | Retransmission frame [ with or without data ]] |
Tag (1B) sending frame header;
len (2B): a data bit length;
SerialNo (2B): temporarily unused fixed at 0x 0000;
FramSeq (2B): frame number (starting from 0), which is always 0 for command frames; for data frames and the like, frame division processing is needed to obtain the total frame number fre _ total, and the total frame number is transmitted by +1 each time until the data frames are transmitted to (fre _ total-1);
FramSum (2B): the total frame number is 1 for the instruction frame all the time; for the data frame, the frame number is equal to the number fre _ total of the subframe;
cla: the control bit is 8 bits higher;
ins: the control bit is 8 bits lower, and cla + ins completes the control function of the equipment;
data bits, the Data bits of the instruction frame may or may not be present; the data bits of the data frame are data to be transmitted;
CRC16, check bits, a modbus CRC16 check mode is adopted, and a check section: the first 11 bytes + Data bit Data [ ];
2. acknowledgement frame specification
The format is as follows:
Tag(1B)+Len(2B)+SerialNo(2B)+FramSeq(2B)+Cla(1B)+Ins(1B)+State(2B)+Data+CRC(2B)
see the following Table
Tag (1B): response frame header.
Len (2B): the data bit length.
SerialNo (2B): temporarily fixed to 0x 0000.
FramSeq (2B): temporarily fixed to 0x 0000.
Cla (1B): the control bit sent by the sending end is 8 bits high.
Ins (1B): the control bit sent by the sending end is 8 bits high, and the cla and ins of the sending end are returned as they are.
State (2B): and the state bit returns the state to the main equipment, the state [0] represents the report of the abnormal information, and the state [1] represents the instruction receiving condition.
Data [ ]: data bits, if any.
CRC16, check bits, a modbus CRC16 check mode is adopted, and a check section: all data before the CRC bits.
| State[0] | Means of |
| 0x00 | Without error |
| State[1] | Means of |
| 0x00 | Without error |
| 0x01 | The receiving end checks the error or the beginning data of the non-0 x40 after receiving the data |
| 0x02 | Receiving end receiving data overtime |
Description of communication Process
Fig. 1 is a diagram illustrating a transmission process of an instruction frame, specifically,
a1, two devices establish spp connection through Bluetooth;
a2, a sender initializes sendcount to be 0 (the sending times of the same instruction frame), determines the value of cla and ins according to the function to be realized, determines the length of the instruction frame to be sent, defaults serialNo to be 0, starts FrameSeq frame number to be 0, fixes the total number of FrameSum frames to be 1, and adds a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41;
a3, performing modBudCRC16 calculation on the frame header and the data bits of the instruction frame to obtain CRC bits;
a4, sending an instruction frame through Bluetooth; clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
a5, waiting for the response data of the receiving party, if the waiting time is out or the response frame does not meet the requirement, if yes, judging whether the retransmission time is greater than or equal to a first set time (namely sendcount > -2); otherwise, entering A6; if the retransmission times are larger than or equal to the first set times, quitting the transmission, and checking whether the Bluetooth connection is normal; otherwise, returning to A3;
a6, if the receiver receives the response data, checking whether the frame header is 0x 20; otherwise, returning to A5; if the frame header is 0x20, go to A7; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a7, judging whether the CRC passes, and if so, entering A8; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a8, checking whether the instruction received by the receiver is correct, and if so, entering A9; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a9, checking whether cla and ins of the sending frame and the response frame are consistent, if so, indicating that the sending is successful, returning to A1, and sending the next instruction frame by the sender; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
fig. 2 shows a process of transmitting a data frame, specifically,
b1, establishing spp connection between the two devices through Bluetooth;
b2, the sender initializes sendcount to 0 (which is the number of times of sending the same data frame), cla is 0x02 because of the data frame, ins is 0x01, determines the length len of the data frame to be sent (if the length of the data to be sent is greater than 990, len is 990 when the frame is sent; less than 990, len is the actual length), serialNo defaults to 0, the frame sequence number of FrameSeq is 0, the total number of FrameSum frames (the total number of frames is determined according to the total data length to be B3), and adds a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41;
b3, determining the total frame number FrameSum and the total data length% 990+ (1 or 0), if the total data length can be divided by 990, adding 0, and if the total data length cannot be divided by 990, adding 1; when the data cannot be divided completely, the remaining data is less than 990 as 1 frame;
b4, obtaining data bit corresponding to the data frame according to the frame number of the data frame to be sent;
b5, performing modBudCRC16 calculation on the frame header and the data bits of the data frame to obtain CRC bits;
b6, sending data frames through Bluetooth, clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
b7, when the sending frame number is equal to the preset frame number or the last frame is sent, waiting for the response of the receiver; otherwise, continuing to send according to the frame sequence number;
b8, waiting for a response frame, clearing the timeout timer timeout, and starting timing; accumulating the sending times sendcount;
b9, waiting for the response data of the receiving party, if the waiting time is out or the response frame is not satisfactory, judging whether the retransmission time is greater than or equal to a second set time (i.e. sendcount > -2); otherwise, entering B10; if the retransmission times are larger than or equal to the second set times, checking whether the Bluetooth connection is normal; otherwise, returning to B3;
b10, after receiving the response data, checking whether the frame header is 0x20, if so, entering B11; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b11, whether the CRC passes or not, if yes, entering B12; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b12, checking whether the cla and the ins of the sending frame and the response frame are consistent, and if so, entering B13; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b13, checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that all the packet Data are successfully transmitted, and entering B16; otherwise, it indicates that there are data frames which fail to be sent in the packet, and needs to retransmit these failed data frames, and enters B14;
b14, transmitting the failed data frames separately and sequentially;
b15, after the Data frame failed to be sent is sent separately, continuing to wait for the response frame, and checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that the Data of the packet is sent successfully, and entering B16; otherwise, quitting sending and checking the Bluetooth connection condition;
b16, checking whether the serial number of the sent data frame is equal to the total frame number, if yes, indicating that the data frame is completely sent; if not, the rest data frames are continuously sent until all the data frames are sent, and the next packet of data is sent.
Fig. 3 shows a process of transmitting an acknowledgement frame, specifically,
c1, the receiver receives the data through the Bluetooth communication callback process, and continues to receive after entering the queue;
c2, the data processing process takes out the data from the queue and analyzes the data; step C3 begins with a resolution process;
c3, determining whether the header Tag of the frame data is 0x40 or 0x41, if yes, entering C4, if no, sending an illegal data response frame, namely setting cla to 0x30 and ins to 0x11, and sending the organization data through bluetooth;
c4, judging whether the received frame is a data frame or a command frame according to cla and ins, if cla is 0x20 and ins is 0x01, indicating that the frame is a data frame, and entering C7; otherwise, entering C5 for instruction frame;
c5, judging whether the CRC checks are consistent, if so, entering C6; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c6, returning cla and ins as they are, and returning state according to actual state; calculating CRC organization data and sending the CRC organization data through Bluetooth;
c7, if the received frame is a data frame, the received _ frame + + is accumulated, and the received frame number enters C8;
c8, judging whether the CRC passes, if so, entering C9; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c9, setting rec _ frame _ status of the frame to 1 according to the received _ frame, indicating that the frame is successfully received;
c10, judging whether the received frame number received _ frame is integral multiple of the set number or the last frame, if yes, entering C11; otherwise, returning to C2 for reparation;
c11, when receiving the frame with set number or the last frame, organizing the corresponding rec _ frame _ status [ ] as the data bit and then sending the data bit as the response frame through Bluetooth;
and C12, finishing the transmission of the current response frame and entering the transmission of the next response frame.
Fourth, the description of the parameters in the flow
sendcount: the number of times of sending the same instruction;
s _ cla: cla of the sender;
s _ ins: ins of the sender;
r _ cla: cla received by the receiver;
r _ ins: ins received by the receiver;
len: sending a data bit length;
timeout: the sender side waits for receiving ACK overtime timing;
CRC 1: received CRC bits;
CRC 2: CRC bits calculated by the receiver;
total _ frame: the total frame number which needs to be received when receiving the data frame;
now _ frame: receiving the frame number of the current frame when receiving the data frame;
received _ frame: the number of frames received when receiving a data frame;
frame _ head: receiving a frame header Tag of the data;
rec _ frame _ status: when receiving the data frame, the receiver returns the receiving condition of each frame in a packet of data;
sendFram: sending the data frame number when sending the data frame;
FramSeq: sending the data frame number when sending the data frame;
r _ data [ ]: receiving the data of each frame in a packet of data;
err _ num: the number of frames receiving errors in a packet of data;
retrans [ ]: and recording the frame number which needs to be retransmitted due to transmission failure when the data frame is received.
By adopting the technical scheme disclosed by the invention, the following beneficial effects are obtained:
the invention provides a method for multi-packet communication between two devices, which solves the problem that when a Bluetooth SPP communication slave device responds to a master device, the master device has long waiting time for receiving data, so that the interactive communication speed is slowed down in the using process, increases the data volume sent by the master device each time through self-defining a communication protocol, and reduces the response times of the slave device to improve the overall speed.
The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and improvements can be made without departing from the principle of the present invention, and such modifications and improvements should also be considered within the scope of the present invention.
Claims (5)
1. A method for multi-packet communication between two devices is characterized in that: the method comprises the steps of sending an instruction frame, sending a data frame and sending a response frame between two devices;
the command frame is sent in the process that,
a1, two devices establish spp connection through Bluetooth;
a2, a sender initializes the sending times of the same instruction frame to 0, determines the value of cla and ins according to the function to be realized, determines the length of the instruction frame to be sent, defaults serialNo to 0, starts FrameSeq frame sequence number to 0, fixes the total number of FrameSum frames to 1, and adds a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41;
a3, performing modBudCRC16 calculation on the frame header and the data bits of the instruction frame to obtain CRC bits;
a4, sending an instruction frame through Bluetooth; clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
a5, waiting for the response data of the receiver, if the waiting time is over or the response frame is not in accordance with the requirement, if yes, judging whether the retransmission times is more than or equal to the first set times; otherwise, entering A6; if the retransmission times are larger than or equal to the first set times, quitting the transmission, and checking whether the Bluetooth connection is normal; otherwise, returning to A3;
a6, if the receiver receives the response data, checking whether the frame header is 0x 20; otherwise, returning to A5; if the frame header is 0x20, go to A7; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a7, judging whether the CRC passes, and if so, entering A8; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a8, checking whether the instruction received by the receiver is correct, and if so, entering A9; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
a9, checking whether cla and ins of the sending frame and the response frame are consistent, if so, indicating that the sending is successful, returning to A1, and sending the next instruction frame by the sender; otherwise, returning to A5 to judge whether the retransmission times is larger than or equal to the first set times;
the data frame is sent in the process of,
b1, establishing spp connection between the two devices through Bluetooth;
b2, a sender initializes the sending times of the same data frame to 0, as the data frame is, cla is 0x02, ins is 0x01, the length len of the data frame to be sent is determined, serialNo is defaulted to 0, the starting of the FrameSeq frame number is 0, the total number of FrameSum frames is added with a frame header Tag; the first transmission is 0x40 and the retransmission is 0x 41;
b3, determining the total frame number FrameSum and the total data length, and if the total data length can be divided 990 completely, adding 0, and if the total data length cannot be divided completely, adding 1; when the data cannot be divided completely, the remaining data is less than 990 as 1 frame;
b4, obtaining data bit corresponding to the data frame according to the frame number of the data frame to be sent;
b5, performing modBudCRC16 calculation on the frame header and the data bits of the data frame to obtain CRC bits;
b6, sending data frames through Bluetooth, clearing the timeout timer timeout and starting timing; accumulating the sending times sendcount;
b7, when the sending frame number is equal to the preset frame number or the last frame is sent, waiting for the response of the receiver; otherwise, continuing to send according to the frame sequence number;
b8, waiting for a response frame, clearing the timeout timer timeout, and starting timing; accumulating the sending times sendcount;
b9, waiting for the response data of the receiving party, if the waiting time is over or the response frame is not in accordance with the requirement, judging whether the retransmission times is more than or equal to a second set time; otherwise, entering B10; if the retransmission times are larger than or equal to the second set times, checking whether the Bluetooth connection is normal; otherwise, returning to B3;
b10, after receiving the response data, checking whether the frame header is 0x20, if so, entering B11; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b11, whether the CRC passes or not, if yes, entering B12; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b12, checking whether the cla and the ins of the sending frame and the response frame are consistent, and if so, entering B13; otherwise, returning to B9 to judge whether the retransmission times is larger than or equal to the second set times;
b13, checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that all the packet Data are successfully transmitted, and entering B16; otherwise, it indicates that there are data frames which fail to be sent in the packet, and needs to retransmit these failed data frames, and enters B14;
b14, transmitting the failed data frames separately and sequentially;
b15, after the Data frame failed to be sent is sent separately, continuing to wait for the response frame, and checking whether the Data bits r _ Data [0] -r _ Data [4] in the response frame are all 1, if so, indicating that the Data of the packet is sent successfully, and entering B16; otherwise, quitting sending and checking the Bluetooth connection condition;
b16, checking whether the serial number of the sent data frame is equal to the total frame number, if yes, indicating that the data frame is completely sent; if not, the rest data frames are continuously sent until all the data frames are sent, and the next packet of data is sent.
The procedure for transmitting the response frame is that,
c1, the receiver receives the data through the Bluetooth communication callback process, and continues to receive after entering the queue;
c2, after taking out the data from the queue, the data processing process enters C3 for analysis;
c3, determining whether the header Tag of the frame data is 0x40 or 0x41, if yes, entering C4, if no, sending an illegal data response frame, namely setting cla to 0x30 and ins to 0x11, and sending the organization data through bluetooth;
c4, judging whether the received frame is a data frame or a command frame according to cla and ins, if cla is 0x20 and ins is 0x01, indicating that the frame is a data frame, and entering C7; otherwise, entering C5 for instruction frame;
c5, judging whether the CRC checks are consistent, if so, entering C6; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c6, returning cla and ins as they are, and returning state according to actual state; calculating CRC organization data and sending the CRC organization data through Bluetooth;
c7, if the received frame is a data frame, the received _ frame + + is accumulated, and the received frame number enters C8;
c8, judging whether the CRC passes, if so, entering C9; if not, sending a check failure response frame, namely setting cla to be 0x30 and ins to be 0x10, and sending the organization data through Bluetooth;
c9, setting rec _ frame _ status of the frame to 1 according to the received _ frame, indicating that the frame is successfully received;
c10, judging whether the received frame number received _ frame is integral multiple of the set number or the last frame, if yes, entering C11; otherwise, returning to C2 for reparation;
c11, when receiving the frame with set number or the last frame, organizing the corresponding rec _ frame _ status [ ] as the data bit and then sending the data bit as the response frame through Bluetooth;
and C12, finishing the transmission of the current response frame and entering the transmission of the next response frame.
2. The method of claim 1, wherein the method further comprises: the first set number of times is 2.
3. The method of claim 1, wherein the method further comprises: the second set number of times is 2.
4. The method of claim 1, wherein the method further comprises: the preset frame number is 5.
5. The method of claim 1, wherein the method further comprises: the set number is 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011566447.7A CN112737739B (en) | 2020-12-25 | 2020-12-25 | Method for multi-packet communication between two devices |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011566447.7A CN112737739B (en) | 2020-12-25 | 2020-12-25 | Method for multi-packet communication between two devices |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112737739A true CN112737739A (en) | 2021-04-30 |
| CN112737739B CN112737739B (en) | 2022-08-23 |
Family
ID=75616474
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011566447.7A Active CN112737739B (en) | 2020-12-25 | 2020-12-25 | Method for multi-packet communication between two devices |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112737739B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113645600A (en) * | 2021-08-13 | 2021-11-12 | Oppo广东移动通信有限公司 | Data transmission method, device, terminal and storage medium |
| CN113721498A (en) * | 2021-07-15 | 2021-11-30 | 青岛英泰信息技术有限公司 | FreeRTOS-based instruction interaction control system and method thereof |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160117493A1 (en) * | 2013-04-27 | 2016-04-28 | Feitian Technologies Co., Ltd. | Working method of smart key device |
| CN107454563A (en) * | 2017-09-08 | 2017-12-08 | 歌尔科技有限公司 | A kind of Bluetooth communication method, device and bluetooth equipment |
| CN108134622A (en) * | 2017-12-29 | 2018-06-08 | 爱图智能（深圳）有限公司 | A kind of method and smart machine that control instruction is sent using Bluetooth audio frequency |
| CN108712737A (en) * | 2018-05-04 | 2018-10-26 | 北京洛克家智能科技有限责任公司 | A kind of method and system of information exchange |
-
2020
- 2020-12-25 CN CN202011566447.7A patent/CN112737739B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160117493A1 (en) * | 2013-04-27 | 2016-04-28 | Feitian Technologies Co., Ltd. | Working method of smart key device |
| CN107454563A (en) * | 2017-09-08 | 2017-12-08 | 歌尔科技有限公司 | A kind of Bluetooth communication method, device and bluetooth equipment |
| CN108134622A (en) * | 2017-12-29 | 2018-06-08 | 爱图智能（深圳）有限公司 | A kind of method and smart machine that control instruction is sent using Bluetooth audio frequency |
| CN108712737A (en) * | 2018-05-04 | 2018-10-26 | 北京洛克家智能科技有限责任公司 | A kind of method and system of information exchange |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113721498A (en) * | 2021-07-15 | 2021-11-30 | 青岛英泰信息技术有限公司 | FreeRTOS-based instruction interaction control system and method thereof |
| CN113645600A (en) * | 2021-08-13 | 2021-11-12 | Oppo广东移动通信有限公司 | Data transmission method, device, terminal and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112737739B (en) | 2022-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106559739B (en) | Lightweight data transmission method suitable for Bluetooth low-power wireless communication system | |
| US7236494B2 (en) | Limited automatic repeat request protocol for frame-based communications channels | |
| JP5438153B2 (en) | Status information transmission method and receiver for wireless communication system | |
| US7020822B2 (en) | Automatic repeat request for centralized channel access | |
| CN101877672B (en) | System and method for retransmitting packets over a network of communication channels | |
| US20010021984A1 (en) | Apparatus and method for re-transmitting erroneous packet data | |
| JP2006054673A5 (en) | ||
| CN112737739B (en) | Method for multi-packet communication between two devices | |
| CN106209915A (en) | A kind of real time flow medium radio transmitting method and system thereof | |
| JP3533385B2 (en) | Method and system for acknowledgment of data reception | |
| WO2022052507A1 (en) | Bluetooth low-power consumption audio data transmission method, and apparatus and device | |
| WO2016184333A1 (en) | Transmission method, device and system for group call of packet data | |
| CN100574274C (en) | The transmission system of radio link protocol and method | |
| EP1580916B1 (en) | System and method for transmitting units of messages in a mobile communication system | |
| US11258721B2 (en) | Radio link control (RLC) acknowledged mode (AM) data reception | |
| JP2016174211A (en) | Communication system | |
| CN104836645B (en) | A kind of RLC AM mode state feedback transmission methods | |
| KR20000025436A (en) | Method for retransmitting radio packets using plurality of response signals in radio communication system | |
| US20060251076A1 (en) | Real-time and reliable method for transporting data | |
| JPH1070523A (en) | Method and equipment for packet transmission | |
| CN111464569B (en) | Ethernet data transmission method adopting custom protocol | |
| CN109151904B (en) | Lora message reassembly and retransmission method, sending end and receiving end | |
| WO2012155703A1 (en) | Link parameter autonegotiation method, terminal and system based on hdlc protocol | |
| KR20090043724A (en) | A method for serial transmitting/receiving high volume data | |
| JPH10242946A (en) | Method for transmitting data frame |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |