nRF5 SDK for Mesh v5.0.0
Beaconing example
You can test this example on the following devices: nRF52840, nRF52833, nRF52832, nRF52820, and nRF52810.

This example shows how to do concurrent beaconing, which allows an application to advertise beacons (such as iBeacon or Eddystone beacons) while participating in the Bluetooth mesh network. Moreover, it demonstrates the usage of the RX callback.

Table of contents

Beacon sending

To send beacons, the application uses the mesh-internal packet manager and advertiser structure directly.

The application first initializes the advertiser (initialization is needed only once). It then allocates and fills the fields of the packet. There is no need to set the packet type or advertisement address, because this is taken care of by the advertiser module.

After the initialization, the application schedules the packet for transmission by putting it in the TX queue of the advertiser, with a parameter indicating the number of repeats that the advertiser will do. In this example, the repeat count is set to BEARER_ADV_REPEAT_INFINITE, which causes the packet to be retransmitted forever or until replaced by a different packet.

Using the packet manager and advertiser directly makes the application compete for the same resources as the Bluetooth mesh core framework. Incorrect or heavy usage will affect Bluetooth mesh performance or stability. Treat these modules with caution.

RX callback

The beaconing example also demonstrates the usage of the RX callback. This functionality allows to receive all non-filtered, BLE-compliant advertisement packets in the application code. These packets are captured by Scanner.

The RX callback can be registered through nrf_mesh_rx_cb_set(). As an input, the RX callback function takes a pointer to a nrf_mesh_adv_packet_rx_data_t struct that contains all data available on the incoming packet.

Once a new packet is captured by the Scanner, the filtering is applied. By default, the Bluetooth mesh filters out non-mesh packets. If the new packet is not filtered out, it is passed through the provided RX callback to the user application.

There are various filter types that can be used to filter out the incoming packets. See Packet filtering for more details.

The RX callback is invoked for all packets that are processed by the Bluetooth mesh after the mesh itself has processed them. The Bluetooth mesh assumes that all incoming packets adhere to the Bluetooth Low Energy advertisement packet format.

In the beaconing example, in addition to the Bluetooth mesh packets' filtering, the filtering by the Complete Local Name Advertising Data Type (AD Type) is applied. It means that the packets containing Complete Local Name AD Type will also be passed to the RX callback.

Hardware requirements

You need one compatible development kit for this beaconing example.

See Compatibility for information about the compatible development kits.

Software requirements

You need to install nRF Connect in one of the following versions:


You can find the source code of the beaconing example in the following folder: <InstallFolder>/examples/beaconing

Testing the example

To test the beaconing example:

  1. Build the example by following the instructions in Building the Bluetooth mesh stack.
  2. Program the board by following the instructions in Running examples.
  3. Connect RTT viewer to see the RTT output generated by the beaconing example in the RTT log.

Once the example is running, it outputs all non-filtered incoming packets over RTT. Outgoing beacons can be observed with nRF Connect for Desktop or nRF Connect for Mobile.

Documentation feedback | Developer Zone | Subscribe | Updated