BLE Write Attribute Performance / Throughput

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

cross mob
aglier
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Hi everyone,

 

I'm trying to transmit some data over GATT characteristics.

The connection setup allows the minium connection interval of 7.5ms (i can see this in the connection updated events from EZSerial)

The peripheral allows a maximum MTU per write of 154 bytes.

If I use write handle without acknowledgement I can only got down to around 20ms between each write.

If I go below this delay, I will have data loss.

If I use acknowledgement instead, I can get up to 5kByte/s throughput.

Is the CYBT343026 capable of going above that throughput?

Is there any setting that I can adjust for improving the performance? I feel like this is way to low for 4.2 BLE.

 

Best regards

Alex

0 Likes
1 Solution
Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

Hi,

I think the bottleneck is the GATT itself. Unlike CYSPP, which is based on RFCOMM, GATT is based on ATT. ATT is a connectionless protocol, while RFCOMM is a connection-oriented protocol. This fundamental difference results in the different theoretical transmission throughput. So I think it can't achieve the same TX/RX rate as Bluetooth Classic.

Also, the minimum connection interval of 7.5ms is hardly achieved in the tests. Due to hardware restrictions, around 25ms was detected as the actual minimum interval. You can record the air log to verify this.

The actual maximum throughput you could get should be 5-7 kbytes/s, based on the interval of 25ms and the maximum MTU of 154 bytes. So I think you have already achieved the actual maximum throughput, via GATT.

Best regards

View solution in original post

0 Likes
4 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

@Charles_Lai , Do you have performance documents for this module ?  I know IOS has limitations that will influence the T/P value , better to check details for this request, thanks.

0 Likes
Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

Hi,

Are you running the test over the EZ-Serial firmware? Please use the CYSPP profile to transmit data if so.

Or you can try the below demo, and refer to it:
https://github.com/Infineon/mtb-example-btsdk-ble-throughput

Best regards

0 Likes
aglier
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Hi,

 

no I'm not using CYSPP and I also can not use it as I'm not talking to a Cypress Module on the other side.

But it should be a almost similar approach.

Rx and Tx characteristics that need to be utilized.

Still I'm not able to send Write Attribute Commands faster then 15ms.... If I do so, it will result in data loss.

The uart is fast enough to handle the command flow. But it seems that EZ serial is the restricting component.

Any restrictions that you are aware of?

0 Likes
Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

Hi,

I think the bottleneck is the GATT itself. Unlike CYSPP, which is based on RFCOMM, GATT is based on ATT. ATT is a connectionless protocol, while RFCOMM is a connection-oriented protocol. This fundamental difference results in the different theoretical transmission throughput. So I think it can't achieve the same TX/RX rate as Bluetooth Classic.

Also, the minimum connection interval of 7.5ms is hardly achieved in the tests. Due to hardware restrictions, around 25ms was detected as the actual minimum interval. You can record the air log to verify this.

The actual maximum throughput you could get should be 5-7 kbytes/s, based on the interval of 25ms and the maximum MTU of 154 bytes. So I think you have already achieved the actual maximum throughput, via GATT.

Best regards

0 Likes