How to Use Bluetooth® LE Connections
This section provides information about developing software for a Bluetooth® LE-capable host that needs to communicate with the device using Bluetooth® Low Energy (Bluetooth® LE). The device acts as a Bluetooth® LE server/peripheral, and the host acts as a client/central.
About GATT Characteristics
Messages are exchanged with the device using a service named “DynaFlex”. The UUID for this service is 0c ba 14 b7 ff 24 47 b0 be 09 26 44 05 38 53 0c in big endian order. This service contains the following characteristics.
Messages are sent to the device using a characteristic named “Message From Host”. The UUID for this service is 47 f0 5f fa 59 09 49 69 bc 57 25 0d 47 e8 74 e5 in big endian order. This characteristic supports the Write Request Attribute PDU Method. The value of this characteristic has a variable length. The maximum length is 244 bytes. The host must have performed secure connections pairing with the device before the device will allow it to write to this characteristic.
Messages are sent to the host using a characteristic named “Message To Host”. The UUID for this service is fe d4 91 18 c7 e2 4a 61 9e d5 e6 dd 65 c3 07 1b in big endian order. This characteristic only supports the Handle Value Notification Attribute PDU Method. The value of this characteristic has a variable length. The maximum length is 244 bytes. The host must have secure connections pairing with the device before the device will send notifications on this characteristic. The host must also enable notifications to be sent from this characteristic before the device will start sending messages on it.
Messages are exchanged with these characteristics using the DynaFlex Bluetooth® LE protocol. This protocol is described in the next section.
DynaFlex Bluetooth® LE protocol
This protocol was designed to meet the following goals:
Exchange messages with the device.
Maximize throughput.
Allow the side receiving a message to detect if a message is partially or completely dropped.
Bluetooth® LE attribute protocol transmits data in protocol data units (PDUs). The maximum size of a PDU is determined by the maximum transmission unit (MTU) agreed on between the host and the device. The MTU is typically set to the minimum of the host and device’s ATT_MTU size. DynaFlex’s ATT_MTU size is 247 bytes. Most host’s ATT_MTU sizes are larger than 247 bytes, so the MTU size agreed on between most hosts and DynaFlex’s is 247 bytes. Since application messages can be much larger than 247 bytes, application messages need to be able to be sent using multiple PDUs. Note that the minimum ATT_MTU allowed for all hosts and devices is 23 bytes. To maximize throughput, all messages should be sent using the maximum MTU size possible. This protocol allows large application messages to be sent using multiple PDUs. The protocol format for sending and receiving messages is the same for both the host and device. The only difference is the characteristic used. Since the attribute opcode and attribute handle use 3 bytes of the MTU size the attribute value length for the message from host and message to host characteristics is limited to 247 - 3 = 244 bytes.
When a PDU is received in the application layer, it is guaranteed to be correct since Bluetooth® LE does error detection and retries in the lower layers. However, PDUs can be completely dropped if the device goes out of range of the host or bad interference occurs. So host applications should be written with appropriate error detection and handling to account for these potential drops.
Protocol field definitions The following is the definition of each byte of a characteristic’s value for the DynaFlex Bluetooth® LE protocol:
The first byte of the characteristic value is the message counter for every PDU. The message counter should be zero for the first message sent after every new BLE connection is established and should increase by one after sending every message. If its’ value is 0xff before it increments, it should have a value of zero after incrementing. All PDUs of a single message should have the same value for the message counter. The side receiving the message can use this counter to help detect if some PDUs of a message or if an entire message is dropped. The message counter for the message from host direction should be completely independent from the message counter for the message to host direction.
The second byte of the characteristic value is the PDU counter for every PDU. The PDU counter should be zero for the first PDU of a message sent and should increase by one after sending every PDU of that message. If its’ value is 0xff before it increments, it should have a value of one instead of zero after incrementing. This is because the value of zero is reserved to always be used for the first PDU of a message. If the device receives a PDU counter of zero while it is still expecting more PDUs for an existing message, it shall discard any message that it is currently receiving and start receiving the new message. The first PDU of a message has a different protocol format than the remaining PDUs. The side receiving the message shall use this counter to help detect if some PDUs of a message are dropped. The PDU counter for the message from host direction should be completely independent from the PDU counter for the message to host direction.
If the PDU counter is zero indicating that this is the first PDU of a message, then the following paragraphs define the remaining bytes of the PDU, otherwise the remaining bytes of the PDU starting with the third byte contain the next portion of the application message.
If the PDU counter is zero indicating that this is the first PDU of a message, then the third byte of the PDU contains the protocol control byte (PCB). The protocol control byte is reserved and should always be set to zero. This byte may be used in the future to extend the protocol.
If the PDU counter is zero indicating that this is the first PDU of a message, then the fourth, fifth, sixth and seventh byte of the PDU contain the message length in big endian order. This is the length of the entire message not just the portion contained in the current PDU. The receiver of the message shall use this value to determine when it has received all the PDUs of a message.
If the PDU counter is zero indicating that this is the first PDU of a message, the remaining bytes of the PDU starting with the eighth byte contain the first portion of the application message. If the entire application message fits into one PDU then it contains all the application message.
Example PDU sequence
The following is an example of sending two application messages in a row where the first 9-byte message fits into a single PDU and the second 512-byte message requires 3 PDUs.
00
00
00
00 00 00 09
9 bytes
01
00
00
00 00 02 00 (512 bytes)
237 bytes
01
01
242 bytes
01
02
33 bytes
Protocol implementation recommendations:
Last updated