1. Introduction
Eddystone Protocol Specification
Common Elements
Every Eddystone frame type must contain the following PDU data types:
The Complete List of 16-bit Service UUIDs as defined in The Bluetooth Core Specification Supplement (CSS) v5, Part A, § 1.1. The Complete List of 16-bit Service UUIDs must contain the Eddystone Service UUID of 0xFEAA. This is included to allow background scanning on iOS devices. The Service Data data type, Ibid., § 1.11. The Service Data - 16 bit UUID data type must be the Eddystone Service UUID of 0xFEAA. The specific type of Eddystone frame is encoded in the high-order four bits of the first octet in the Service Data associated with the Service UUID. Permissible values are:
Frame Type High-Order 4 bits Byte Value UID 0000 0x00 URL 0001 0x10 TLM 0010 0x20 EID 0011 0x30 RESERVED 0100 0x40 The four low-order bits are reserved for future use and must be 0000.
Note: although the core Bluetooth data type are defined in the standard as little-endian, Eddystone's multi-value bytes defined in the Service Data are all big-endian.
An example frame type may look like:
Byte offset Value Description Data Type 0 0x02 Length Flags. CSS v5, Part A, § 1.3 1 0x01 Flags data type value 2 0x06 Flags data 3 0x03 Length Complete list of 16-bit Service UUIDs. Ibid. § 1.1 4 0x03 Complete list of 16-bit Service UUIDs data type value 5 0xAA 16-bit Eddystone UUID 6 0xFE ... 7 0x?? Length Service Data. Ibid. § 1.11 8 0x16 Service Data data type value 9 0xAA 16-bit Eddystone UUID 10 0xFE ... With subsequent bytes comprising the frame-specific Service Data.
The individual frame types are listed below.
Eddystone-UID The Eddystone-UID frame broadcasts an opaque, unique 16-byte Beacon ID composed of a 10-byte namespace and a 6-byte instance. The Beacon ID may be useful in mapping a device to a record in external storage. The namespace portion of the ID may be used to group a particular set of beacons, while the instance ID identifies individual devices in the group. The division of the ID into namespace and instance components may also be used to optimize BLE scanning strategies, e.g. by filtering only on the namespace.
Eddystone-URL The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet.
Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast the URL https://goo.gl/Aq18zF, then any client that received this packet could choose to visit that url.
The Eddystone-URL frame forms the backbone of the Physical Web, an effort to enable frictionless discovery of web content relating to one’s surroundings. Eddystone-URL incorporates all of the learnings from the UriBeacon format from which it evolved.
Eddystone-TLM The Eddystone-TLM frame broadcasts telemetry information about the beacon itself such as battery voltage, device temperature, and counts of broadcast packets.
Eddystone-EID The Eddystone-EID frame broadcasts an encrypted ephemeral identifier that changes periodically at a rate determined during the initial registration with a web service. The broadcast ephemeral ID can be resolved remotely by the service with which it was registered, but to other observers appears to be changing randomly. This frame type is intended for use in security and privacy-enhanced devices.
Warning: Display title "STM32WBA Bluetooth<sup>®</sup> LE – Beacon" overrides earlier display title "STM32WBA Bluetooth<sup>®</sup> LE – Beacon Project".
2. Beacon Profile
Beacon Profile is a proprietary Generic Attribute Profile (GATT) based low-energy profile defined by the Bluetooth® Special Interest Group[1]
The beacon Profile family can be divided in main family, the Eddystone (Google) beacon and the iBeacon (Apple ).
- Eddystone is an open protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages. It describes several different frame types that may be used individually or in combinations to create beacons that can be used for a variety of applications.
- iBeacon is a protocol developed by Apple and introduced at the Apple Worldwide Developers Conference in 2013.iBeacon is based on Bluetooth low energy proximity sensing by transmitting a universally unique identifier[4] picked up by a compatible application or operating system.
Beacon widely used for:
- Advertising: sending a packet of information that contains a Universally Unique Identifier (UUID), used to trigger events specific to that beacon.
- Notification and interaction: associated with the artpieces in a museum to encourage further interaction.
- Indoor navigation: indoor positioning with beacons falls into three categories. Implementations with many beacons per room, implementations with one beacon per room, and implementations with a few beacons per building.
- Healthcare: with the device tracking capabilities of Bluetooth beacons, in-home patient monitoring is possible, person's movements and activities can be tracked in their home. Bluetooth beacons are a good alternative to in house cameras due to their increased level of privacy.
- Tracker: various animals, people or objects finders.
| Bluetooth® LE Beacon Profile & STM32WBA |
|---|
 |
3. Eddystone Protocol Specification
Every Eddystone frame type must contain the following PDU data types:
- The Complete List of 16-bit Service UUIDs as defined in The Bluetooth Core Specification Supplement (CSS) v5, Part A, § 1.1. The Complete List of 16-bit Service UUIDs must contain the Eddystone Service UUID of 0xFEAA. This is included to allow background scanning on iOS devices.
- The Service Data data type, Ibid., § 1.11. The Service Data - 16 bit UUID data type must be the Eddystone Service UUID of 0xFEAA.
The specific type of Eddystone frame is encoded in the high-order four bits of the first octet in the Service Data associated with the Service UUID. Permissible values are:
| Eddystone Frame Type | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The four low-order bits are reserved for future use and must be 0000.
Note: although the core Bluetooth data type are defined in the standard as little-endian, Eddystone's multi-value bytes defined in the Service Data are all big-endian.
An example frame type may look like:
| Eddystone frame type example | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
With subsequent bytes comprising the frame-specific Service Data.
The individual frame types are listed below.
3.1. Eddystone-UID
See https://github.com/google/eddystone/tree/master/eddystone-uid
The Eddystone-UID frame broadcasts an opaque, unique 16-byte Beacon ID composed of a 10-byte namespace and a 6-byte instance.
The Beacon ID may be useful in mapping a device to a record in external storage.
The namespace portion of the ID may be used to group a particular set of beacons, while the instance ID identifies individual devices in the group.
The division of the ID into namespace and instance components may also be used to optimize BLE scanning strategies, e.g. by filtering only on the namespace.
3.1.1. Frame Specification
The UID frame is encoded in the advertisement as a Service Data block associated with the Eddystone service UUID. The layout is:
| Eddystone UID frame | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
3.1.2. Field Notes
- The length of this frame is fixed and takes up the full 31 bytes of the ADV packet.
The value of the Service Data Length byte must be 0x17.
Existing UID implementations that truncate the frame to omit the RFU bytes will use 0x15, but in future should include the RFU bytes and the full length. - The Ranging Data is the Tx power in dBm emitted by the beacon at 0 meters.
Note that this is different from other beacon protocol specifications that require the Tx power to be measured at 1 m.
The value is an 8-bit integer as specified by the Tx Power Level Characteristic and ranges from -100 dBm to +20 dBm to a resolution of 1 dBm.
See Transmit Power below for more details. - The 10-byte Namespace ID component is unique self-assigned beacon ID namespace.
See UID Construction below for recommendations on generating this unique namespace. - The 6-byte Instance ID component is unique within the namespace.
See UID Construction below for recommendations on ensuring beacon ID uniqueness.
3.1.3. Tx Powers
Tx power is the received power at 0 meters measured in dBm. The value may range from -100 dBm to +20 dBm at a resolution of 1 dBm.
The best way to determine the precise value to put into this field is to measure the actual output of your beacon from 1 meter away and then add 41 dBm to that. 41dBm is the signal loss that occurs over 1 meter.
3.1.4. UID Construction
An Eddystone-UID beacon ID is 16 bytes long, consisting of a 10-byte namespace component and 6-byte instance component.
The namespace is intended to ensure ID uniqueness across multiple Eddystone implementers and may be used to filter on-device scanning for beacons.
Two methods for generating a unique 10-byte namespace are recommended:
- a truncated hash of your FQDN:
Produce a SHA-1 hash of a fully-qualified domain name that you own.
If you desire additional obscurity and/or additional namespaces, you may wish to use a random subdomain under this FQDN.
Select the first 10 bytes from that hash. - an elided UUID:
Generate a version 4 UUID then remove bytes 5 - 10 (inclusive).
For example: from this UUID: 8b0ca750-e7a7-4e14-bd99-095477cb3e77 remove these bytes: e7a7-4e14-bd99.
This produces the following namespace: 8b0ca750095477cb3e77.
This option may be useful if you interleave Eddystone-UID with other UUID-based frame formats.
It allows you to relate your Eddystone-UID namespace to the UUID in the other frames by deriving one from the other.
3.1.5. Instance ID
The 6-byte instance portion of the Eddystone-UID beacon ID may be assigned via any method suitable for your application.
They may be random, sequential, hierarchical, or any other scheme.
3.2. Eddystone-URL
https://github.com/google/eddystone/tree/master/eddystone-url
The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet.
Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast the URL https://goo.gl/Aq18zF, then any client that received this packet could choose to visit that url.
The Eddystone-URL frame forms the backbone of the Physical Web, an effort to enable frictionless discovery of web content relating to one’s surroundings. Eddystone-URL incorporates all of the learnings from the UriBeacon format from which it evolved.
3.2.1. Frame Specification
The UID frame is encoded in the advertisement as a Service Data block associated with the Eddystone service UUID. The layout is:
| Eddystone URL frame | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
3.2.2. Tx Powers
Tx power is the received power at 0 meters measured in dBm. The value may range from -100 dBm to +20 dBm at a resolution of 1 dBm.
The best way to determine the precise value to put into this field is to measure the actual output of your beacon from 1 meter away and then add 41 dBm to that. 41dBm is the signal loss that occurs over 1 meter.
The value is a signed 8 bit integer as specified by TX Power Level Bluetooth Characteristic.
Examples
- The value 0x12 is interpreted as +18dBm
- The value 0xEE is interpreted as -18dBm
3.2.3. URL Scheme Prefix
The URL Scheme Prefix byte defines the identifier scheme, an optional prefix and how the remainder of the URL is encoded.
| Eddystone URL Scheme Prefix | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
3.2.4. Eddystone-URL HTTP URL encoding
The HTTP URL scheme is defined by RFC 1738, for example https://goo.gl/S6zT6P, and is used to designate Internet resources accessible using HTTP (HyperText Transfer Protocol).
The encoding consists of a sequence of characters. Character codes excluded from the URL encoding are used as text expansion codes. When a user agent receives the Eddystone-URL the byte codes in the URL identifier are replaced by the expansion text according to the table below.
| Eddystone-URL HTTP URL encoding | |||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Note:
- URLs are written only with the graphic printable characters of the US-ASCII coded character set.
The octets 00-20 and 7F-FF hexadecimal are not used.
See “Excluded US-ASCII Characters” in RFC 2936. - Range 07-13 define the same top level domains as 00-06 without a /.
3.3. Eddystone-TLM
https://github.com/google/eddystone/tree/master/eddystone-tlm
The Eddystone-TLM frame broadcasts telemetry information about the beacon itself such as battery voltage, device temperature, and counts of broadcast packets.
Eddystone beacons may transmit data about their own operation to clients.
This data is called telemetry and is useful for monitoring the health and operation of a fleet of beacons.
Since the Eddystone-TLM frame does not contain a beacon ID, it must be paired with an identifying frame which provides the ID, either of type Eddystone-UID or Eddystone-URL.
See Interleaving Telemetry for details.
TLM frames may be broadcast either in the clear, like UID and URL frames, or, when a beacon has been configured as Eddystone-EID, encrypted with the identity key set during the EID configuration.
When broadcast in the clear there is no message integrity validation and you should design your applications to be tolerant of the open nature of such a broadcast.
3.3.1. Unencrypted TLM Frame Specification
https://github.com/google/eddystone/blob/master/eddystone-tlm/tlm-plain.md
The TLM frame is encoded in the advertisement as a Service Data block associated with the Eddystone service UUID. The layout is:
| Unencrypted TLM Frame Specification | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
All multi-byte values are big-endian.
3.3.2. Field Notes
- The length of this frame is fixed and must be truncated after the "time since power-on" bytes.
The value of the Service Data Length byte must be 0x11. - TLM version allows for future development of this frame type.
At present the value must be 0x00. - Battery voltage is the current battery charge in millivolts, expressed as 1 mV per bit.
If not supported (for example in a USB-powered beacon) the value should be zeroed. - Beacon temperature is the temperature in degrees Celsius sensed by the beacon and expressed in a signed 8.8 fixed-point notation.
If not supported the value should be set to 0x8000, -128 °C. - ADV_CNT is the running count of advertisement frames of all types emitted by the beacon since power-up or reboot, useful for monitoring performance metrics that scale per broadcast frame.
If this value is reset (e.g. on reboot), the current time field must also be reset. - SEC_CNT is a 0.1 second resolution counter that represents time since beacon power-up or reboot.
If this value is reset (e.g. on a reboot), the ADV count field must also be reset.
3.3.3. Interleaving Telemetry
Telemetry frames should be interleaved with an identifying frame type (e.g. Eddystone-UID or Eddystone-URL).
The TLM frame depends on the client to associate it with the identifying frames via the device address (since no beacon ID exists in the TLM frame).
Thus it is important that a beacon that rotates or randomizes its device address uses the same device address for some period that allows for multiple ID frames and multiple TLM frames to be broadcast from the same device address.
You may decide to interleave one TLM frame for each ID frame, or use some lower ratio depending on how critical the TLM data is for your application.<fr>
For example, if your application is using the TLM for fleet management, it may be satisfied receiving one TLM frame per day, so your beacons deployed in a high traffic area may broadcast TLM only once per minute or longer, giving a high probability that a client receives the TLM frame and transmits it to your service once per day.
In a low-traffic environment such an application may require a higher TLM rate.
Finally, if your application uses TLM to (e.g.) supply up-to-the-minute runtime status information to an end user, you may wish to interleave TLM with ID frames 1 to 1.
3.4. Eddystone-EID
https://github.com/google/eddystone/tree/master/eddystone-eid
The Eddystone-EID frame broadcasts an encrypted ephemeral identifier that changes periodically at a rate determined during the initial registration with a web service.
The broadcast ephemeral ID can be resolved remotely by the service with which it was registered, but to other observers appears to be changing randomly.
This frame type is intended for use in security and privacy-enhanced devices.
The table below describes the structure of Heart Rate Sensor services:
| Bluetooth® LE Heart Rate Service specification | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Heart Rate Profile is a combination of a Heart Rate Collector and a Heart Rate Sensor to connect and exchange data in different applications.
The GAP - Generic Access Profile defines and manages advertising and connection.
| Collector Central device and Sensor Peripheral device |
|---|
 |
The GATT - Generic Attribute Profile defines and manages in/out data exchange.
| Collector GATT client device and Sensor GATT service device |
|---|
 |
| Example of flow diagram between STM32WBA & ST BLE Toolbox |
|---|
 |
3.5. STMicrolectronics Manufacturer Advertising Data
At start up, Heart rate Sensor application starts Fast Advertising(80ms/100ms) including the STMicroelectronics Manufacturer Advertising Elements as described below:
| Heart Rate Sensor STMicroelectronics Manufacturer Advertising data | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Advertising is switched to Low Power advertising (1s/2.5s) after 60s
3.6. On board buttons configuration
| HR Sensor Application Nucleo-WBA buttons configuration | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
4. Requirements
4.1. Software and system requirements
The software required are the following (minimum IDEs version):
- IAR Embedded Workbench for ARM (EWARM) toolchain V??
- RealView Microcontroller Development Kit (MDK-ARM) toolchain V??
- STM32CubeIDE toolchain V?? [2].
Programmer:
- STM32CubeProgrammer[3] : To flash the board with an already generated binary
4.2. Hardware requirements
NUCLEO-WBA5 [4] is necessary to install the application.
| Hardware platform illustration |
|---|
 |
4.3. Collector applications compatible
The STM32CubeWBA Heart Rate Sensor project is compatible with the following collector:
5. STM32WB Heart Rate Sensor example description
5.1. Project directory
The "BLE_HeartRate" application is available by downloading STM32CubeWBA MCU Package[5]. LINK TO UPDATE
| Heart Rate project directory |
|---|
5.2. Project description
5.2.1. Structure
Software project structure with the most important parts:
| Heart Rate project structure |
|---|
|
WARNING: Do not modify the files in Middlewares folder |
5.2.2. Application initialization
The different steps of the application initialization are described below:
| Heart Rate project initialization |
|---|
5.2.3. GAP and GATT initialization and interaction
and 
The Bluetooth LE Heart Rate Sensor application initialization is done within app_ble.c
- Initialize the BLE stack - initialize the device as peripheral - configure and start advertising: ADV parameters, local name, UUID - APP_BLE_init()
- Call the services controller initialization SVCCTL_Init() - svc_ctl.c
- Manage the GAP event - SVCCTL_App_Notification()
- HCI_LE_CONNECTION_COMPLETE - provides information of the connection interval, slave latency, supervision timeout
- HCI_LE_CONNECTION_UPDATE_COMPLETE- provides the new information of the connection
- HCI_DISCONNECTION_COMPLETE - informs the application about the link disconnection and the reason
The Services management is done by the service controller, svc_ctl.c
- Initialize the number of registered handler - SVCCTL_Init()
- Manage events - SVCCTL_UserEvtRx()- from the BLE Host Stack and redirect them to the gap event handler - SVCCTL_App_Notification
The application level of the Heart Rate Sensor is done with hrs_app.c:
- Initialization of the services:
- Heart Rate Service - HRS_Init() - hrs.c
- Initialization of the context of the application
- Measurement value flags support
- Body sensor location - HRS_BODY_SENSOR_LOCATION_HAND
- Receive notification from the Heart Rate Service - HRS_Notification()
- When Heart rate measurement characteristics are enabled by the remote, simulate every 1 s the Heart Rate Measure (HRS_APP_Measurement) and increase the energy expended to transfer to the remote device (collector) - HRS_UpdateValue()
The Heart Rate Service hrs.c manages the specification of the service:
- Service Init - HRS_Init()
- Register Heart Rate Event Handle to Service Controller - SVCCTL_RegisterSvcHandler(HRS_EventHandler);
- Initialize Service UUID – add Heart Rate service as Primary services
- Initialize Heart rate measurement characteristic
- Initialize Body Sensor location characteristic
- Manage the GATT event from BLE Stack - HRS_EventHandler()
- ACI_GATT_WRITE_PERMIT_REQ_VSEVT_CODE
- Reception of a Write Command: HR Control Point Characterictic Value
- Send an aci_gatt_write_response() with an OK or KO status.
- Notify the application to Reset Energy Expended - HRS_Notification(HRS_RESET_ENERGY_EXPENDED_EVT)
- Reception of a Write Command: HR Control Point Characterictic Value
- ACI_GATT_ATTRIBUTE_MODIFIED_VSEVT_CODE
- Reception of an attribute modification - HR Measurement Characteristics Description Value : ENABLE or DISABLE Notification
- Notify application of the Measurement Notification - HRS_Notification(HRS_NOTIFICATION_ENABLED/DISABLED)
- Reception of an attribute modification - HR Measurement Characteristics Description Value : ENABLE or DISABLE Notification
- ACI_GATT_WRITE_PERMIT_REQ_VSEVT_CODE
| Heart Rate Sensor software module interaction |
|---|
5.3. Build and install
Follow the steps described in Bluetooth® LE Build and Install Application page, applying them for STM32WBA BLE_HeartRate project.
5.4. How to use
Once the BLE Heart Rate application is installed on the STM32WBA platform, launch ST BLE Sensor or ST BLE ToolBox smartphone application. Then, scan and connect the device called HR_XX (where XX is replaced by the last byte of the BD address) to the application.
Once the Bluetooth® LE connection is established and the notification enabled by the smartphone:
- Heart Rate measurement is provided to remote every 1 s.
- thanks to the timer server and the task manager
BLE Heart Rate application support the pairing procedure
- Pressing B2 while not connected allows to clear the security database
- Pressing B2 while connected allows to request pairing
With the WBA5x.Nucleo board, it is also possible to change RF PHY modulation
- Pressing B1 while connected allows to switch between 2 Mbits and 1 Mbits PHY
BLE Heart Rate application allows other actions on button:
- Pressing B1 while not connected allows to restart the fast advertising
- Pressing B3 while connected allows to update the connection interval
5.5. Optimize low power
The project is delivered with the full system low-power enabled:
- no debug trace
- no debugger
It is possible to enable/disable the Low Power feature within app_conf.h
/******************************************************************************
* Low Power
*
* When CFG_FULL_LOW_POWER is set to 1, the system is configured in full
* low power mode. It means that all what can have an impact on the consumptions
* are powered down.(For instance LED, Access to Debugger, Etc.)
*
* When CFG_FULL_LOW_POWER is set to 0, the low power mode is not activated
*
******************************************************************************/
#define CFG_FULL_LOW_POWER (1)
5.6. UART debug trace
Thanks to the debug log via UART interface LINK TO UPDATE?, it is possible to trace the application project.
To enable the traces within the project, enable them within app_conf.h as described below:
/**
* Enable or Disable traces in application
*/
#define CFG_DEBUG_APP_TRACE (0)
Debugger can also be supported by enabling it within app_conf.h as described below:
/**
* User interaction
* When CFG_LED_SUPPORTED is set, LEDS are activated if requested
* When CFG_BUTTON_SUPPORTED is set, the push button are activated if requested
* When CFG_DBG_SUPPORTED is set, the debugger is activated
*/
[...]
#define CFG_DBG_SUPPORTED (1)
| Heart Rate Sensor - Initialization phase | Connected Phase |
|---|---|
==>> Start Ble_Hci_Gap_Gatt_Init function
Success: hci_reset command
Success: aci_hal_write_config_data command - CONFIG_DATA_PUBADDR_OFFSET
Public Bluetooth Address: 00:80:e1:2a:7c:ea
Success: aci_hal_write_config_data command - CONFIG_DATA_IR_OFFSET
Success: aci_hal_write_config_data command - CONFIG_DATA_ER_OFFSET
Success: aci_hal_set_tx_power_level command
Success: aci_gatt_init command
Success: aci_gap_init command
Success: aci_gatt_update_char_value - Device Name
Success: aci_gatt_update_char_value - Appearance
Success: hci_le_set_default_phy command
Success: aci_gap_set_io_capability command
Success: aci_gap_set_authentication_requirement command
Success: aci_gap_configure_whitelist command
==>> End Ble_Hci_Gap_Gatt_Init function
Services and Characteristics creation
Success: aci_gatt_add_service command: HRS
Success: aci_gatt_add_char command : HRME
Success: aci_gatt_add_char command : BSL
Success: aci_gatt_add_char command : HRCP
Success: aci_gatt_update_char_value BSL command
Success: aci_gatt_add_service command: DIS
Success: aci_gatt_add_char command : MANS
Success: aci_gatt_add_char command : MNBS
Success: aci_gatt_add_char command : SNS
Success: aci_gatt_add_char command : HRS
Success: aci_gatt_add_char command : FRS
Success: aci_gatt_update_char_value MANS command
Success: aci_gatt_update_char_value MNBS command
Success: aci_gatt_update_char_value SNS command
Success: aci_gatt_update_char_value HRS command
Success: aci_gatt_update_char_value FRS command
End of Services and Characteristics creation
==>> aci_gap_set_discoverable - Success
==>> Success: Start Advertising
|
>>== HCI_LE_CONNECTION_COMPLETE_SUBEVT_CODE - Connection handle: 0x0001
- Connection established with @:62:f1:e7:ab:a6:18
- Connection Interval: 48.75 ms
- Connection latency: 0
- Supervision Timeout: 5000 ms
>>== HCI_LE_CONNECTION_UPDATE_COMPLETE_SUBEVT_CODE
- Connection Interval: 7.50 ms
- Connection latency: 0
- Supervision Timeout: 5000 ms
>>== HCI_LE_CONNECTION_UPDATE_COMPLETE_SUBEVT_CODE
- Connection Interval: 48.75 ms
- Connection latency: 0
- Supervision Timeout: 5000 ms
ACI_GATT_ATTRIBUTE_MODIFIED_VSEVT_CODE HRS_NOTIFICATION_ENABLED
|
6. Heart Rate Collector - smartphone application
6.1. ST BLE ToolBox application
Once the BLE Heart Rate application is installed on the STM32WBA platform, launch the ST BLE ToolBox smartphone application. The application starts scanning and allows to see advertisement data or to connect to the device. Once the device is connected bpm and kcal measurements are displayed in real time.
| BLE Heart Rate application on ST BLE ToolBox | ||
|---|---|---|
7. References