Central Role#

The Central role enables your device to discover and connect to peripheral devices. This page covers scanning, connection initiation, managing multiple connections (GAP context), and central-side power considerations.

For Generic Attribute Profile (GATT) client procedures and multi-connection GATT context, see GATT client.

Scanning Modes and Parameters#

Scanning is the process of listening for advertising packets from peripheral devices. The SiWx917 supports both passive and active scanning modes with configurable parameters.

Scanning Modes#

Passive Scanning:

• Behavior: Listens for advertising packets without sending scan requests.

• Use Case: Lower power consumption, sufficient when advertising data contains needed information.

• API: Use rsi_ble_start_scanning() or rsi_ble_start_scanning_with_values() with passive mode.

• Power: Lower power consumption (receive only).

Active Scanning:

• Behavior: Listens for advertising packets and sends scan requests to receive scan response data.

• Use Case: When additional information is needed (scan response contains service UUIDs, device name, etc.).

• API: Use rsi_ble_start_scanning_with_values() with active scan mode.

• Power: Higher power consumption (receive + transmit).

Scanning Parameters#

Scan Interval:

• Range: 2.5ms to 10240ms (10.24 seconds).

• Definition: Time from start of one scan window to start of next scan window.

• Impact: Longer intervals reduce power but may miss advertisements.

• Typical Values: 100ms-1000ms for general scanning.

Scan Window:

• Range: 2.5ms to 10240ms.

• Definition: Duration of listening window during each scan interval.

• Constraint: Must be ≤ scan interval.

• Impact: Longer windows increase discovery probability but consume more power.

• Typical Values: 50ms-500ms (often 50-100% of scan interval).

Scan Window Ratio:

• Duty Cycle: scan_window / scan_interval.

• 100% Duty Cycle: Continuous scanning (maximum power, best discovery).

• Lower Duty Cycle: Intermittent scanning (lower power, may miss advertisements).

• Recommended: 50-100% for reliable discovery.

Discovery Modes#

Generic Discovery:

• Reports all discovered devices (connectable and non-connectable).

• Use for general device discovery.

Limited Discovery:

• Reports only devices in limited discoverable mode.

• Use for specific device discovery scenarios.

Scanning Implementation#

Starting Scanning:

// Start scanning with default parameters
rsi_ble_start_scanning();

// Or with custom parameters
rsi_ble_scan_params_t scan_params;
scan_params.scan_interval = 100;  // 100ms
scan_params.scan_window = 50;     // 50ms
scan_params.scan_type = ACTIVE_SCAN;
rsi_ble_start_scanning_with_values(&scan_params);// Start scanning with default parameters
rsi_ble_start_scanning();

// Or with custom parameters
rsi_ble_scan_params_t scan_params;
scan_params.scan_interval = 100;  // 100ms
scan_params.scan_window = 50;     // 50ms
scan_params.scan_type = ACTIVE_SCAN;
rsi_ble_start_scanning_with_values(&scan_params);

Receiving Advertisement Reports:

• rsi_ble_event_adv_report_t event is received for each advertisement.

• Event contains: device address, address type, RSSI, advertising data, and report type.

• Filter advertisements based on device address, service UUIDs, or other criteria.

Stopping Scanning:

• Use rsi_ble_stop_scanning() to stop scanning.

• Typically stopped after finding target device or when connection is established.

• If scanning is no longer needed (for example, after a connection is formed), the application must explicitly stop scanning; otherwise scanning continues in the background and can consume power.

Extended Scanning: For receiving extended advertising in Bluetooth Low Energy (BLE) 5.0 and later, use the extended scanning commands: rsi_ble_ae_set_scan_params() to configure parameters and rsi_ble_ae_set_scan_enable() to start or stop. See Extended advertising (Extended Scanning) for setup and API reference.

Connection Initiation Procedures#

After discovering a peripheral device through scanning, the central device can initiate a connection. This section describes the connection initiation process.

Connection Initiation Flow#

1. Device Discovery:

• Scan for advertising devices using rsi_ble_start_scanning().

• Receive rsi_ble_event_adv_report_t events for discovered devices.

• Identify target device by address, name, or service UUIDs.

• For extended advertising discovery (BLE 5.0+), use rsi_ble_ae_set_scan_params() to configure and rsi_ble_ae_set_scan_enable() to start or stop extended scanning.

• See Extended advertising — scanning for setup and API reference.

2. Connection Request:

• Use rsi_ble_connect() for a basic connection using default scan and connection parameters.

• Or use rsi_ble_connect_with_params() when you need to specify scan and connection parameters (interval, window, latency, supervision timeout).

• Or use rsi_ble_enhance_connect_with_params() when you also need filter accept list, own address type control (including RPA), or connection event length control.

• Or use rsi_ble_extended_connect_with_params() when connecting through extended advertising procedures with PHY selection (1M/2M/Coded PHY, BLE 5.0+).

• Connection request includes: remote device address, address type, connection parameters.

3. Connection Established:

• Receive rsi_ble_event_conn_status_t or rsi_ble_event_enhance_conn_status_t event

• Event indicates successful connection or failure reason

• Connection handle is provided for subsequent operations

4. Post-Connection:

• Stop scanning (if not needed for other devices)

• Begin GATT operations (service discovery, read/write characteristics)

• Monitor connection status and handle disconnections

Connection Parameters#

Connection Interval:

• Range: 7.5ms to 4s (must be multiple of 1.25ms)

• Impact: Shorter intervals = lower latency but higher power

• Typical Values: 20ms-100ms for most applications

Slave Latency: (central requesting or accepting parameters)

• Range: 0–32 (stack clamps values >32). If the remote peer is a Si917 peripheral, it enforces max 32 also on its side, else effective latency may be limited by the peer.

• Impact: Allows the remote peripheral to skip connection events; lower power for peer.

• Typical Values: 0-10 for most applications

Supervision Timeout:

• Range: 100ms to 32s

• Impact: Maximum time without communication before timeout

• Constraint: Must be > (1 + latency) × interval × 6. Supervision timeout ÷ connection interval must be > 6 to allow parameter updates; otherwise disconnections with error 0x4e08 can occur.

• Typical Values: 4s-8s

Connection APIs#

Basic Connection:

// Connect with default parameters
rsi_ble_connect(remote_addr_type, remote_addr);// Connect with default parameters
rsi_ble_connect(remote_addr_type, remote_addr);

• Use when: Default connection parameters are acceptable.

• Best for: Simple applications, quick prototyping, standard use cases.

Connection with Parameters:

// Connect with custom parameters
rsi_ble_connect_with_params(remote_addr_type, remote_addr,
                            scan_interval, scan_window,
                            conn_interval_max, conn_interval_min,
                            conn_latency, supervision_timeout);// Connect with custom parameters
rsi_ble_connect_with_params(remote_addr_type, remote_addr,
                            scan_interval, scan_window,
                            conn_interval_max, conn_interval_min,
                            conn_latency, supervision_timeout);

• Use when: You need to specify connection interval, latency, or supervision timeout.

• Best for: Power optimization, latency requirements, custom connection timing.

Enhanced Connection:

// Enhanced connection with additional options
rsi_ble_enhance_connect_params_t params;
// Configure parameters...
rsi_ble_enhance_connect_with_params(&params);// Enhanced connection with additional options
rsi_ble_enhance_connect_params_t params;
// Configure parameters...
rsi_ble_enhance_connect_with_params(&params);

• Use when: You need filter accept list control, custom scan parameters, or address type selection.

• Best for: Advanced filtering, privacy features, fine-tuned connection control.

Extended Connection (BLE 5.0+):

// Extended connection using extended advertising procedures
rsi_ble_ae_extended_create_connect_s ext_conn_params;
// Configure extended connection parameters...
rsi_ble_extended_connect_with_params(&ext_conn_params);// Extended connection using extended advertising procedures
rsi_ble_ae_extended_create_connect_s ext_conn_params;
// Configure extended connection parameters...
rsi_ble_extended_connect_with_params(&ext_conn_params);

• Use when: Connecting to devices using extended advertising (BLE 5.0+).

• Best for: PHY selection during initiation, Resolvable Private Address support, extended advertising scenarios.

Canceling Connection:

• Use rsi_ble_connect_cancel() to cancel a pending connection request.

• Useful if connection takes too long or device is no longer needed.

Multiple Connection Management#

The SiWx917 central role supports maintaining multiple simultaneous connections to different peripheral devices. This section covers managing multiple connections effectively.

Connection Tracking#

Connection Handles:

• Each connection has a unique handle (device address).

• Use device address to identify connections in API calls.

• Track active connections in application data structures.

Connection State:

• Device state (overall): Use rsi_ble_get_device_state() to get the local device state (for example, advertising, scanning, connected as a bitmask). It does not return which connections are active.

• Per-connection state: There is no API that returns the list of active connections. Track which connections are active by handling connection events (rsi_ble_event_conn_status_t, rsi_ble_event_enhance_conn_status_t) and disconnect events, and maintain the list in your application.

Managing Multiple Connections#

Connection Limits:

• Maximum number of simultaneous connections depends on system configuration.

• Each connection consumes memory and processing resources.

• Balance number of connections with application requirements.

Connection Prioritization:

• Prioritize connections based on application needs.

• Critical connections: Use shorter connection intervals.

• Background connections: Use longer intervals for power savings.

• Adjust connection parameters per connection using rsi_ble_conn_params_update().

Connection Lifecycle:

• Establish: Initiate connections to discovered devices.

• Maintain: Monitor connection status, handle parameter updates.

• Terminate: Use rsi_ble_disconnect() when connection no longer needed.

• Reconnect: Re-establish connections to previously bonded devices.

Power Consumption Considerations#

Power optimization for central devices involves balancing scanning, connection management, and GATT operations to minimize power consumption while maintaining required functionality.

Scanning Power Optimization#

Scan Duty Cycle:

• Reduce scan window relative to scan interval for lower power.

• Use shorter scan windows when target devices are known to advertise frequently.

• Stop scanning when not needed (for example, after finding target device).

Scan Interval Selection:

• Longer scan intervals reduce power but may miss advertisements.

• Balance discovery latency with power consumption.

• Use adaptive scanning: high duty cycle initially, reduce after discovery.

Selective Scanning:

• Use accept list filtering (rsi_ble_addto_acceptlist()) to scan only for known devices.

• Reduces processing overhead for unwanted advertisements.

Connection Power Optimization#

Connection Interval Management:

• Use longer connection intervals for connections with infrequent data.

• Request interval changes using rsi_ble_conn_params_update() based on data needs.

• Different intervals per connection based on priority.

Connection Event Optimization:

• Minimize data transfer per connection event.

• Batch operations when possible.

• Use write without response for non-critical data.

Connection Supervision:

• Set appropriate supervision timeout based on connection requirements.

• Longer timeout reduces false disconnections but delays detection of lost connections.

• Balance reliability with power efficiency.

GATT Operation Optimization#

Efficient Service Discovery:

• Cache discovered service and characteristic handles at the application level (BT 5.1 GATT Caching feature is not supported on SiWx917).

• Avoid repeated discovery operations.

• Use UUID-based discovery when handles are known.

Batch Operations:

• Read/write multiple characteristics in batches when possible

• Use rsi_ble_get_multiple_att_values() for multiple reads

• Reduce number of connection events needed

MTU Optimization:

• Request larger MTU to reduce packet overhead

• Fewer packets = fewer connection events = lower power

• As ATT Client: When RSI_BLE_MTU_EXCHANGE_FROM_HOST is enabled, the application receives rsi_ble_mtu_exchange_event() when MTU exchange is triggered; initiate after connect or enhance connect event.

• As ATT Server: Use rsi_ble_mtu_exchange_resp() to respond to MTU exchange requests (when RSI_BLE_MTU_EXCHANGE_FROM_HOST is enabled).

Power Management Strategies#

Adaptive Behavior:

• High activity: Shorter intervals, active scanning

• Low activity: Longer intervals, passive scanning, reduce scan duty cycle

• Idle: Stop scanning, use longer connection intervals

Sleep Between Operations:

• Enter low-power sleep between connection events

• Sleep during scan intervals (when scan window < scan interval)

• Stack handles timing automatically

Reference Power Management Guide:

• For detailed power management strategies, see the Power Management Developer Guide. The guide also includes power save modes and sleep configurations.

APIs Used in This Section#