¶ BLE Serial
(Substantial portion of technical info was obtained from punchthrough.com website.)
¶ Overview
Bluetooth Low Energy (BLE) was designed as a low power alternative to Bluetooth (now Bluetooth Classic). BLE devices can communicate for years on very small battery power. This is made possible by sending small chunks of data. Compared to the Bluetooth Classic, which is capable of sending streams of long data packets, BLE is more suited to short bursts of short data packets.
¶ How Data is Exchanged Over BLE
Before we begin, let’s cover some of the basic BLE terminology:
Central device (aka master): A device that initiates commands and requests, and accepts responses (e.g. smartphone).
Peripheral device: A device that receives commands and requests, and returns responses (e.g. a BLE sensor).
Connection Interval: The connection interval is the time period during which the central and peripheral devices communicate with each other.
Connection Event: Each instance of communication between two devices is called a Connection Event.
During a connection interval, the master and peripheral exchange packets as shown below:
Master and peripheral exchange SINGLE packets.
Multiple packets can also be exchanged in a connection interval as shown below:
MULTIPLE packets exchanged in a connection interval.
This process can continue until both sides no longer have additional data to send, a package fails to get delivered, or if the maximum connection event duration is reached.
The more packets you can send in a connection, the higher your throughput will be. The maximum packets you can send in an interval is often limited by the maximum connection event duration.
Application data is sent over a BLE connection via the Attribute Protocol (ATT). The ATT provides an interface for discovering, reading, and writing attributes on a connected device. The ATT protocol is combined with the Generic Attribute Profile (GATT). The GATT provides a further definition for the structure of ATT attributes into Services, Characteristics, and Descriptors. The overall structure containing concrete instances of the above elements is known as the Gatt Table.
Profiles are simply a group of one or more services needed to fulfill a use case.
Services are groups of characteristics.
Services are identified by their UUID, which can be 16, 32, or 128 bits. 16-bit and 32-bit UUIDs are assigned by the Bluetooth SIG either as a common service for interoperability or as a proprietary service whose UUID was purchased by a 3rd party. 128-bit UUIDs are unassigned and can be used by anyone.
Characteristics are individual values within a Service.
These values can be read from, written to, or subscribed to. All Characteristic instances include:
- Characteristic Properties (Read, Write, etc.)
- Characteristic Value (pointer)
- Characteristic UUID (16-bit or 128-bit)
Characteristics can share further information via descriptors.
Descriptors (also called Characteristic Descriptors) can be considered metadata for a characteristic and generally include information such as the unit that the characteristic’s value is in (e.g., feet vs. meters) or human-readable description strings. Descriptor UUIDs are either 16 or 128 bits and can be a standard BLE descriptor or a custom descriptor.
SERIAL DATA EXCHANGE
The common approach for proprietary devices is to create serial channels over GATT. This is done by creating a Service that contains an RX Characteristic (write-enabled) and a TX Characteristic (notify/indicate-enabled). The client writes data to the RX Characteristic in a proprietary format, and a response is received from the TX Characteristic.
| MicroBlocks IDE Service UUIDs | |
|---|---|
| #define MB_SERVICE_UUID | "BB37A001-B922-4018-8E74-E14824B3A638" |
| #define MB_CHARACTERISTIC_UUID_RX | "BB37A002-B922-4018-8E74-E14824B3A638" |
| #define MB_CHARACTERISTIC_UUID_TX | "BB37A003-B922-4018-8E74-E14824B3A638" |
| Nordic UART Service (NUS) | |
| #define UART_SERVICE_UUID | "6E400001-B5A3-F393-E0A9-E50E24DCCA9E" |
| #define UART_UUID_RX | "6E400002-B5A3-F393-E0A9-E50E24DCCA9E" |
| #define UART_UUID_TX | "6E400003-B5A3-F393-E0A9-E50E24DCCA9E" |
The Exchanging MTU Size is defined as the maximum size of any packet transmitted between a client and a server. The ATT MTU value should be within the range 23 to 251 inclusive. The default size is 23 bytes (which allows the packet to fit in one LL packet) but the size can be negotiated via the Exchange MTU Request & Response. Using ATT_MTU sizes that are multiples of 23 bytes is ideal.
DO NOT equate MTU size to maximum application data bytes per packet.
The actual BLE packet is longer in size but naturally it includes segments for many important purposes such as CRC and headers for different layers.
It is safe to say that a BLE packet contains a maximum of 20 bytes of application data for BLE v4.0 and v4.1. Bluetooth 4.2 increases that to 244 bytes.
According to punchthrough.com testing, ~50 KB/s data throughput is achievable on newer Android and iOS devices with DLE enabled on the default LE 1M PHY.
¶ Summary Of Blocks
| Short Description | |
|---|---|
 |
Returns TRUE when a BLE Serial is connected. |
 |
Returns bytes read from the BLE Serial port. |
 |
Returns a string read from the BLE Serial port. |
 |
Writes any String or ByteArray to the BLE Serial port. |
¶ Block Descriptions
¶ BLE serial connected
In the context of MicroBlocks BLE Serial Library, the microcontroller device is a PERIPHERAL device. Therefore, it advertises its BLE ID and Services when powered on and will wait for a connection initiated by the CENTRAL device.
In contrast, the CENTRAL device is the one that is scanning for BLE IDs and attempts to gain access to peripheral's advertised services.
This block will return a TRUE statue when a BLE connection is established. Since BLE connections can come and go depending on operational factor, it is a good practise to initiate any BLE actions upon verifying the result of this block.
¶ BLE serial read bytes
This block will read byte data (byte array) from the BLE Serial connection. Each byte will be in the range of 0-255 decimal values.
In the example below, text message "HELLO" is read from the BLE buffer and displayed as decimal values.
One can use a mobile APP to send messages to the MicroBlocks program. See the info at the end of this section on how to establish a connection. Once connected, you can start sending messages.
¶ BLE serial read string
This block will read string data from the BLE Serial connection. Each byte will be a value representing letters, numbers, punctuations.
In the example below, text message "HELLO" is read from the BLE buffer and displayed as string.
One can use mobile APP to send messages to the MicroBlocks program. See the info at the end of this section on how to establish a connection. Once connected, you can start sending messages.
¶ BLE serial write
This block writes a string or a byte array to the BLE Serial connection.
See sample program below.
¶ Sample Program
This demo program will verify that a BLE Serial connection exists.
If it does, it will display a checkmark (YES image) on the LED or OLED screen of the device used. If there is no connection, it will display an X mark (NO image).
In case of a connection, it will transmit a BLE message every five seconds. The message consists of the string "Hello from MB - " followed by a random number between 1 and 9. This is to ensure received message can be distinguished from each other.
Above code can be drag & dropped onto the MicroBlocks IDE to save time copying it.
One can use a mobile APP to receive the sent messages. A popular Android program is the Serial Bluetooth program, which works with both legacy Bluetooth and Bluetooth LE connections.
Install, run the APP and scan for the 3-character ID of your device.
Connect to it. You should see the incoming messages in the display area.
Download Link: BLE Serial Demo