Peripheral Role#

The Peripheral role enables your device to advertise its presence and accept connections from central devices (such as smartphones, tablets, or other Bluetooth Low Energy (BLE) central devices). This page covers advertising, connection procedures, power save while connected, and connection parameter negotiation.

For Generic Attribute Profile (GATT) server implementation, notifications, and indications, see GATT server.

Advertising Types#

Peripheral devices use advertising to make themselves discoverable and connectable. The SiWx917 supports three types of advertising: Legacy Advertising, Extended Advertising (BLE 5.0+), and Periodic Advertising (BLE 5.0+).

Legacy Advertising Types#

Legacy advertising uses a single advertising instance and supports four advertising packet types:

ADV_IND (0x00) - Connectable and Scannable Undirected Advertising

  • Use Case: Standard peripheral advertising for general discoverability

  • Behavior: Device can be discovered, scanned, and connected to by any central device

  • API: Use rsi_ble_start_advertising() or rsi_ble_start_advertising_with_values() with connectable and scannable flags set

  • Most Common: This is the most commonly used advertising type for peripherals

ADV_DIRECT_IND (0x01) - Connectable Directed Advertising

  • Use Case: Fast reconnection to a specific known device

  • Behavior: Device advertises with a specific target address; only that device can connect

  • API: Use rsi_ble_start_advertising_with_values() with directed advertising parameters

  • Limitation: Directed advertising has a short timeout (typically 1.28 seconds) to save power

ADV_SCAN_IND (0x02) - Scannable Undirected Advertising

  • Use Case: Device discovery without accepting connections

  • Behavior: Device can be scanned but not connected to

  • API: Use rsi_ble_start_advertising_with_values() with scannable but non-connectable flags

Note: This is typically used in Broadcaster role (see Broadcaster role)

ADV_NONCONN_IND (0x03) - Non-Connectable Undirected Advertising

  • Use Case: One-way data transmission (beacon applications)

  • Behavior: Device broadcasts data but cannot be scanned or connected to

  • API: Use rsi_ble_start_advertising_with_values() with non-connectable and non-scannable flags

Note: This is typically used in Broadcaster role (see Broadcaster role)

Extended Advertising (BLE 5.0+)#

Extended advertising allows larger advertising data than legacy (31 bytes). The maximum extended advertising data length is configuration-dependent; the controller can report a value in the range 0x001F–0x0672 (31–1650 bytes). Use rsi_ble_get_max_adv_data_len() to query the actual limit for your build. Supported extended advertising payload on SiWx917 is 200 bytes per advertising set; advertising data chaining is not supported. See Extended advertising and Advertising set limits for details.

Periodic Advertising (BLE 5.0+)#

Periodic advertising enables synchronized data transmission without maintaining a connection. See Periodic advertising for details.

Setting Advertising Data#

Legacy Advertising Data:

  • Maximum 31 bytes of advertising data

  • Use rsi_ble_set_advertise_data() to set the advertising payload

  • Use rsi_ble_set_scan_response_data() to set scan response data (additional 31 bytes)

  • Advertising data format follows Bluetooth SIG AD structure (length, type, data)

Common Advertising Data Types:

  • Flags (0x01): Indicates device capabilities (LE Limited/General Discoverable, BR/EDR support)

  • Complete Local Name (0x09): Full device name

  • Shortened Local Name (0x08): Abbreviated device name

  • Complete List of 16-bit Service UUIDs (0x03): Services the device provides

  • Complete List of 128-bit Service UUIDs (0x07): Custom 128-bit service UUIDs

  • Manufacturer Specific Data (0xFF): Custom vendor data

Connection Procedures#

When a peripheral device is advertising, central devices can discover and initiate connections. This section describes the connection establishment process from the peripheral's perspective.

Connection Establishment Flow#

1. Advertising Phase

  • Peripheral starts advertising using rsi_ble_start_advertising() or rsi_ble_start_advertising_with_values()

  • Advertising packets are transmitted periodically on the three advertising channels (37, 38, 39)

  • Central device receives advertising packets during scanning

2. Connection Request

  • Central device sends a connection request (CONNECT_IND) to the peripheral

  • Connection request includes connection parameters (interval, latency, timeout)

  • Peripheral receives connection request automatically (handled by stack)

3. Connection Established

  • Peripheral or central receives rsi_ble_event_conn_status_t or rsi_ble_event_enhance_conn_status_t event indicating successful connection

  • Event includes remote device address, connection handle, and connection parameters

  • Advertising automatically stops when connection is established (for connectable advertising)

4. Post-Connection

  • Peripheral can now exchange data with the central device through GATT

  • Connection parameters can be negotiated (see Connection Parameter Negotiation)

  • GATT services and characteristics become accessible to the central device

Connection Event Handling#

Connection Status Event:

  • rsi_ble_event_conn_status_t: Basic connection status event

  • rsi_ble_event_enhance_conn_status_t: Enhanced connection status with detailed parameters

  • Register callbacks using rsi_ble_gap_register_callbacks() to receive connection events

Connection Parameters:

  • Connection Interval: Time between connection events (7.5ms to 4s)

  • Slave Latency: Number of connection events the peripheral can skip. BLE spec allows up to 499; on Si917 the stack supports 0–32 (values above 32 are clamped). See rsi_ble_conn_params_update() in GAP.

  • Supervision Timeout: Maximum time without communication before timeout (100ms to 32s). Note: Supervision timeout ÷ connection interval must be greater than 6 to allow connection parameter updates; otherwise disconnections with error 0x4e08 can occur.

Power Save During Connected State#

Power optimization is critical for battery-powered peripheral devices. The SiWx917 provides several mechanisms to minimize power consumption while maintaining BLE connections.

Connection Interval Optimization#

Connection Interval Impact:

  • Shorter Interval (for example, 7.5ms): Lower latency, higher power consumption

  • Longer Interval (for example, 100ms-4s): Higher latency, lower power consumption

  • Optimal Range: 20ms-100ms for most applications balances latency and power

Selecting Connection Interval:

  • Request appropriate interval during connection parameter negotiation (see Connection Parameter Negotiation)

  • Use rsi_ble_conn_params_update() to request interval changes after connection

  • Consider application requirements: real-time data needs shorter intervals, periodic updates can use longer intervals

Slave Latency#

Slave Latency Benefits:

  • Allows peripheral to skip connection events when no data to send/receive

  • Reduces power consumption by allowing device to sleep between connection events

  • Maximum latency depends on supervision timeout

Latency Configuration:

  • Set during connection parameter negotiation

  • Typical values: 0 (no skipping) to 10-20 (skip 10-20 events)

  • Must ensure: (1 + latency) × interval < supervision_timeout

  • Slave latency is limited to 0–32; values >32 are clamped to 32 by the stack. See rsi_ble_conn_params_update() in GAP.

Example:

  • Connection interval: 50ms

  • Slave latency: 10

  • Effective wake period: Every 550ms (11 × 50ms) instead of every 50ms

  • Power savings: ~90% reduction in connection event wake-ups

Connection Event Optimization#

Minimize Active Time:

  • Keep connection events short by minimizing data transfer per event

  • Use appropriate MTU size to reduce number of packets needed

  • Use write without response for non-critical data to avoid acknowledgment overhead

Data Transfer Strategies:

  • Burst Transfers: Send multiple notifications in single connection event when possible

  • Batching: Collect data and send in batches rather than individual updates

  • Adaptive Rate: Adjust notification rate based on connection interval

Power Save Considerations#

Sleep Between Connection Events:

  • Peripheral can enter low-power sleep between connection events

  • Wake up just before next connection event

  • Stack handles timing automatically

Connection Supervision Timeout:

  • Set appropriate supervision timeout based on connection interval and latency

  • Too short: Premature disconnections

  • Too long: Delayed detection of lost connections

  • Recommended: supervision_timeout > (1 + latency) × interval × 6

  • Si917: Supervision timeout ÷ connection interval must be > 6 to allow parameter updates; otherwise disconnections with error 0x4e08 can occur

Reference Power Management Guide:

Connection Parameter Negotiation#

Connection parameters (interval, latency, timeout) determine connection timing and power consumption. Both central and peripheral can request parameter changes, and negotiation ensures both devices agree on acceptable parameters.

Connection Parameter Request (From Central)#

Receiving Parameter Requests:

  • When the central requests parameter changes (using rsi_ble_conn_params_update()), the peripheral handles it in ble_on_remote_conn_params_request_event (rsi_ble_on_remote_conn_params_request_t), registered with rsi_ble_gap_register_callbacks(). The callback receives rsi_ble_event_remote_conn_param_req_t * (proposed interval, latency, timeout, etc.) and uint16_t resp_status.

  • Peripheral must respond using rsi_ble_conn_param_resp()

Response Options: rsi_ble_conn_param_resp(remote_dev_address, status) — status: 0 = ACCEPT, 1 = REJECT.

  • Accept: Call with status 0 to accept the requested parameters

  • Reject: Call with status 1 to reject (current parameters unchanged)

Implementation:

// Handle connection parameter request
void handle_conn_param_req(rsi_ble_event_remote_conn_param_req_t *request, uint16_t resp_status) {
    // Evaluate proposed parameters from request
    (void)resp_status;
    if (parameters_acceptable(request->interval, request->latency, request->timeout)) {
        rsi_ble_conn_param_resp(request->dev_addr, 0);  // 0 = ACCEPT
    } else {
        rsi_ble_conn_param_resp(request->dev_addr, 1);  // 1 = REJECT
    }
}

Connection Parameter Update (From Peripheral)#

Requesting Parameter Changes:

  • Peripheral can request parameter changes using rsi_ble_conn_params_update()

  • Request includes desired interval, latency, and timeout

  • Central device accepts or rejects the request

  • rsi_ble_event_conn_update_t event indicates successful parameter update

Parameter Constraints: (peripheral requesting update; supported ranges per WiSeConnect API)

  • Interval: Multiple of 1.25ms; supported range 7.5ms to 4s (units 6–3200). See rsi_ble_conn_params_update() in the API reference for exact limits.

  • Latency: 0–32 on Si917 (stack enforces max 32). Must satisfy (1 + latency) × interval < timeout.

  • Timeout: Supported range 100ms to 32s (units 10–3200, in 10ms). Must be > (1 + latency) × interval × 6. Supervision timeout ÷ connection interval must be > 6 to allow parameter updates; otherwise disconnections with error 0x4e08 can occur.

Example Parameter Update: Interval is in 1.25ms units; timeout is in 10ms units (see API reference). Choose values so that the effective supervision timeout is greater than (1+latency)×interval×6.

// Request longer connection interval for power savings
rsi_ble_conn_params_update(remote_dev_addr,
                           50,   // interval_min (62.5ms)
                           100,  // interval_max (125ms)
                           10,   // latency (skip 10 events)
                           1000); // timeout (10s)

Parameter Selection Guidelines#

Supported range (WiSeConnect API): Interval 7.5 ms–4 s (units 6–3200, 1.25 ms per unit), latency 0–32, timeout 100 ms–32 s (units 10–3200, 10 ms per unit). Use rsi_ble_conn_params_update(); see Parameter Constraints above for details.

The Bluetooth Core Specification defines the legal ranges and the supervision-timeout constraint; it does not define recommended values for different use cases. We give the following only as examples; actual parameter choice is usage-dependent (data rate, link-loss detection needs, and application behavior).

For Low Latency Applications:

  • Interval: 7.5–15 ms

  • Latency: 0

  • Timeout: 500 ms–2 s

For Balanced Applications:

  • Interval: 30–50 ms

  • Latency: 0–4

  • Timeout: 2–6 seconds

For Low Power Applications:

  • Interval: 100–200 ms

  • Latency: 9–29

  • Timeout: 6–12 seconds (ensure supervision timeout satisfies the spec inequality for your interval and latency)

Parameter Negotiation Best Practices#

  • Start Conservative: Begin with standard parameters, optimize based on application needs

  • Monitor Performance: Track connection stability and adjust parameters accordingly

  • Consider Both Devices: Parameters affect both central and peripheral power consumption

  • Validate Constraints: Ensure parameters satisfy Bluetooth specification constraints

  • Handle Rejections: Implement fallback if parameter requests are rejected

  • See Power Save During Connected State for power optimization APIs.

APIs Used in This Section#

Topic

APIs / symbols

Reference

GAP — advertising

rsi_ble_start_advertising(), rsi_ble_start_advertising_with_values(), rsi_ble_set_advertise_data(), rsi_ble_set_scan_response_data(), rsi_ble_stop_advertising(), rsi_ble_get_max_adv_data_len()

GAP

GAP — connection events

rsi_ble_gap_register_callbacks(); rsi_ble_event_conn_status_t, rsi_ble_event_enhance_conn_status_t

Register Callbacks, Callbacks Declarations

Connection parameters — control plane

rsi_ble_conn_params_update(), rsi_ble_conn_param_resp()

GAP

Connection parameters — events / callbacks

rsi_ble_on_remote_conn_params_request_t, rsi_ble_event_remote_conn_param_req_t, rsi_ble_event_conn_update_t

Callbacks Declarations