what the meaning of "average of 4 connection events"?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

According to speed_test example, it is possible that it is transferring data to fine_timer of 12ms.

I saw in the discussion related to the previous one. Re: Maximum BLE throughput for reliable data transfer

"So at the app layer, if you send 20 bytes / packet, assume an average of 4 connection events / connection interval and 133 intervals (7.5mS) / second, you will get ~ 85Kbps."

In this article, what the meaning of "average of 4 connection events"?

If the calculations, 20 * 4 * 133 * 8 = 85120bits -> about 85kbits / s.

Is the means by 20byte simultaneously transmit four times?

If this is correct, how do this?

If not, let me know how.

In speed_test is confirmed by sending once every 12ms.

According to "connection interval and 133 intervals (7.5mS) / second", that the transfer once every 7.5ms. This is possible?

I do not know too much about the ble.

Thanks you for your cooperation.

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

> According to speed_test example, it is possible that it is transferring data to fine_timer of 12ms.

The app is enqueueing data every ~12mS. It may or may not be transmitted immediately because connection events won't always line up and these packets only go into the transmit queue (because the baseband has reliable delivery - the packet will not be released until acknowledged over the air by the other side).

Packet headers have a bit called the MD bit (more data) which will be set when more data is pending in the device's transmit queue. In a slave->master data transfer (typically server sending notifications, which is what I think you have here) when the master sees that this bit is set, it may choose to poll the slave yet again immediately after receiving the last bit of the current packet (after the required inter-frame silence) so the slave can transmit yet another packet (which may/maynot have the MD bit set) and so on. So as you can see, you can transmit multiple packets within the same connection interval (because time to poll + max sized packet + inter frame silence is < 1mS and so you can have many of these within a connection interval). Whether the master polls the slave when the MD bit is set or not is entirely up to the master and what other connections/scans/advertisements/other activities it has to perform. So, in a 7.5mS connection interval, assuming that the master will poll the slave 4 times every connection interval when the MD bit is set on every packet will not be far from reality in most cases.

The best place to start learning about BLE is the Bluetooth SIG website at buetooth.org and the developer site at developer.bluetooth.org.

If you use PUART at a baud rate of say 115200, you can achieve ~100 kbits/s data over UART (you have to take care of overflow on UART and your FW buffers). So if you use a mechanism similar to speed_test, you should be able to keep up quite easily over PUART.

View solution in original post

4 Replies
Anonymous
Not applicable

I get 16 bytes of 20ms each using uart. The notification to the fine_timer of 12ms.

The blocks are configured in this my project.

[   uart   ] -> [   uart   ][1kbyte buffer][notification]  -> [wireless] -> [android phone]

[MICOM]     [                   BCM20732                  ]

*set lel2cap_sendConnParamUpdateReq(6, 6, 0, 700)*

If the calculation,

micom uart -> buffer : Data transmission of 6kbps.

buffer -> wireless : Data transmission of 12kbps.

It is theoretically possible 12kbps. But soon the buffer overflow.

0 Likes
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

> According to speed_test example, it is possible that it is transferring data to fine_timer of 12ms.

The app is enqueueing data every ~12mS. It may or may not be transmitted immediately because connection events won't always line up and these packets only go into the transmit queue (because the baseband has reliable delivery - the packet will not be released until acknowledged over the air by the other side).

Packet headers have a bit called the MD bit (more data) which will be set when more data is pending in the device's transmit queue. In a slave->master data transfer (typically server sending notifications, which is what I think you have here) when the master sees that this bit is set, it may choose to poll the slave yet again immediately after receiving the last bit of the current packet (after the required inter-frame silence) so the slave can transmit yet another packet (which may/maynot have the MD bit set) and so on. So as you can see, you can transmit multiple packets within the same connection interval (because time to poll + max sized packet + inter frame silence is < 1mS and so you can have many of these within a connection interval). Whether the master polls the slave when the MD bit is set or not is entirely up to the master and what other connections/scans/advertisements/other activities it has to perform. So, in a 7.5mS connection interval, assuming that the master will poll the slave 4 times every connection interval when the MD bit is set on every packet will not be far from reality in most cases.

The best place to start learning about BLE is the Bluetooth SIG website at buetooth.org and the developer site at developer.bluetooth.org.

If you use PUART at a baud rate of say 115200, you can achieve ~100 kbits/s data over UART (you have to take care of overflow on UART and your FW buffers). So if you use a mechanism similar to speed_test, you should be able to keep up quite easily over PUART.

Anonymous
Not applicable

Thanks you.

I got another question.

What will be transmitted once every 7.5mS data that is entered in the transmission queue mean?

Every 12mS accumulate data are only in the transmission queue,

Because they do not send immediately, does that mean that eventually sent to 7.5mS connection interval?

0 Likes

If connection interval is 7.5mS, the master will poll (or send data itself) the slave for data at least once every 7.5mS (or more often only if MD bit in either/both directions is set). This is the only time the devices can exchange data over the air. Data that is to be sent may be generated asynchronously to this. In speed_test, it generates data packets every 12.5mS, but gets sent out at the 7.5mS interval.