Simple Mesh Node
Table of Contents
Introduction
The simple_mesh_node
project implements a simple Bluetooth Low Energy Mesh device with Mesh functionality.
The application can be controlled in 2 ways:
- Using a menu, controlled by two buttons.
- Using an external Host PC tool (Python script), sending messages over UART.
For information about BLE-Mesh configuration via SysConfig please refer to the BLE Mesh SysConfig Features
section in the BLE5-Stack User's Guide provided in the SDK.
This project has the following app configurations available:
App Build Configuration | Description |
---|---|
Release (default) | All TI-RTOS debug features disabled but application-logging to UART remains enabled. The application uses the config file ble_release.cfg and the defines are in <app name>_Release.opt . |
Debug | All TI-RTOS debug features enabled. The application uses the config file ble_debug.cfg and the defines are in <app name>_Debug.opt . |
All application configurations use the stack library configuration,
FlashROM_Library. This build configuration will yield additional flash footprint
optimizations by the linker since the application and stack can share
contiguous flash pages. This configuration is further discussed in the Stack
Library Configuration
section of the BLE5-Stack User's Guide provided in the SDK.
Hardware Prerequisites
The default Simple Mesh Node board configuration uses the device's LaunchPad development kit. This hardware configuration is shown in the below image:
For custom hardware, see the Running the SDK on Custom Boards
section of the
BLE5-Stack User's Guide.
Software Prerequisites
For information on what versions of Code Composer Studio and IAR Embedded Workbench to use, see the Release Notes file provided in the SDK. For information on how to import this project into your IDE workspace and build/run, please refer to the device's Platform section in the BLE5-Stack User's Guide.
Menu Usage
This application uses the UART peripheral to provide an interface for the application. The UART is only used for display messages.
This document will use a terminal program (Tera Term, PuTTY, etc.) to serve as the display for the output from the LaunchPad. Note that any other serial terminal can be used. The following default parameters are used for the UART peripheral display:
UART Param | Default Values |
---|---|
Baud Rate | 115200 |
Data length | 8 bits |
Parity | None |
Stop bits | 1 bit |
Flow Control | None |
Once the Simple Mesh Node sample application starts, the output to the terminal will report its address and that it is initialized and ready to begin discovery, as shown below. On the menu, you can use the left button (BTN-1) to move to the next option and the right button (BTN-2) to select an item:
Main Menu
First lines are for the 5 sub-menus: INIT, BUTTON, LED, GENERIC models and SENSOR models
Middle lines are for the status of the messages between devices.
Last lines are for the Button, Led, Generic models and Sensor models status
- Menu limitation: when configured to static provisioning, the node can communicate with up to 10 other nodes
- The default node configuration is basic mesh functionality+RELAY+PROXY.
- User must set a different UUID for each node.
The device UUID is configured in SysConfig under BLE → BLE Mesh → Provisioning Data Configuration before compiling the project
Init Menu
The Mesh Init menu contains 2 options to initialize the mesh device:
- With unprovisioned beacon
- Load from the Non-Volatile Storage (NVS) the address and provisioning info stored from previous run.
When static provisioning is enabled via SysConfig, the unprovisioned beacon option will be replaced with the static provisioning option.
Note: The device address is configured via SysConfig.
The provisioning information that the node will be loaded with, can be updated in the static_prov.c/h files.
Button Menu
The second option that can be selected is the BUTTON menu.
The BUTTON menu contains options to turn on and off a LED on a selected target device.
The menu also enables getting the status of the LED on the target device.
User can first set button target address, range = [Group, 1..10], default=Group (all nodes)
Note: Turn on the LED is not real led on device board
It is only status line ----LED ON---- in the device terminal
Led Menu
The third option that can be selected is the LED menu.
The LED menu contains an option to notify the status of a LED on selected target device.
User can first set led target address, range = [Group, 1..10], default=Group (all nodes)
Example - Turn on a Led
Sending Turn LED ON
from Node #1 to Node #2.
As can be seen in the picture below, in the LED status line (bottom line) in Node #2, after sending the request, the status of the LED is ON
Mesh models
Generic models Menu
The GENERIC models menu contains the following models sub-menus (client and server):
- ONOFF get, set, set_unack set values 0, 1 (default 0) several timing settings used for qualification testing (default transition time=0, delay=0) - LEVEL level get, set, set_unack delta set, set_unack move set, set_unack several level value (default 0x01FF) and timings used for qualification testing (default transition time=0, delay=0) - TRANSITION get, set, set_unack several timing values used for qualification testing (default transition time=0) - POWER ONOFF get, set, set_unack (ON, OFF, Restore) - BATTERY get
User can first set the target address, range = [Group, 1..10], default=1
Sensor models Menu
The SENSOR models menu contains Client, Server and Set target address sub-menu.
User can first set the target address, range = [1..10], default=1
Sensor Client models Menu
The SENSOR Client models menu contains Client command for the
following states:
Descriptor - get Data - get Column - get Series - get Settings - get Cadence - get, set, set_unack Setting - get, set, set_unack
User should first select the Property id:
tmpr8 - id of the temperature sensor implemented in this sample 0x42 - id of unimplemented sensor, used for qualification testing all - id used to send command for all sensors
Host PC Tool Usage
In order to work with the Host PC tool, the user must enable the Network Processor Mode via SysConfig (Under BLE).
When Network Processor Mode is enabled, the provisioning data and composition data configuration is done on the host side (and not via SysConfig).
For more information, please refer to the TI Bluetooth Mesh Host PC Tool
section in the BLE5-Stack User's Guide provided in the SDK.
BLE Mesh
Overview
A general mesh network has a many-to-many topology, where each device is able to communicate with every other device in the mesh network. Communication is achieved using messages, and devices are able to relay messages to other devices so that the end-to-end communication range is extended far beyond the radio range of each individual node.
Basic communication over mesh network is based on flooding, where each node, acting as a relay node, forwards a message which has been received and not designate to the local node. Managed flooding, where time to live and message caching mechanisms are implemented, is used to reduce the flooded traffic over the network. Enhanced implementations include management of forward paths to further optimize the forwarded traffic load.
The Mesh support over BLE networks is standardized by the SIG in the Bluetooth Mesh Profile specification and defines fundamental requirements to enable an interoperable mesh networking solution for Bluetooth low energy wireless technology.
High Level System Architecture
Mesh Profile
Starting from the bottom up, the BLE Mesh standard(Mesh Profile) enables overlay of a complete protocol stack on top of a BLE protocol stack, with the last providing bearer services to carry connection-less (as advertisement bearers) or connection-oriented (as GATT bearers) based connectivity. At the GATT bearers level, the BLE Mesh is seen as a profile where attributes are used to exchange mesh data.
The Mesh layer architecture:
The BLE Mesh network topology is built of different mesh nodes types (features):
- Mesh node: A member of a mesh network. It includes basic node functionality for receiving and processing broadcast, multicast and uni-cast message designate for the node as well as transmission of local mesh data.
- Mesh Relay node: Local processing as well as mesh messages relaying for range extension within a mesh network (Multiple hops support).
- Mesh Proxy node: Proxying between GATT-Bearer and Advertise bearer, for devices that support GATT-bearer only (i.e. Mobiles phones, etc.).
- Mesh Low power node: A power limited node which wakes up on specific time intervals to send messages or receive messages which are aggregated by a friend node.
- Mesh Friend node: Used to aggregate messages for LPN nodes during their sleep cycles and deliver their messages upon wake-up.
Node combinations are allowed over same device. For instance: Friend and Relay node.
An example Mesh network:
For further reading about the Mesh , please refer to the Mesh Networking Specifications on the Bluetooth SIG webpage.
Zephyr Project
The Texas Instruments mesh solution utilizes the open source code kindly provided by the Zephyr Project atop the TI BLE protocol stack.
The Zephyr Project is a community project managed by the Linux Foundation.
The source code can be found on GitHub.
TI BLE Stack & Zephyr
The following diagram shows the top level architecture in which the application, the Mesh profile, the adaptation layer and the BLE stack co-exist:
Changing Profile Configurations
As mentioned before in the Mesh Profile section, there are numerous Mesh capabilities. The node's capabilities are configured via SysConfig under BLE → BLE Mesh.