This example shows how to use a standalone Stateflow® chart to model the state machine in a Bluetooth® low energy (BLE) link layer.
Bluetooth technology is a wireless interface intended to replace the cables connecting portable and fixed electronic equipment. The Bluetooth Special Interest Group industry consortium defines two groups of standards for this technology: Bluetooth low energy (BLE) and Bluetooth basic rate/enhanced data rate (BR/EDR). BLE devices are characterized by low power consumption and low cost. These devices have an operating radio frequency in the range 2.4000 GHz to 2.4835 GHz. The operating band is divided into 40 channels, each with a bandwidth of 2 MHz. User data packets are transmitted using channels in the range from 0 to 36. Advertising data packets are transmitted in channels 37, 38, and 39.
The functionality of the BLE protocol stack is divided between three main layers:
The controller layer includes the low energy physical layer (PHY), the link layer (LL), and the controller-side host controller interface (HCI). The state machine modeled by this example is part of the link layer in this portion of the BLE protocol stack.
The host layer includes the host-side HCI, logical link control and adaptation protocol (L2CAP), attribute protocol (ATT), generic attribute profile (GATT), security manager protocol (SMP), and generic access profile (GAP). This layer also contains the BLE mesh stack, which consists of the advertising bearer, network, lower transport, upper transport, access, foundational model, and model layers.
The application profiles and services layer (APP) is the user interface that defines usage profiles and enables interoperability between Bluetooth applications.
In the BLE protocol stack, the link layer manages the state of the radio to define the role of a device as advertiser or scanner. This layer interfaces directly with the PHY layer, which uses the three advertising channels (37, 38, and 39) to transmit and receive data packets.
In this example, the standalone Stateflow chart
sf_bluetooth.sfx defines the operating modes of the link layer. The chart has three states:
Scanning. Initially, the
Standby state is active, indicating that the device is idle. In the next time step, the chart transitions to the
Scanning state, depending on the value of the local data
TxData. This value indicates whether there is data from the advertising bearer in the host layer available for transmission.
If there is data available, the chart transitions to the
Advertising state. When this state is active, the device cycles through the three advertising channels and transmits the same data packet in each channel. The chart remains in the
Advertising state for an advertising interval before it returns to the
Standby state. The advertising interval is divided into three checkpoint timestamps that correspond to the three advertising channels. In this example, the advertising interval consists of a minimum of 20 milliseconds, with checkpoint timestamps at 1 millisecond (for channel 37), 9 milliseconds (for channel 38), and 17 milliseconds (for channel 39).
If there is no data available, the chart transitions to the
Scanning state. When this state is active, the PHY layer passively scans one of the advertising channels for new data. If the PHY layer receives a data packet, the link layer passes it to the advertising bearer layer. The chart remains in the
Scanning state for a scanning interval before it returns to the
Standby state. At that point, if there is still no data available, the chart selects a new advertising channel and starts another scanning interval. In this example, the scanning interval consists of 50 milliseconds.
sf_bluetooth_demo.m creates a BLE link layer object
bleLinkLayer and simulates 10 seconds of mesh communications over an advertising bearer. The link layer object relies on the standalone chart
sf_bluetooth.sfx for control logic and on the link layer queue object
bleQueue for storing data from the advertising bearer.
The simulation consists of 10,000 time steps. Each time step represents an execution of the link layer object (which corresponds to 1 millisecond of simulation time) and typically consists of these steps:
If the link layer queue is not empty, read a data packet. The data in the queue represents the advertising data packets that the link layer obtains from the advertising bearer layer.
Set the value of the chart data
TxData and execute the standalone chart. In this step, the chart determines whether the device acts as an advertiser or scanner.
If the chart is in the
Advertising.Transmit state, generate a BLE link layer advertising channel protocol data unit (PDU) using the data read from the link layer queue. The PDU represents a transmission by the PHY layer. For more information on generating and configuring the advertising channel PDU, see
bleLLAdvertisingChannelPDU (Communications Toolbox) and
bleLLAdvertisingChannelPDUConfig (Communications Toolbox).
There are two exceptional cases:
Every 1000 time steps, the script pushes data into the link layer queue before executing the link layer object. This data represents the advertising data packets that the link layer obtains from the advertising bearer layer.
Every 2500 time steps, the script generates a BLE link layer advertising channel PDU that represents an advertising data packet received by the PHY layer. Then the script executes the link layer object. If the chart is in the
Scanning state, the link layer object attempts to decode the PDU and, if the decoding is successful, passes the PDU to the advertising bearer layer. For more information on PDU decoding, see
bleLLAdvertisingChannelPDUDecode (Communications Toolbox).
When the simulation is complete, the script prints a summary that lists the number of data packets and bytes transmitted and received by the link layer.
Number of PDUs transmitted from link layer: 27 Number of bytes transmitted from link layer: 702 Number of PDUs received at link layer: 4 Number of bytes received at link layer: 112
During the simulation, the chart animation provides a visual indication of the runtime behavior of the algorithm. Note that chart animation slows down performance. To reduce the running time of the example, close the chart before running the script.