nRF5 SDK for Thread and Zigbee v4.1.0
BLE Scanner and Thread SED Example

Table of Contents

This information applies to the following SoCs: nRF52833 and nRF52840.
This example requires the following SoftDevice: S140

Important: Before you run this example, make sure to program the SoftDevice.

Warning
There is an issue in the nRF5 SDK for Thread and Zigbee v4.1.0 that causes higher-than-usual sleep power consumption for all multiprotocol examples when using nRF52840. See workaround on DevZone.

The BLE Scanner and Thread Sleepy End Device example is a multiprotocol application that demonstrates a device simultaneously acting as a Bluetooth Low Energy Central and as a Sleepy End Device on Thread. Thread operates on the 802.15.4 radio during inactive time of the BLE radio (using Timeslot API). This allows for the application to spend a limited amount of radio time on Thread (as Sleepy End Device) and act as a BLE Central device and perform BLE scanning.

For more information about multiprotocol support, see Multiprotocol support with BLE/Bluetooth.

To show all of its functionalities, this BLE-Thread dynamic multiprotocol example requires three nRF52 Development Kit boards:

The example is configured to connect automatically to any BLE Proximity device found during BLE scanning.


Setup

You can find the source code and the makefile in the following folder: <InstallFolder>\examples\multiprotocol\ble_thread\ble_thread_dyn_mtd_scanner

LED assignments

The example uses LED assignments as described in Thread BSP LED and button reference for the following LEDs:

Button assignments

The following buttons are assigned in this example:


Testing

Note
The following testing procedure uses the nRF52840 device.

To test this example, you need three nRF52840 Development Kits.

  1. On the Thread-only Board 1, run the following commands to flash the thread_cli example and switch the board on:
    $ cd <InstallFolder>/examples/thread/cli/ftd/uart/hex
    $ nrfjprog -f nrf52 -r --program nrf52840_xxaa_pca10056.hex --chiperase
  2. On the BLE-only Board 2:
    1. Flash the SoftDevice.
    2. Run the following commands to flash the ble_app_proximity example and switch the board on:
      $ cd <InstallFolder>examples/ble_peripheral/ble_app_proximity/hex
      $ nrfjprog -f nrf52 -r --program ble_app_proximity_pca10056_s140.hex --chiperase
      LED1 starts blinking and BLE advertising starts.
  3. Build the BLE Scanner and Thread SED example (see Building examples).
  4. On the multiprotocol application Board 3:
    1. Connect to the board with an RTT such as J-Link RTT Viewer. All the application logs will be printed here.
      <info> app_timer: RTC: initialized.
      <info> app: Thread version : OPENTHREAD/20180926-01143-g8a1992e2; NRF52840; Dec 10 2019 22:45:59
      <info> app: Network name : OpenThread
      <info> app: Thread interface has been enabled.
      <info> app: 802.15.4 Channel : 11
      <info> app: 802.15.4 PAN ID : 0xABCD
      <info> app: Radio mode : rx-off-when-idle
      <info> app: BLE Thread dynamic MTD Scanner example started.
      <info> app: State changed! Flags: 0x0103D21D Current role: 1
  5. Connect to the Thread CLI Board 1 through UART. The application uses the following UART settings:
    • Baud rate: 115200
    • 8 data bits
    • 1 stop bit
    • No parity
    • HW flow control: None
    Refer to OpenThread CLI reference for complete reference of the OpenThread Command Line Interface.
  6. On the Thread-only Board 1:
    1. Run the following commands to form a Thread network. Use the same network credentials as the BLE Scanner and Thread SED example:
      > panid 0xabcd
      Done
      > channel 11
      Done
      > ifconfig up
      Done
      > thread start
      Done
      LED1 starts blinking (attaching to a Thread network) and, after a few seconds, it turns solid (Thread network created). The multiprotocol device then attaches to the network as a child. You can check the RTT logs:
      <info> app: State changed! Flags: 0x015002A4 Current role: 2
    2. Retrieve RLOC16 address of the multiprotocol device using the following command:
      > child table
      | ID | RLOC16 | Timeout | Age | LQ In | C_VN |R|S|D|N| Extended MAC |
      +-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
      | 1 | 0xc801 | 10 | 2 | 3 | 127 |0|1|0|0| 4a28713522754314 |
      Done
    3. Create an IPv6 address by replacing last two bytes of the following example address with retrieved RLOC16 of the device and ping it on Thread by running the following commands on the Thread CLI board:
      > ping fdde:ad00:beef:0:0:ff:fe00:c801
      > 16 bytes from fdde:ad00:beef:0:0:ff:fe00:c801: icmp_seq=1 hlim=64 time=1791ms
      Successful ping proves connectivity over Thread.
  7. On the multiprotocol application Board 3, press Button 1 on the multiprotocol board to trigger a BLE scan. All found devices are visible in the RTT logs. If there is a BLE Proximity device advertising and is in range (RSSI greater than RSSI_THRESHOLD defined in main.c), the application connects to it automatically.
    Scanning started, In range RSSI threashold: -60 dBm.
    <info> app: === Advertising device found ===
    <info> app: Peer address: e9e8abc2d4b
    <info> app: Proximity service available: true, In range: true
    <info> app: === Advertising device found ===
    <info> app: Peer address: 211ecd4f1f5a
    <info> app: Proximity service available: false, In range: true
    <info> app: Connected to e9e8abc2d4b.
    LED1 is now solid.
    Note
    The advertising has a timeout of 180 s. If no BLE Proximity devices are present in the logs, restart the BLE-only board, which resets the time-out timer.

Documentation feedback | Developer Zone | Subscribe | Updated