Bluetooth Development Kits: From Board Selection to a Working BLE Demo - Yenra

Choose the board and software as a pair

Start with the intended connection. A BLE sensor exercise needs a different feature set from Classic Bluetooth audio or an existing serial-profile product. Confirm the radio modes and supported SDK examples for the exact board; a general Bluetooth label leaves those details unresolved.

For a first exercise, prefer a supported board with a documented debugger, USB connection, buttons, and LEDs. Record the board revision, computer OS, SDK, toolchain, and mobile app version. Use a USB data cable and the board’s documented programming port. A cable that supplies power without data can leave a board lit but absent from the development tools.

On a small screen, scroll the table sideways to read all columns.

Follow one versioned example from a clean baseline

The concrete reference here is Nordic’s Peripheral LBS sample in nRF Connect SDK v3.2.1, using an nRF52840 DK. This is a pinned learning reference, not a claim that v3.2.1 is the newest SDK. Its sample configuration includes the target nrf52840dk/nrf52840 and sysbuild.

First follow the installation and build setup in Nordic’s SDK Fundamentals course for the selected SDK and matching toolchain. Install nRF Connect for VS Code and confirm that the development kit is detected before trying a radio test.

1. In the sample browser, select SDK v3.2.1 and the Bluetooth LE LED Button Service example at samples/bluetooth/peripheral_lbs. Create a working copy.
2. Add the nRF52840 DK build configuration with the matching target and the sample’s sysbuild setup. Keep the default sample settings for the baseline.
3. Build, then flash the detected kit using the documented controls. Save the build output and first error if either step fails.
4. Open the board’s documented serial log and confirm startup and advertising messages. Use the SDK example’s expected LED indications as a second check.

If you choose another board or SDK, use that version’s support list and instructions throughout. Different board families use different printed LED and button numbers.

Verify the service, then both directions of data

Nordic’s first BLE exercise explains the roles: the board advertises as a peripheral and exposes the LED Button Service; the phone acts as central and GATT client. Open nRF Connect for Mobile, grant its documented permissions, scan, and connect to your Nordic_LBS device. Confirm identity by observing your own board’s power and connection behavior rather than selecting a similarly named neighbor.

On the nRF52840 DK, the pinned sample uses Button 1 for notifications and LED 3 for remote control. Enable notifications on the Button characteristic, then press and release Button 1. Write the LED characteristic and observe LED 3.

The pinned LBS service implementation accepts a one-byte LED value: hexadecimal 01 for on and 00 for off. Choose the app’s hex-byte input when entering those values. Typing the text characters “01” sends different bytes if the app is in text mode. Read the app’s preview before submitting.

Record the request, expected result, and observed result separately. A connected status establishes a link; a successful write followed by the intended LED response establishes a more useful application-level check.

Use failures and reconnection to improve the test

Board undetected: check the data cable, programming port, power and documented debugger setup. Build fails: record the first relevant compiler/configuration error and compare SDK, toolchain and target. Advertising absent: inspect firmware startup logs before changing phone settings.

Connected but no button events: confirm the Button characteristic’s notification subscription and the correct physical button. LED write rejected: check the selected characteristic and one-byte encoding. The service code makes data length and accepted values explicit, giving you a concrete starting point.

1. Record one complete connect, LED-on, LED-off, press and release sequence.
2. Disconnect normally, reconnect, rediscover the service if required, and check the notification subscription.
3. Restart the board and repeat the same sequence. Record which settings the app retains and which require action.
4. Save the example version and configuration before making your first modification.

This exercise is a learning baseline. A production device additionally needs an appropriate security design, update/recovery process, power measurements and product qualification. Use the Bluetooth module guide when moving from a development kit toward embedded hardware.