cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB BLE packet missing and INSUFFICIENT_RESOURCES

audrey38
Associate II

Hello all,

We are using BLE to send packet of 23 bytes every 5 ms. Since we have noticed that some packets are lost, we are trying to investigate to understand what's happened. In addition to lost packets, for almost every packet, we get the error BLE_STATUS_INSUFFICIENT_RESOURCES from function aci_gatt_update_char_value. Some packet retry several times before being received. We have this issue when BLE is connected to a computer or a smartphone, same behavior.

What are we doing wrong ? Is the time of 5 ms too short between sent packet ? In the documentation it is written that we could go up to 2 Mbit/s and currently we are only around 36 kbit/s.

Should we send more data in one packet but using a longer time between sent packets ?

Best regards,

Audrey

5 REPLIES 5
KKIM.6
Senior

2 Mbit is bit value in PHY-2 mode. 

When you are send a data, single data is in byte = 8 bit.

So, 2 Mbit/s => 250 kbyte/s max.

Of cause, it is not possible archieve that value because packets have overhead (3-4? byte) and time delay between packets.

The data thorughput examples that company provide, can archieve maxium 80 kbyte/s

If you are using STM32cubeMX and cubeIDE, the packet size is initally 156 if you dosen't change it.

but you need to change size of payload of aci_gatt_update_char_value if you want to send 156 byte per packet.

I'm also trying to find a way to improve data throughput usinf multi packet but there is really no example regarding on it. there is only a poor document explaining aci_gatt_write_long_char_value.

I'll reply again if I find somthing good.

  

audrey38
Associate II

Thank you KKIM.6 for your answer.

We are developping a mobile application that must be compatible with every smartphone and Samsung accepts only BLE packets of 23 bytes, that's why we use this size of packet. I will wait for your answer about multi packet.

Best regards,

Audrey

I tested transmitting 23 bytes per packet (a total of 26 bytes because of overhead, MTU-26). The number of packets is ~350 per second in PHY-1 mode. if I set PHY-2, it become ~450 per second. The data rate is around 6 kbyte/s and 10 kbyte/s but the response time is better than large packet. I think that the BLE module already sends multi packets because, for example, 450 packets per second means 2.2 ms per packet which is smaller than the connection interval (7.5 ms). I realize the initial phy is phy-1 if we doesn't change the PHY-mode using the hci_le_set_phy command. In addition, sometimes PHY-1 is faster than PHY-2 depending on the packet size. For example, I can achieve 580 packet/s in PHY-1 mode in the case of the 23-byte packet (MTU-23) but PHY-2 mode shows only 320 packet/s. 

FYI, you can change packet size in the #define CFG_BLE_MAX_ATT_MTU (23) in the app.conf.h.

You can use the hci_le_set_phy or hci_le_read_phy command in the custom_stm.c after getting the connection handle. (connection handle appears after the connection is maiden).

FYI 2. I'm using my own stm32wb55 circuit which shows -53 db signal strength.

In my experience, you don't need to limit the transfer rate. The Bluetooth module in STM32 operates at the highest speed by itself, so there is no need to control the connection interval. If you give some delay internally in your microcontroller, it may slow down the BLE data throughput. The only factors you need to control are the ATT-MTU and PHY-1 / PHY-2 mode. If you enter more data than Bluetooth can transmit, the data will be stored in the memory buffer of the Bluetooth module, and the data will be transmitted until the buffer is empty, even faster than 5 ms. It seems to decide by itself whether or not to send multiple packets in one connection interval.