What did you set for your min/max connection interval? The max data you can send is 20bytes. Check out the speed_app in the SDK for more details.
Thank for your comment.
I have already read the speed_test before. I set same connection parameter in hello_sensor.My min/max connection interval is 6(6*1.25ms=7.5ms The minimum connection interval in BLE spec).I call the API to change the connection interval in connection_up call back function.
lel2cap_sendConnParamUpdateReq(6, 6, 0, 700) =>This function use in the speed_test,and I porting it to my hello_sensor and hello_client.
The connection events are used to send data packets between the master and slave.The master will send the data package to slave in connection event. In my experiment, the master will send two data packages in connection event.
If I want to increase the data rate.I can use the short connection interval to increase transmission chance.Another method is to increase the times of transfers within the connection event.Can I increase the times of transfers within the connection event?
The max data you can send is 20bytes=>The master receive 300 Byte from PUART,and store it to the buffer. The master will use the writecmd to send the data of buffer. Each packet is 20 byte.
Note that the speed_test was included in the SDK to demonstrate an optimal transfer scenario. I would study that application and experiment with different parameters.
Hi mwf_mmfae ,
Thanks for the quick response. I had previously tested the speed_test. The data rate is about 70~80 kbps in my test. If I know the maximum number of packets within the connection event, and I can calculate the throughput for a BLE link. The number of packets per interval n and a connection interval T, the maxiumum throughput can be calculated like this:
throughput = N * 20 Byte * 1/T
Thank you for your attention!
This link may clear up the air a little...
But in general we cannot enforce the transmission of a certain number of packets in each connection interval.
I found the answer in the article.
=>In short, you can get anywhere from 1 to 6 packets (depends on resource availability, interference and a number of other factors) to the other side in this 7.5mS.
I get 2 packets in my experiment. Thank you.
Now the maximum throughput can be calculated like this:
Max throughput = 6 * 20 Byte * 1/7.5ms *8= 128 kbps
I found a strange phenomenon in my experiment.
When I download the firmware,and I got 4 notification packets within connection event.
And I press the reset bottom in both side(hello_sensor and hello_client), I got another transmission pattern.
I upload my code to the forum. I add puart function and GATT service in the sample code.
Why I got different transmission pattern?
I think I found the problem. I use TI Packet Sniffer to analyze the BLE packet. The result is shown in the following figure.
Before reset(After download the firmware) - Packet Sniffer:
Before reset(After download the firmware) - Logic Analyzer:
After Reset - Packet Sniffer
After Reset - Logic Analyzer:
Before I press the reset switch, I can got 4 packet within connection event. The master will send the data to the slave,and the MD(More Data) bit will set to "1". The MD will set to "0" until the master send 4 packets. So I can got 4 packet because of the MD is set to "1".
But when I press the reset switch, I only got 1 packet within connection event because the MD bit is set to "0". In addition to the MD isn't set to "1",some of connection event didn't send the packet(Like number 2464~2645 ). How to explain this phenomenon?
I still have a issue. Why I got different throughput within connection event? One is 4 packets within connection(After download firmware), and the other is 1 packet within connection event(After reset).
Throughput1(After download firmware): 4 * 20 Byte * 1/7.5ms *8= 85 kbps
Throughput2(After reset): 1 * 20 Byte * 1/7.5ms *8= 21 kbps
The expert in the reference post above discussed this issue around the concept of a MD (more data) bit. This will cause the client to poll the server immediately after the last bit of the current packet. This therefore can achieve multiple packets in one interval such as 4_packets/interval. Do you have such a condition in your application?
Thanks for the quick response.
When I download the firmware(hello_client and hello_sensor sample) to the chip, and I can got 4 packets in one connection event. But I rest the chip, and I just got 1 packet in one connection event.
We can use the API to send the notification packet, and the stack will send the packet to the receiver. I think the BRCM BLE stack will set the MD bit. I use hello_client to send the 15 notification packets, and the MD bit MD will be set three times in one connection event. So the hello_sensor will got 4 packets. But I reset the chip, The MD bit didn't set in one connection event. So the hello_sensor just got 1 packet.May I ask what is the reason?