Use Case #10: I want to exchange data with up to 32 peripheral devices#

This use case describes an EFR32 central that scales to 32 simultaneous EFR32 peripheral links. It provides a characterization baseline for a Bluetooth Low Energy central that scans for peripherals advertising a known custom service, opens links as peers are found, discovers the required GATT objects, enables notifications, and maintains up to 32 simultaneous connections with selectable PHY operation. For information about the general requirements for handling multiple connections, see Multi-Peripheral Topology.

The reference topology consists of one central and up to 32 peripheral connections. The software baseline is SiSDK 2025.12.3. The hardware baseline is an EFR32MG26 on a BRD4116A radio board with a BRD4002A mainboard.

Bluetooth features used: connections, legacy passive scanning, GATT service discovery, notifications, optional write-without-response traffic, and selectable 1M, 2M, or Coded PHY operation.

System Model and Assumptions#

Topology#

• One EFR32 central maintains N simultaneous connections, where N can scale up to 32.

• The central uses a fixed-size peer table sized for the target connection count and treats each discovered peripheral as a managed slot in that table.

• All links are intended to remain active once opened. Application does not deliberately disconnect.

• Baseline runtime behavior is continuous multi-link management, GATT service discovery, notification reception from peripherals, and automatic reconnect handling after disconnects.

• Scanning restarts after connection events and during maintenance so discovery and reconnection can continue while other connections are active.

Baseline Connection Configurations#

• ATT MTU = 247.

• 1M PHY on all links.

• Peripheral latency = 0.

• Connection interval = 50 ms.

• No Bluetooth security used.

• Supervision timeout = 6000 ms.

• DLE enabled, preferred data length = 251.

• Even Connection Scheduling Algorithm enabled.

• Use legacy passive scanning to discover peripherals that advertise the custom 128-bit service UUID in the advertising payload.

• The central expects the peripheral GATT database to expose one custom service containing a notify characteristic for peripheral-to-central data and a write-without-response characteristic for optional central-to-peripheral traffic.

• For the additional application features used, see Appendix A. Application features.

General Configuration Tips#

• Choose the right PHY profile: 1M, 2M, or Coded, based on throughput, airtime, and range requirements. More information on the trade-offs between PHYs can be found here.

• Size the connection budget for 8, 16, 20, 24, or 32 maintained links and set connection parameters and stack memory accordingly.

• Tune minimum and maximum connection event length to control scheduler margin.

• Align data length, ATT MTU, and available buffering with the intended traffic profile. Generic throughput optimization techniques are available here.

• An appropriate Bluetooth security mechanism may be implemented using Security Manager.

• For cases where 2.4 GHz congestion is expected, such as with coexistence, the following mitigations can be helpful:

  • Use longer connection intervals.

  • Reduce payload size.

  • Use AFH.

  • Use Channel Classification.

  • Switch to a more robust PHY.

Test Conditions#

• Use peripherals that expose the required custom service and characteristic contract expected by the central.

• The test passes if all target links stay connected for the full test duration with no unexpected disconnects.

• Use good RF conditions, low external interference, fixed node placement, and identical peripheral firmware/configuration.

Memory Footprint#

Component-wise Static Memory Breakdown#

Note: The memory consumption reported under Application in the preceding table includes the features listed in Appendix A. Application features and may vary depending on the application. Component grouping follows Appendix B.

Failure Modes and Mitigations#

Decision Tree: When to Choose PAwR Instead of Many Connections#

Use this quick check:

If both rows apply, start with many connections for up to 32 managed links and evaluate PAwR only if scheduler margin, reconnection behavior, or scaling becomes the limiting factor.

Appendix A. Application features#

• Fixed 32-slot peer table with connection statistics and per-peer state machine.

• 2M and Coded PHY are compile time configurable.

• Advertisement filtering for the expected custom 128-bit control service UUID.

• Automatic scan resume after connection and discovery events to fill or restore the 32-link set.

• Standard GATT flow: service, characteristic discovery, notification enablement.

• Compile-time configurable link parameters for PHY, interval, supervision timeout, MTU, and data length.

• Disconnect handling with bounded reconnect backoff and per-peer retry state.

• Optional logging of KPIs (disabled by default): opens, failures, disconnects, discovery failures, throughput, scheduler skips, reconnect attempts, full-32-link dwell time, and heap high-water reporting.

• Central can optionally enable a round-robin mechanism to perform write-without-response across all the connected peripherals. It is disabled in baseline.

• Service UUID: efcdab89-6745-2301-fedc-ba9876543210.

• TX notify UUID: efcdab89-6745-2301-fedc-ba9876543211.

• RX write UUID: efcdab89-6745-2301-fedc-ba9876543212.

Appendix B. Object File Grouping Used for the Memory Breakdown#

The map-file analysis groups the object files into 12 categories.

This grouping is used only to make the memory breakdown easier to read. Some categories contain many object files, while others contain only a few reserved sections or support objects.