Bluetooth SDK Examples¶
The SiFli-SDK Bluetooth examples are focused starting points for a profile, role, or radio workflow; they are not drop-in product firmware. Start from the project that already proves the most constrained part of the product, make the unmodified example work on the target board, and then add one product requirement at a time.
This page organizes the Classic Bluetooth, BLE, and LE Audio broadcast examples for SF32LB58x by engineering task. The official page for each project remains the authority for its SDK release, supported boards, menuconfig settings, build commands, test equipment, and limitations.
Start with the Right Bluetooth Path¶
| Product need | Start with | Establish before product integration |
|---|---|---|
| A custom BLE service or companion-app link | BLE Peripheral | Advertising, connection, one service contract, reconnection, and phone-side validation |
| The device must act as both a phone peripheral and a sensor central | BLE Central and Peripheral | Simultaneous GAP roles and GATT client/server ownership |
| Reliable BLE data transfer | BLE Throughput or BLE File Transfer | The required payload flow, connection settings, and recovery behavior |
| Bluetooth firmware update | Peripheral with OTA or Central and Peripheral with Pingpong OTA | Update roles, interruption handling, partitions, and rollback plan |
| Classic Bluetooth serial, network, or phone compatibility | SPP, PAN, or HCI over UART | The intended host interface, peer device, and product transport boundary |
| Classic Bluetooth audio or calls | Music Sink, Music Source, or HFP | Audio route, clocking, buffering, phone interoperability, and power budget |
| LE Audio broadcast | BAP Broadcast Source or BAP Broadcast Sink | Broadcast role, audio pipeline, test receiver or transmitter, and timing margin |
Bring Up an Example as Evidence¶
Before changing the project, record the exact SDK version, board name, configuration, peer device or app, radio settings, and expected log. Then work through this sequence:
- Build and flash the unmodified example for a board supported by its official page.
- Prove the defining over-the-air behavior: discover, connect, transfer, stream, or receive as appropriate.
- Repeat the test after reset, disconnect, reconnect, and power-cycle conditions.
- Add one product-specific service, user-flow, audio route, or power policy at a time.
- Retest under the product's combined workload, including display, sensors, storage, audio, and low-power transitions where applicable.
An example demonstrates a bounded workflow. It does not establish that a product's security policy, radio range, latency, power consumption, or interoperability is ready for release.
BLE Examples¶
Use BLE examples for companion-app links, interoperable GATT services, beacons, data transfer, and BLE-based OTA. Select a role-oriented example first, then add a profile example only when the product needs that standardized service.
| Engineering task | Official examples | Use these projects to establish |
|---|---|---|
| Foundation roles and service access | Peripheral, Central and Peripheral, Multi-Connection | Advertising, scanning, connection ownership, and the correct central/peripheral split |
| Phone integration | AMS, ANCS, Dual-Core ANCS | Apple media or notification integration and the required phone-side pairing flow |
| Standard GATT profiles | BASC, CPPC, CSCPC, DISS, HRPC, CTS | The service role, characteristic contract, and peer interoperability of a standard profile |
| Input and intercom | HID, BLE Talkback | The interaction model before product UI or voice behavior is added |
| Pairing and reconnect behavior | BLE Pair | Bonding, identity handling, and the product's re-pairing path |
| Advertising and discovery | iBeacon, Periodic Advertising, Periodic Advertising Sync | The required broadcast or synchronization behavior without assuming a GATT connection |
| Data transfer and OTA | File Transfer, Throughput, Peripheral with OTA, Central and Peripheral with Pingpong OTA | Payload, link parameters, update roles, interruption recovery, and end-to-end validation |
Do not treat a throughput result as a product data rate. It depends on the selected PHY, connection settings, peer behavior, RF environment, host activity, and payload pattern. Likewise, an ANCS or AMS example is a phone-integration baseline, not a guarantee for every iOS release or user permission state.
Classic Bluetooth Examples¶
Classic Bluetooth projects apply to dual-mode products that need established BR/EDR profiles, audio, serial-style transport, or IP networking through a phone. They require a product-specific interoperability plan in addition to a successful development-board demonstration.
| Engineering task | Official examples | Use these projects to establish |
|---|---|---|
| HCI or serial-style transport | HCI over UART, SPP | The boundary between a host, controller, UART transport, and serial profile |
| Audio streaming and media control | A2DP Multi-Connection, A2DP Sharing, AVRCP Cover Art, Music Sink, Music Sink with Relay, Music Source | The intended source/sink topology, audio route, media-control path, and resource budget |
| Calls and voice links | 3-SCO, HFP, HFP Relay | Call topology, audio latency, microphone/speaker path, and phone behavior |
| Phone-provided networking and OTA | PAN, PAN OTA | Phone tethering, IP traffic, reconnection, and the OTA delivery path |
For the PAN networking model and phone-side setup, see Bluetooth PAN. For audio routing, buffer ownership, and system-load validation, see Audio Overview and Audio Server and Buffering.
LE Audio Broadcast Examples¶
The zbt projects focus on LE Audio Broadcast Audio Profile (BAP) roles. Treat the source and sink as a paired system test: the broadcast configuration, audio source, receiver, clocking, and RF conditions all matter to the observed result.
| Product direction | Official example | What to establish first |
|---|---|---|
| Receive a broadcast audio stream | BAP Broadcast Sink | Receiver behavior, output audio path, and the test broadcast configuration |
| Transmit a broadcast audio stream | BAP Broadcast Source | Source audio pipeline, broadcast configuration, and a known-good receiver |
| Bridge Classic Bluetooth and LE Audio broadcast | BAP Broadcast Source with Classic Bluetooth | The two audio domains, their handoff boundary, and combined timing/resource margin |
Product Validation Beyond the Example¶
| Boundary | Preserve from the source example | Re-validate for the product |
|---|---|---|
| Radio behavior | The supported board and the example's intended role or profile | Antenna, enclosure, range, RF coexistence, peer devices, and regulatory test plan |
| Connection policy | The baseline advertising, scan, or connection flow | Product latency, power target, reconnect strategy, and state transitions |
| Security | The example's pairing or bonding setup | Authentication requirements, key storage, privacy, factory reset, and user-facing recovery |
| Data and audio | The demonstrated packet or stream flow | Payload contract, error recovery, latency, buffering, codec configuration, and memory margin |
| Evidence | Build settings, logs, and expected behavior | Repeatable phone/accessory matrix, power trace, disconnect recovery, and regression test |
Related Resources¶
- Bluetooth Overview for product-level role, profile, security, connection-parameter, and coexistence choices.
- Bluetooth Processor Architecture for host/controller boundaries and power behavior.
- Bluetooth PAN for phone-tethered IP networking and PAN-based OTA.
- Audio SDK Examples for local capture, codec, and playback examples that complement Bluetooth audio work.
- Examples for the cross-domain SDK example catalogue.
Auto-generated content
This page was compiled/drafted without an existing source document. Verify technical claims against SiFli's official documentation before relying on them.