Editor's Note: Part 1 of this series of two-part detailed description of the architecture and functionality of the grid Bluetooth 1.0 protocol. Here, Part 2 describes how to integrate a Bluetooth network into Bluetooth low energy designs using chips and development kits.
Bluetooth networks bring significant network advantages to popular short-range protocols. Part 1 discusses this in detail. However, the specification also brings new design challenges, especially when implementing its model.
The key to overcoming these challenges is to use upgraded development tools to better understand the Bluetooth network. This article describes how to use the selected Bluetooth hardware and software, Development Kit (DK) and Software Development Kit (SDK) to set up and build a Bluetooth grid application.
Bluetooth Grid Development ToolsThe Bluetooth mesh network stack contains a completely new host layer that shares some concepts with the BLE host layer but is not compatible with it. Earlier versions of the Bluetooth grid stack can now be used for engineering development, usually as part of the SDK.
Since the Bluetooth network is a supplement to the Bluetooth core specification, vendors do not need to update their Bluetooth low energy (BLE) physical layer (PHY) or software stack to support it. However, adding a Bluetooth network requires vendors to launch their own stack implementations for their customers.
For example, BLE vendor Nordic Semiconductor has introduced Mesh 's nRF5 SDK . The kit includes a Bluetooth networking stack, an example of selecting drivers, libraries, and grid applications. The SDK's several integrated development environments (IDEs) and compilers, including the working SEGGER Embedded Studio from the suite containing the Segger microcontroller system and CMake.
Since the Bluetooth grid is compatible with all versions of BLE (ie: 4.0, 4.1, 4.2, and 5), Nordic's Grid SDK will eventually work with all its BLE chips. However, the current version is only applicable to the company's latest nRF52 series BLE solution, such as the mid-range Bluetooth 5 compatible nRF52832 chip.
Because there is no change to the BLE PHY or software stack, Bluetooth mesh development can be performed on an existing DK that contains the target device. The recommended DK for nRF52832 is the nRF52 DK (Figure 1).
Figure 1: The Nordic Semiconductor Grid SDK will be used with the nRF52 DK containing the nRF52832 SoC target device. (Source: Nordic Semiconductor)
Grid development requires at least three (preferably more) devices to communicate and simulate a meshed environment. Ideally, several DKs can be used to represent nodes in a grid, but this has the disadvantage of significantly increasing the cost of development hardware. Another method is to use a DK and purchase a tested and verified BLE module (based on the target device) to form an additional node. For Nordic nRF52832 development, Rigado of BMD-300 or Laird of BL652-SA-01-T / R module is a good option.
Cypress Semiconductor has taken a similar approach to Northern Europe. The company is BCM92073X WICED Smart DK offers Bluetooth grid SDK, the DKM-based Cypress BCM20736S Bluetooth v4.1 PHY. Suitable BLE modules for grid development work based on this PHY include Inventek's ISM20736S .
Understanding the modelThe Nordic and Cypress hardware, software, and development tools are accompanied by examples and tutorials to guide developers through the steps to build a simple Bluetooth grid application. But before starting the first design, it helps to permeate the tutorial to understand the unique features of the Bluetooth mesh architecture because it has a major impact on the design process.
These tutorials emphasize that although Bluetooth mesh nodes have four generic types (see Part 1 of the two-part series), each type of function depends on its model. Understanding the model is the key to making full use of the Bluetooth network capabilities.
The Bluetooth grid provides the flexibility needed to build new grid applications because developers can build models that give the device many custom behaviors. The model defines the required states, messages that act on these states, and related behaviors. All communications over the mesh network are facilitated by messages.
The status is the value that represents the status of the element. An element is an addressable entity of a device or node. Each device has at least one (primary) element and may have one or more secondary elements. The number and structure of elements will not change throughout the life of the node. The elements of the "exposed" state are called servers. The element "access" status is called the client.
Importantly, there are three types of models; servers, clients, and controls. The server model consists of one or more states that span one or more elements. It defines a set of mandatory messages that can be sent or received, element behavior when sending and receiving messages, and any other behavior that occurs after sending or receiving messages.
The client model defines a set of messages that clients use to request, change, or "consume" the corresponding server state, as defined by the server model. The client model has no status.
The control model can combine client model capabilities (to communicate with other server models) and server model capabilities (to communicate with other client models). The control model may also contain control logic - a set of rules and behaviors that are used to coordinate the interaction between the control model and other models connected to the control model (Figure 2).
Figure 2 shows the component model structure of a Bluetooth mesh device implementing a control model. Device C can act as a client (message X, Y and Z and messages R, S and T respectively) and a client model (in device D) as a server and server model (in devices A and B) (messages are supported) A, B and C). (Source: Bluetooth SIG)
To illustrate the use of the model in practical applications, consider a power strip that includes two separate power outlets, each of which controls power output and integrates a BLE radio to allow connection to a Bluetooth network.
The device (power strip) has two elements that represent two power outlets. The function of each element is defined by a generic power level server model that defines a set of states on the server and a set of messages that operate on those states. A generic power level setting message can be sent to the device to control the output power. The message is sent to a socket element.
Sockets can also be controlled by common devices (such as dimmers) that implement a generic client model. The model sets the desired level to zero, maximum, or a value between the two. The power of the outlet is controlled through the state binding. In each power outlet, the universal power supply's actual status is tied to the universal level status. The generic client sends generic messages to the generic server. The generic level status changes, which in turn (through defined bindings) changes the general power actual state of the control power output.
Because the elements can report status, each socket can report the power level and the energy consumption of the device plugged into the socket. Energy consumption is reported using messages defined by the Sensor Server model.
Building a Bluetooth mesh networkAssume that developers already understand the Bluetooth grid architecture and BLE development (see the Digi-Key article: " Bluetooth 4.1, 4.2, and 5 compatible Bluetooth low-power SoCs and tools to meet the IoT challenge " for general BLE design For more information) and equipped with Bluetooth Grid SDK, Host SDK, DK and add-on modules or DK to build the network, developers can configure the Bluetooth grid implementation relatively easily.
The first step is to build a grid stack. In the case of Northern Europe, the stack is built using the selected IDE. For example, using SEGGER Embedded Studio, build the stack by using an example included in the Bluetooth mesh SDK (for example, the "light switch" example) and compiling with the IDE.
The target PHY on the DK is then erased and reprogrammed with the compiled Bluetooth mesh stack and BLE stack. Once the stack is programmed and verified, the SDK can be used to set up and establish a mesh network.
Configuration: Nordic's development tools include configuration application programming interfaces (APIs) for adding new devices to the mesh network. Provisioning is handled by vendors (devices that are already connected to the network and previously configured for provisioning tasks) to provide new devices with the information they need to join the mesh network. Initially, the device provides a network key, an address, and a device key for establishing a secure channel for configuration after configuration.
The API allows the developer to begin listening for broadcast beacons sent on one of the three advertising channels of the BLE (or vendor - equipment to be added to the network) node. The Bluetooth grid uses BLE's advertising channels instead of 37 full-bandwidth data channels to transmit and receive messages. Incoming link requests on the channel are automatically accepted.
After the link is established, it is authenticated using an out-of-band (OOB) method to ensure that the device that joins the network is the intended target. Using the OOB method can reduce the chance of the device being monitored for "man-in-the-middle" attacks when the BLE spectrum is allocated. The API event then provides the device with configuration data and device keys.
Configuration: Nordic's Light Switch application (included in the SDK) shows how to develop an application with the supplier and supplier roles. In the demo, a light switch client model (switch) is the supplier, and a light switch server model (bulb) is the supplier.
Nordic's example takes full advantage of the fact that the simplest server in the Bluetooth network specification is the Generic OnOff server, which means that the server is on or off. For example, the simplest client is the generic OnOff client, which can control the generic OnOff server through messages defined by the generic OnOff model.
When this server model receives a GET or (reliable) SET message from the client model, it will respond with the current value of the OnOff state. This allows the client to understand the server status (Figure 3).
Name Definition Opcode Description Parameter Parameter Size Group SIMPLE_ON_OFF_OPCODE_SET0xc1 Set current ON/OFF status New status 1 byte Get SIMPLE_ON_OFF_OPCODE_GET to 0xC2 Get current ON/OFF status N / A No parameter SET REJECTION SIMPLE_ON_OFF_OPCODE_SET_UNRELIABLE 0xc3 Set Current On/Off Status New Status 1 byte Status SIMPLE_ON_OFF_OPCODE_STATUS0xc4 Contains current status Current status 1 byteFigure 3: Messages and ATT opcodes supported by the generic OnOff model. (Source: Nordic Semiconductor)
The configuration server is used to represent the mesh network configuration of the device and is a mandatory requirement of the Bluetooth mesh node. The configuration server handles communication with the configuration client (controlled by the configurator) and instructions from the configuration client.
Configuration starts after the configuration is complete. The supplier reads the supplier's constituent data to identify the device's metadata and which models are bound to the elements in the device. Next, add and bind application and/or network keys to different models (Figure 4).
Figure 4: Flowchart for configuring and configuring the nRF5 SDK for Mesh. The "nrf_mesh ..." annotation is an API function. (Source: Nordic Semiconductor)
Adding more devices to the network is just a matter of repeating the provisioning and configuration process for each new node.
Publish and subscribe: The final stage in setting up and building an initial application is to configure the release status of the model. For example, the address used to publish status events, what key to use, what "time to live" (TTL) value to use, and to set up subscriptions.
Messages are sent from the publishing address of each model. For example, publishing is used by the sensor nodes reporting data periodically. Messages can only be issued once or repeatedly and sent to unicast, groups, or virtual addresses (see section 1 of this article). The client model also uses publish to send messages to the server model.
The configuration of publishing related state is usually controlled by the configurator through the configuration model.
When using the Nordic SDK, messages are published using the "access_model_publish()" API function, which publishes messages based on the publication model's publishing settings (interval, target).
Subscriptions allow the model to listen for incoming messages from a specific address. For example, this can be used to listen for periodic messages issued from sensor nodes. The Nordic SDK allows models to subscribe to addresses by using the "access_model_subscription_list_alloc()" API function to allocate a subscription list.
Note that when using the client model, you do not need to subscribe to the address of the sending message to receive replies to these messages. Subscriptions are only used to receive unsolicited messages from nodes.
During the development process, connecting non-Bluetooth grid-enabled devices to the Bluetooth grid may help. An example may be smart phones that developers want to use to control prototype smart lighting grid applications. The interaction between the mobile phone and the mesh network is achieved through the generic attribute configuration file (GATT) interface of the smartphone and the node device in the Bluetooth stack, instead of the Bluetooth mesh network stack.
in conclusionThe Bluetooth grid adds new features to BLE applications. However, because it is not part of the original core specification, the adoption of grids has introduced some trade-offs and added some complexity to the design process. Developers who are familiar with designing using the Bluetooth protocol stack are an advantage for those without knowledge, but even for experienced engineers, implementing a Bluetooth network requires learning a new architecture and understanding its nuances. , such as status, elements, and models.
By working with vendors such as Nordic Semiconductor or Cypress Semiconductor, design challenges can be mitigated. These vendors have now released a Bluetooth grid stack to complement their proven BLE solution. The stack comes with a specially designed software development kit that allows developers to use their familiar chips, firmware, and design tools to accelerate the learning process of designing Bluetooth grid applications.
reference" Mesh Profile ", Bluetooth Specification v1.0, Bluetooth SIG, July 2017.
Ring And Fork Type Insulated Terminals
Ring And Fork Type Insulated Terminals,High quality insulated terminal,copper tube terminal
Taixing Longyi Terminals Co.,Ltd. , https://www.lycopperlugs.com