2019-01-11 12:59 AM
Hi,
I'm facing a problem with TX Buffer in my Through Put test using two SPBTLE-RF module. One acts as Client, and one as a Server.
The test is simple, continously call aci_gatt_write_without_response to send 20 bytes of data 1024 times (20 KB) and measure speed. But the test result came out not as expected, it takes about 19 seconds to send 20 KB.
Putting some debug code to see how it goes, I see that after first 7 consecutively sends, TX buffer is full and each time, it has to wait about 27ms before sending again.
Below is the debug code:
I have some questions regarding this, please support me:
Best regards,
Dat Le.
2019-03-18 08:51 PM
There is one other parameter that will control your throughput and that is the packets per connection interval. This is not negotiated but is controlled by the master. I don't know how it is controlled with BlueNRG-MS. I've only done applications talking to phones and each phone will allow a certain number of packets/interval. Typically it is 4 but some will go as high as 6.
2019-03-25 11:29 PM
Hi Dat Le,
TX buffer can be more than 7 bytes.
Please refer to "BlueNRG_MS_Throughput" sample project in DK, it sends 20-byte data.
27 ms may roughly be the connection interval plus time handling events such as printing to UART.
Chances are in your code it either sets CE length (explained below) to 1 or just explicitly sends 1 packet at each connection interval.
When creating the connection (aci_gap_create_connection), user can specify CE length in the last 2 parameters. Minimum_CE_Length and Maximum_CE_Length indicate minimum and maximum length of connection event needed for the LE connection. The controller can have the connection event open as long as it wishes by setting CE lengths high values.
Please noted that (from Spec):
The master shall ensure that a connection event closes at least T_IFS before the anchor point of the next connection event.
@rdscliff
Here the issue shall not be related to the well known maximum number of packets per connection interval limitation on most phones' HCI implementation, because 2 modules were used instead of phones.
Regarding to the limitation, user may customize an Android phone if needed.
Best Regards,
Winfred