cancel
Showing results for 
Search instead for 
Did you mean: 

BlueNRG - Throughput Limitation

wills07
Associate
Posted on June 24, 2017 at 00:30

Dear Colleagues,

I'm developing a real time application which I need around 128 kbps of BLE application throughput.

Inside BlueNRG package there is a Throughput demo that shows how to implement a simple throughput test between two BlueNRG devices. In my case I have configured the following scenario:

STM32L053R8+IDB04A1 (as a SERVER) and STM32F030R8+IDB05A1 (as a CLIENT),

The throughput demo used is the '

SampleAppThT'

 with THROUGHPUT_TEST parameter defined in both sides (V2.8.0 / 10-Feb-2017) . Using the original code  I got around 155 kbps in the throughput test (only calculated by the SERVER side).

After this, I only did the following changes in the original code provided by ST:

1) Uncomment PRINTF command --> SERVER SIDE (sample_service.c)

while(aci_gatt_update_char_value(sampleServHandle, TXCharHandle, 0, 20, data)==BLE_STATUS_INSUFFICIENT_RESOURCES) {

 

// Radio is busy (buffer full).

 

PRINTF('Radio is busy (buffer full)\n');

 

if(Timer_Expired(&t)) {

 

break;

 

}

2) Uncomment PRINTF command --> CLIENTE SIDE (sample_service.c)

n_packet2 = LE_TO_HOST_32(attr_value+16);

 

if(n_packet2 != n_packet1 + 1){

 

lost_packets += n_packet2-(n_packet1+1);

 

}

 

n_packet1 = n_packet2;

 

packets++;

 

PRINTF('packet %d\n', packets);

However, after uncomment the PRINTF lines I've realized that after around 230 packets, the CLIENT side stops to receive packets and therefore the throughput calculated by the SERVER considered only the 'sent packets' .

I can see that when the SERVER busy (the output queue is full

and even so the SERVER try to send the packets the connection is dropped or the CLIENT simply does not receive anything.

I could verify the event 

EVT_BLUE_GATT_TX_POOL_AVAILABLE

 added in BlueNRG-MS FW stack 7.1c for avoiding continuous polling until BLE_STATUS_INSUFFICIENT_RESOURCES is returned. See: 

https://community.st.com/0D50X00009XkfPdSAJ

However, I don't think that this verification could increase the throughput (as the server will need to wait until the queue is free).

As the CLIENT does not receive at least the 500 packets, is not possible to correctly evaluate the real throughput in the CLIENT side.

After the explanation I have the following questions:

1) What's is the maximum throughput provided BLUENRG in the CLIENT side? (As the maximum

throughput in demo provided by ST is only showed in the SERVER side).

2) Does anyone have a working solution which could achieve the maximum theoretical BLE rate with BLUENRG? (Around 128Kbps).

PS.: I also attached the results provided by Serial terminal showing the results.

Many Thanks.

BR,

Willian Mattos

#bluenrg #stm32 #ble-throughput
2 REPLIES 2
wills07
Associate
Posted on August 01, 2017 at 21:44

Dear Colleagues,

It may be related with the above issue but I'm not sure:

I have found the following warning in the ST documentation (

SampleAppThT\readme.txt):

- WARNING: When using the NUCLEO-L053R8 boards the Throughput test may fails. No problem occurs

   when using NUCLEO-F401RE or NUCLEO-L476RG boards.

Anyone knows why this problem may happens?

Many Thanks.

Willian Mattos

Posted on August 02, 2017 at 01:32

>>Anyone knows why this problem may happens?

Likely that a 32 MHz CM0 is relatively nut-less compared to a 80+ MHz CM4, figure perhaps 4-5x slower, probably significantly more for FPU/ALU features.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..