Simultaneous BLE connections on WB55

​The BLE stack is able to connect to 2 central devices and up to 6 peripherals. So it is not possible to extend the number of connection to central devices.

You can disconnect from one central device and then connect to a new one as lon as the total number of central devices is not higher than 2.

Thank you for the quick answer, Remi! Is this limitation documented somewhere? Also, does ST have any plans to change this limit in the foreseeable future?

​Indeed I did not find this limitation mentioned in the application notes.

No there is no plan to extend the number of connected central devices for now.

​In fact this is mentionned in the release notes ofthe BLE stack under STM32Cube_FW_WB_V1.8.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x

• stm32wb5x_BLE_Stack_full_fw.bin
  • Full BLE Stack 5.0 certified : Link Layer, HCI, L2CAP, ATT, SM, GAP and GATT database
  • BT SIG Certification listing : Declaration ID D042164
    • Following features are kept:
      • GAP peripheral, central (LL slave up to 2 links, LL master up to 6 links)
      • GATT server, client
      • Data length extension
      • 2Mbit PHY / PHY update
      • Privacy / White list
      • Legacy Pairing, LE secure connections
      • HCI interface (full, like stm32wb5x_BLE_HCILayer_fw.bin)
      • Direct Test Mode

• stm32wb5x_BLE_Stack_light_fw.bin
  • Full BLE Stack 5.0 certified : Link Layer, HCI, L2CAP, ATT, SM, GAP and GATT database
  • BT SIG Certification listing : Declaration ID D042164
  • Wireless Ble stack Light configuration – Slave Only
    • Following features are kept:
      • GAP peripheral only (LL slave up to 2 links)
      • GATT server
      • Data length extension
      • Legacy Pairing
      • HCI interface (reduced)
      • Direct Test Mode

Thank you again for your prompt assistance, Remi. If I may, I'd like to suggest to document this limitation in a more visible fashion, rather than the release notes of the firmware file. I believe this is a serious limitation of the ST stack at this point, and knowing this limitation in advance, before committing to the ecosystem saves a lot of headache and frustration for your customers.

In addition, I'd suggest some changes in the example codes and the BLE boilerplate code generated by CubeMX:

• In app_conf.h, the CFG_BLE_NUM_LINK variable and its description might be misleading:

/******************************************************************************
 * BLE Stack
 ******************************************************************************/
/**
 * Maximum number of simultaneous connections that the device will support.
 * Valid values are from 1 to 8
 */
#define CFG_BLE_NUM_LINK 8

• In app_ble.c, the Adv_Request() function swallows the return value of aci_gap_set_discoverable(), hiding the fact that the advertisement actually fails.

static void Adv_Request(APP_BLE_ConnStatus_t New_Status)
{
 tBleStatus ret = BLE_STATUS_INVALID_PARAMS;
 
 BleApplicationContext.Device_Connection_Status = New_Status;
 /* Start Fast or Low Power Advertising */
 ret = aci_gap_set_discoverable(
 ADV_TYPE,
 CFG_FAST_CONN_ADV_INTERVAL_MIN,
 CFG_FAST_CONN_ADV_INTERVAL_MAX,
 BLE_ADDR_TYPE,
 ADV_FILTER,
 0,
 0,
 0,
 0,
 0,
 0);
 
 /* Update Advertising data */
 ret = aci_gap_update_adv_data(sizeof(ad_data), (uint8_t*) ad_data);
 
 if (ret == BLE_STATUS_SUCCESS)
 {
 APP_DBG_MSG("Successfully Start Fast Advertising \n" );
 }
 else
 {
 APP_DBG_MSG("Start Fast Advertising Failed , result: %d \n", ret);
 }
 
 return;
}

Thank you again for your help,

Akos

​interesting indeed!

I will push your request to our dev team.

Hello :)

Any news on this or are the maxmimum allowed connections for the STM32WB55 still 8?

Any plans to increase the max allowed connections?

Thanks!

No update.

What is your use case that requires more than 8 connections?

Quite interesting!!

The only way I can see is splitting the network architecture in 2 parts, adding on one of the peripheral devices today a role of master to interface with additional 6 or 7 other peripherals devices. This secondary master device would be connected to the first master as a peripheral or/and would directly connect to the tablet using the second peripheral role possible on a device to reduce any latency when displaying data on the UI.