Embed Size (px)
Citation preview
BLUETOOTH® 4.0 HEART RATE SENSOR
APPLICATION NOTE
Thursday, 23 May 2013
Version 1.4
Bluegiga Technologies Oy
Copyright © 2000-2013 Bluegiga Technologies
All rights reserved.
Bluegiga Technologies assumes no responsibility for any errors which may appear in this manual. Furthermore, Bluegiga Technologies reserves the right to alter the hardware, software, and/or specifications detailed here at any time without notice and does not make any commitment to update the information contained here. Bluegiga’s products are not authorized for use as critical components in life support devices or systems.
The WRAP, Bluegiga Access Server, Access Point and iWRAP are registered trademarks of Bluegiga Technologies.
The Bluetooth trademark is owned by the Bluetooth SIG Inc., USA and is licensed to Bluegiga Technologies. All other trademarks listed herein are owned by their respective owners.
Bluegiga Technologies Oy
VERSION HISTORY
Version Comment
1.0 First version
1.1 Services added
1.2 Updated BGscript code examples
1.3 Changed broadcast=”true” to advertise=”true”
1.4 Updated compile and installation instructions
Bluegiga Technologies Oy
TABLE OF CONTENTS
1 Introduction ....................................................................................................................................................5
2 What is Bluetooth low energy technology? ...................................................................................................6
3 Heart Rate Profile v1.0 ..................................................................................................................................7
3.1 Description ............................................................................................................................................7
3.2 Service requirements ............................................................................................................................7
3.3 Heart Rate Service requirements .........................................................................................................8
3.4 Device Information Service requirements .............................................................................................8
3.5 Other requirements ...............................................................................................................................8
3.6 Connection establishment requirement ................................................................................................9
3.7 Security requirements ........................................................................................................................ 10
4 Implementing a Heart Rate Sensor ............................................................................................................ 11
4.1 Creating a project .............................................................................................................................. 12
4.2 Hardware configuration ...................................................................................................................... 13
4.3 Heart Rate Profile GATT database .................................................................................................... 14
4.4 Writing BGScript application .............................................................................................................. 19
4.5 Compiling and installing the firmware ................................................................................................ 23
5 Testing the Heart Rate Sensor ................................................................................................................... 27
5.1 Testing with BLEGUI ......................................................................................................................... 27
6 Debugging Heart Rate sensor code ........................................................................................................... 34
7 Appendixes ................................................................................................................................................. 37
7.1 Bluegiga’s Bluetooth 4.0 single mode stack suite ............................................................................. 37
7.2 Bluetooth 4.0 single mode stack ........................................................................................................ 37
7.3 BGAPI protocol .................................................................................................................................. 38
7.4 BGLib library ...................................................................................................................................... 39
7.5 BGScriptTM
scripting language ........................................................................................................... 40
7.6 Profile toolkit ...................................................................................................................................... 41
7.7 External resources ............................................................................................................................. 42
8 Contact information .................................................................................................................................... 43
Bluegiga Technologies Oy
Page 5 of 43
1 Introduction
This application note discusses how to build Bluetooth 4.0 Heart Rate Profile (HRP) sensor using Bluegiga’s Bluetooth 4.0 software and DKBLE112 hardware development kits. The application note contains a practical example of how to build GATT based Heart Rate Profile and how to make a standalone sensor device using BGScript scripting language.
Notice that this application note only focuses on the Heart Rate Profile sensor implementation, not the Heart Rate Profile Collector implementation.
Bluegiga Technologies Oy
Page 6 of 43
2 What is Bluetooth low energy technology?
Bluetooth low energy (Bluetooth 4.0) is a new, open standard developed by the Bluetooth SIG. It’s targeted to address the needs of new modern wireless applications such as ultra-low power consumption, fast connection times, reliability and security. Bluetooth low energy consumes 10-20 times less power and is able to transmit data 50 times quicker than classical Bluetooth solutions.
Link: How Bluetooth low energy technology works?
Bluetooth low energy is designed for new emerging applications and markets, but it still embraces the very same benefits we already know from the classical, well established Bluetooth technology:
Robustness and reliability - The adaptive frequency hopping technology used by Bluetooth low energy allows the device to quickly hop within a wide frequency band, not just to reduce interference but also to identify crowded frequencies and avoid them. On addition to broadcasting Bluetooth low energy also provides a reliable, connection oriented way of transmitting data.
Security - Data privacy and integrity is always a concern is wireless, mission critical applications. Therefore Bluetooth low energy technology is designed to incorporate high level of security including authentication, authorization, encryption and man-in-the-middle protection.
Interoperability - Bluetooth low energy technology is an open standard maintained and developed by the Bluetooth SIG. Strong qualification and interoperability testing processes are included in the development of technology so that wireless device manufacturers can enjoy the benefit of many solution providers and consumers can feel confident that equipment will communicate with other devices regardless of manufacturer.
Global availability - Based on the open, license free 2.4GHz frequency band, Bluetooth low energy technology can be used in world wide applications.
There are two types of Bluetooth 4.0 devices:
Bluetooth 4.0 single-mode devices that only support Bluetooth low energy and are optimized for low-power, low-cost and small size solutions.
Bluetooth 4.0 dual-mode devices that support Bluetooth low energy and classical Bluetooth technologies and are interoperable with all the previously Bluetooth specification versions.
Key features of Bluetooth low energy wireless technology include:
Ultra-low peak, average and idle mode power consumption
Ability to run for years on standard, coin-cell batteries
Low cost
Multi-vendor interoperability
Enhanced range
Bluetooth low energy is also meant for markets and applications, such as:
Automotive
Consumer electronics
Smart energy
Entertainment
Home automation
Security & proximity
Sports & fitness
Bluegiga Technologies Oy
Page 7 of 43
3 Heart Rate Profile v1.0
3.1 Description
Heart Rate Profile enables a Heart Rate Collector to connect and exchange data with a Heart Rate Sensor in sports and fitness applications.
Heart Rate Profile defines two roles:
The Heart Rate Sensor
The Heart Rate Sensor measures the heart rate and exposes it via the Heart Rate Service. The sensor also contains the Device Information Service, which contains information for example about the manufacturer of the device. The Heart Rate Sensor is the GATT server.
The Heart Rate Collector
The Heart Rate Collector accesses the information exposed by the Heart Rate Sensor and can for example display it to the end user or store it on non-volatile memory for later analysis. The Heart Rate Collector is the GATT client.
The figure below shows the relationship of these two roles.
Heart Rate Collector Heart Rate Sensor
Device Information Service
Heart Rate Service
Figure 1: Heart Rate profile roles
3.2 Service requirements
The table below describes the service requirements.
Service UUID Heart Rate Sensor
Heart Rate Service 180A Mandatory
Device Information Service 180D Mandatory
Table 1: Service requirements
The Heart Rate Sensor implements one and only one instance of Heart Rate Service.
The Heart Rate Sensor implements one instance of Device Information Service.
Bluegiga Technologies Oy
Page 8 of 43
3.3 Heart Rate Service requirements
The table below describes the structure and requirements for the Heart Rate Service
Characteristic UUID Type Support Security Properties
Heart rate measurement 2A37 8bit Mandatory none Notify
Body sensor location 2A38 8bit Optional none Read
Heart rate control point 2A39 8bit Conditional none Write
Table 2: Heart Rate Service structure
3.4 Device Information Service requirements
The table below describes the structure and requirements for the Device Information Service when used in the context of Heart Rate Service.
Characteristic UUID Type Support Security Properties
Manufacturer name string 2A29 UTF-8 Mandatory none Read
Table 3: Device Information Service structure
3.5 Other requirements
The Heart Rate Sensor should include the Heart Rate Service UUID in the advertisement data.
The Heart Rate Sensor should include the device name in the advertisement or scan response data.
The Heart Rate Sensor may support write property for the local name for the device name characteristic so the Collector can write its value.
Bluegiga Technologies Oy
Page 9 of 43
3.6 Connection establishment requirement
3.6.1 Un-bonded devices
Advertisement duration Parameter Value
First 30 seconds Advertising interval 20ms to 30ms
After 30 seconds Advertising interval 1000ms to 2500ms
Table 4: Advertising parameters for un-bonded Heart Rate Sensor
1. The Heart Rate Sensor shall accept any valid values for connection interval and slave latency set by the Collector until service discovery, bonding and/or encryption have are complete. After this the sensor may request the change of connection parameters.
2. If the connection is not established within a time limit, the sensor may exit GAP Connectable mode.
3. If bonded the Heart Rate Sensor should write the address of the Collector to the white list and should set the filtering policy so that scan and connection requests are only accepted from devices on the white list.
4. When the Heart Rate Sensor no longer senses the heart rate it should terminate the connection for example within 10 or 20 seconds.
5. When Heart Rate Sensor is disconnected by the Collector and ready to receive a connection (i.e. senses the heart rate) it should initiate the connection procedure.
3.6.2 Bonded devices
The following produce is uses for bonded devices:
1. The Heart Rate Sensor should use GAP General discoverable mode with connectable undirected advertisement events.
2. For the first 10 seconds the white list should be used to allow only connections from bonded devices. After 10 seconds the white list should not be used to allow connections from other devices.
3. The advertisement parameters should be as in Table 4.
4. The Heart Rate Sensor shall accept any valid values for connection interval and slave latency set by the Collector until service discovery, bonding and/or encryption have are complete. After this the sensor may request the change of connection parameters.
5. If the connection is not established within a time limit, the sensor may exit GAP Connectable mode.
6. When the Heart Rate Sensor no longer senses the heart rate it should terminate the connection for example within 10 or 20 seconds.
7. When Heart Rate Sensor is disconnected by the Collector and ready to receive a connection (i.e. senses the heart rate) it should initiate the connection procedure.
3.6.3 Link loss procedure
When connection is terminated due to link loss the sensor should attempt reconnection with the Collector by entering the GAP connectable mode using the recommended parameters from Table 4.
Bluegiga Technologies Oy
Page 10 of 43
3.7 Security requirements
1 The Heart Rate Sensor may bond with the Collector.
2 When bonding is not used:
2.1 The Heart Rate Sensor should use the Slave Security Request procedure to inform the Collector of its security requirements.
3 When bonding is used:
3.1 The Heart Rate Sensor shall use LE security Mode 1 and either Security Level 2 or 3.
3.2 The Heart Rate Sensor shall use the Slave Security Request procedure.
3.3 All supported characteristics specified by the Heart Rate Service shall be set to Security Mode 1 and either Security Level 2 or 3.
All supported characteristics specified by the Device Information Service should be set to the same security mode and level as the characteristics in the Heart Rate Service.
Bluegiga Technologies Oy
Page 11 of 43
4 Implementing a Heart Rate Sensor
The chapter contains step by step instructions how to implement a stand-alone Heart Rate Sensor with Bluegiga’s Bluetooth 4.0 Software Development Kit. The chapter is split into following steps:
1. Creating a project
2. Defining hardware configuration
3. Building Heart Rate and Device Information Services with Profile Toolkit
4. Writing a BGScript code
5. Compiling the GATT database and BGScript into a binary firmware
6. Installing the firmware into BLE112 or DKBLE112 hardware
The actual project comes as an example with the Bluegiga’s Bluetooth low energy Software Development Kit.
Note: This application note is written for firmware version 0.2.0 build 30.
Bluegiga Technologies Oy
Page 12 of 43
4.1 Creating a project
The Heart Rate Sensor implementation is started by first creating a project file (project.xml), which defines the resources use by the project and the firmware output file.
Figure 2: Project file
<gatt> Defines the XML-file containing the GATT database.
<hardware> Defines the XML-file containing the hardware configuration.
<script> Defines the BGScript-file which contains the BGScript code.
<image> Defines the output HEX file containing the firmware image.
WARNING:
This example MUST only be installed on BLE112 module or DKBLE112 development kit. The example does not use USB or UART interfaces, so the firmware can be installed only via the debug interface using CC debugger. Installing the example into BLED112 USB dongle will brock the device.
Bluegiga Technologies Oy
Page 13 of 43
4.2 Hardware configuration
The hardware.xml file contains the hardware configuration for BLE112 device. It describes which interfaces and functions are in used and their properties.
Figure 3: Hardware configuration for Heart Rate Sensor
<sleeposc> Sleep oscillator is enabled to allow the device to enter low power modes like Power mode 3. If this configuration is not used, the BLE112 device will not go to power mode 3. 30 refers to the crystal accuracy used in BLE112. Do not modify the value.
<usb> USB interface is disabled to save power and allow the device to go to low power modes.
<txpower> TX power is set to +3dBm value. Every step represents 1 dBm change. Range is 15 to 0, corresponding TX power values from +3 dBm to -12 dBm.
This example uses a single ADC to read the heart rate value. DKBL112 development kit contains a potentiometer, which can be read with the ADC.
Typically in a real heart rate sensor a GPIO would be used to indicate the heartbeat and a GPIO pin would be used to detect it. This requires that one GPIO pin is configured as an input.
Bluegiga Technologies Oy
Page 14 of 43
4.3 Heart Rate Profile GATT database
This section describes how to define the Heart Rate Profile services using Bluegiga’s Profile Toolkit.
The Heart Rate Profile contains three services:
Generic Access Profile (GAP) service
Device Information Service (DIS)
Heart Rate Service (HRS)
This example contains a minimum implementation of the above services, so only mandatory characteristics are used. You may also implement the optional characteristics.
4.3.1 Generic Access Profile service
Every Bluetooth low energy device needs to implement a GAP service. The GAP service is very simple and consists of only two characteristics. An example implementation of GAP service is show below.
The service has two characteristics, which are explained in Table 5. In this example the characteristics are read-only, so they are also marked as const. Constant values are stored on the flash of BLE112 and the value is defined in the GATT database. Constant values cannot be changed.
Figure 4: GAP service
Characteristic UUID Type Support Security Properties
Device name 2a00 UTF8 Mandatory none Read (optionally write)
Appearance 2A01 16bit Mandatory none Read
Table 5: GAP (UUID: 1800) service description
Bluegiga Technologies Oy
Page 15 of 43
4.3.2 Heart Rate Service
The Heart Rate Sensor must also implement the Heart Rate Service. The example implementation uses a simplified Heart Rate Service with just the mandatory characteristics, but optionally you may implement the full Hear Rate Service with the optional characteristics also.
Heart Rate Service is described below:
Characteristic UUID Type Support Security Properties
Heart Rate Measurement 2a37 16 bits to 56 bits Mandatory none Notify
Body Sensor location 2a38 8 bit Optional none Read
Heart Rate Control Point 2a39 8 bit Conditional none Write
Table 6: Heart Rate Service (UUID: 180D) description
Hear rate service specification: Hear Rate Service specification: Hear rate service specification
Hear Rate service at Bluetooth developer web site: Heart Rate Service
The example implementation of the minimum Heart Rate Service is shown below:
Figure 5: Minimal Heart Rate Service
A few explanations are needed:
First of all the advertise=”true” option is needed for the Hear Rate Service UUID to be broadcasted in the advertisement packets. For example the Apple iPhone 4S is not able to discover devices, if the service UUIDs are not broadcasted.
The id=”xgatt_HRS_2a37” defines the attribute ID, which the BGScript application can use to update the Heart Rate measurement values.
The length of the Heart Rate measurement is 16-bits in this example. The first 8 bits define the flags for the Heart Rate measurement value and the next 8 bits contain the actual measurement value.
Body Sensor location and Heart Rate Control Point characteristics are not used in this example as they are not mandatory.
Bluegiga Technologies Oy
Page 16 of 43
4.3.3 Device Information Service
The third mandatory service the Heart Rate Sensor must implement is the Device Information Service. This service exposes information about the manufacturer of the device and optionally other information about the device, which is for example device model number and software version. The example implementation uses a simplified Device Information Service with just the mandatory characteristics, but optionally you may implement the full Device Information Service with the optional characteristics also.
Device Information Service is described below:
Characteristic UUID Type Support Security Properties
Manufacturer name string 2a29 UTF-8s Conditional none Read
Model number string 2a24 UTF-8s Conditional none Read
Serial number string 2a25 UTF-8s Conditional none Read
Hardware revision string 2a27 UTF-8s Conditional none Read
Firmware revision string 2a26 UTF-8s Conditional none Read
Software revision string 2a28 UTF-8s Conditional none Read
System ID 2a35 uint40 or uint64
Conditional none Read
IEEE 11073-20601 Regulatory Certification Data List
2a36 reg-cert-data-list
Conditional none Read
Table 7: Device Information Service (UUID: 180A) description
Device Information Service specification: Hear Rate Service specification: Device Information Service specification
Device Information Service at Bluetooth developer web site: Device Information Service
Bluegiga Technologies Oy
Page 17 of 43
The example implementation of the minimum Device Information Service is shown below:
Figure 6: Minimal Device Information Service
A few explanations are needed:
The Heart Rate Profile service only mandates that Manufacturer Name String characteristic is implemented, but the example also implements the Model Number String characteristic.
Bluegiga Technologies Oy
Page 18 of 43
4.3.4 Summary
The full GATT database implementation is shown below.
Figure 7: Heart Rate Profile GATT database
Bluegiga Technologies Oy
Page 19 of 43
4.4 Writing BGScript application
The example implements a standalone Heart Rate Sensor device where no external host processor is needed. The Heart Rate Sensor application is created as a BGScript script application and the BGScript code explained in this chapter.
BGScript uses an event based programming approach. The script is executed when an event takes place, and the programmer may register listeners for various events.
The Heart Rate Sensor BGScript uses the following event listeners:
1. system_boot(…) event listener
When the system is started a boot event is generated and this event listener should be the entry point for all the BGScript applications. In the example above, when the system is started, the unit starts to advertise, enables bonding mode, and starts a timer.
Figure 8: system_boot(...) event listener
Bluegiga Technologies Oy
Page 20 of 43
2. hardware_soft_timer(…)event listener
When the timer expires this event is generated. In the Heart Rate Sensor example the timers are used to alter the advertising intervals and read HR sensor.
Figure 9: hardware_soft_timer(…) event listener
Bluegiga Technologies Oy
Page 21 of 43
3. hardware_adc_result(…)event listener
The ADC read function generates an ADC event, which this event listener captures. The ADC result event is used to read the HR value and write it to GATT database.
Figure 10: hardware_adc_result(…) event listener
4. connection_status(…)event listener
This event takes place when the device is connected. The code changes the connection status parameter and starts the HR measurement timer.
Figure 11: connection_status(…) event listener
Bluegiga Technologies Oy
Page 22 of 43
5. connection_disconnected(…)event listener
The last event handler is executed when the Bluetooth is lost or closed by the remote device. The event listener restarts the advertisement procedure.
Figure 12: connection_disconnected(…) event listener
Bluegiga Technologies Oy
Page 23 of 43
4.5 Compiling and installing the firmware
4.5.1 Using BLE Update tool
When you want to test your project, you need to compile the hardware settings, the GATT data base and BGScript code into a firmware binary file. The easiest way to do this is with the BLE Update tool that can be used to compile the project and install the firmware to a BLE112 module using a CC debugger.
In order to compile and install the project:
1. Connect CC debugger to the PC via USB
2. Connect the CC debugger to the debug interface on the BLE112
3. Press the button on CC debugger and make sure the led turns green
4. Start BLE Update tool
5. Make sure the CC debugger is shown in the Port drop down list
6. Use Browse to locate your project.xml file
7. Press Update
BLE Update tool will compile the project and install it into the target device.
Figure 13: Compile and install with BLE Update tool
Bluegiga Technologies Oy
Page 24 of 43
The View Build Log opens up a dialog that shows the bgbuild compilere output and the RAM and Flash memory allocations.
Figure 14: BLE Update build log
Bluegiga Technologies Oy
Page 25 of 43
4.5.2 Compiling using the bgbuild.exe
The project can also be compiled with the bgbuild.exe command line compiler. The BGBuild compiler simply generates the firmware image file, which can be installed to the BLE112.
In order to compile the project using BGBuild:
1. Open Windows Command Prompt (cmd.exe)
2. Navigate to the directory where your project is
3. Execute BGbuild.exe compiler
Syntax: bgbuild.exe <project file>
Figure 15: Compiling with BGBuild.exe
If the compilation is successful a .HEX file is generated, which can be installed into a BLE112 module.
On the other hand if the compilation fails due to syntax errors in the BGScript or GATT files, and error message is printed.
Bluegiga Technologies Oy
Page 26 of 43
4.5.3 Installing the firmware with TI’s flash tool
Texas Instruments flash tool can also be used to install the firmware into the target device using the CC debugger.
In order to install the firmware with TI flash tool:
1. Connect CC debugger to the PC via USB
2. Connect the CC debugger to the debug interface on the BLE112
3. Press the button on CC debugger and make sure the led turns green
4. Start TI flash tool tool
5. Select program CCxxxx SoC or MSP430
6. Make sure the target device is recognized and displayed in the System-on-Chip field
7. Make sure Retain IEEE address.. field is checked
8. Select the .HEX file you want to program to the target device
9. Select Erase, Program and Verify
10. Finally press Perform actions and make sure the installation is successful
Figure 16: TI’s flash programmer tool
Note:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK v.1.1 or newer, but BLE Update tool should be used instead. The BLE112 and BLED112 devices contain a security key, which is needed for the firmware to operate and if the device is programmed with TI flash tool, this security key will be erased.
Bluegiga Technologies Oy
Page 27 of 43
5 Testing the Heart Rate Sensor
5.1 Testing with BLEGUI
This section describes how to test the Heart Rate Sensor application with BLEGUI software.
5.1.1 Discovering the Heart Rate Sensor
As soon as the Heart Rate Sensor is powered on it starts to advertise itself. A BLED112 USB dongle can for example be used to scan for the sensor together with BLEGUI software.
Start Generic Scan to discover the device.
Figure 17: Scanning with BLEGUI
Bluegiga Technologies Oy
Page 28 of 43
5.1.2 Establishing a connection
Simply select the DKBLE112 heart rate device and press the Connect button in the BLEGUI user interface.
Figure 18: Establishing connection with BLEGUI
Bluegiga Technologies Oy
Page 29 of 43
5.1.3 Making a service discovery
1. Press the GATT button to start GATT tool
2. Press Service Discover button to start a GATT primary service discovery procedure
Figure 19: GATT service discovery
The three services defined in the GATT database are visible in the device.
Bluegiga Technologies Oy
Page 30 of 43
5.1.4 Making a descriptors discovery
1. In order to discover the characteristics of the Device Information Service, select the service and press Descriptors Discover button
2. A list of service descriptors are shown
Figure 20: GATT descriptors discovery
Bluegiga Technologies Oy
Page 31 of 43
5.1.5 Reading a characteristics value
1. To read a characteristic value, select the characteristic you are interested in and press the Read button. For example the Manufacturer Name String has a read property, so the value can be read by a GATT client.
Figure 21: Reading Manufacturer Name String
Bluegiga Technologies Oy
Page 32 of 43
5.1.6 Starting notifications for HR measurement
1. Heart Rate Measurement characteristic has a notify property
2. This means the Heart Rate Sensor notifies the characteristic value changes to the Heart Rate Collector, instead of the collector having to read it constantly.
3. To enable notifications:
o Perform descriptors discovery to the Heart Rate Service
o Write “0x01” to the Client Characteristic Configuration
The Heart Rate Sensor starts to notify the HR measurements at 1 second interval
Figure 22: Enabling HR measurement notifications
Bluegiga Technologies Oy
Page 33 of 43
5.1.7 Terminating the connection
To terminate the connection:
1. Press the Disconnect button
The Heart Rate Sensor restarts the advertisement procedure for the next 60 seconds, until it stops advertisements and goes to Power Mode 3.
After 60 seconds you need to reset the device to restart the advertisements.
Figure 23: Terminating the connection
Bluegiga Technologies Oy
Page 34 of 43
6 Debugging Heart Rate sensor code
Debugging BGScript is easiest achieved over the USB interface. You can add debug prints to the BGScript code and then monitor them via the USB interface for example with terminal software.
The enable debugging a few modifications are needed.
First you need to enable USB interface and give the access to it to BGScript. This can be done with the following modifications to the hardware.xml file.
Figure 24: Hardware configuration with USB enabled and access give to BGScript
Bluegiga Technologies Oy
Page 35 of 43
To print the actual debug messages modifications to the BGScript code is needed. The debug messages are printed to USB with system_endpoint_tx(…) command and a few examples are shown below.
Figure 25: BGscript code with debug prints
call system_endpoint_tx(3,5,”BOOT\n”) prints the actual debug messages. 3 refers to endpoint USB, 5 means that 5 bytes are written. “BOOT\n” is the actual message.
NOTE:
The “BOOT\n” message is actually never received by a terminal software when USB interface is used, because the operating system enumerates the USB when the message is being printed. Other messages will however be visible. If UART interface is used, the also the “BOOT\n” message can also be received.
Bluegiga Technologies Oy
Page 36 of 43
Monitoring debug messages can be done with a standard terminal software.
Figure 26: Monitoring debug messages
Bluegiga Technologies Oy
Page 37 of 43
7 Appendixes
7.1 Bluegiga’s Bluetooth 4.0 single mode stack suite
Bluegiga’s Bluetooth 4.0 single mode stack suite provides a complete development framework for Bluetooth low energy application implementers.
The Bluetooth 4.0 single mode stack suite framework supports two architectural modes:
All software including: Bluetooth 4.0 single mode stack, profiles and end user application all run on the Bluegiga's Bluetooth 4.0 single mode hardware
The Bluetooth 4.0 single mode stack and profiles run on the Bluegiga 4.0 single mode hardware but the end user application runs on a separate host (a micro controller for example)
The benefits of the development suite in either of the use cases is that it provides a complete Bluetooth 4.0 single mode stack so that no Bluetooth development is required, a well-defined transport protocol exists between the host and the Bluetooth hardware and also simple development tools are available for embedding the end user applications on the Bluetooth 4.0 single mode hardware.
The Bluetooth 4.0 single mode development suite consists of several components:
A Bluetooth 4.0 single mode stack
Binary based communication protocol (called BGAPI) between the host and the Bluetooth stack
A C library (called BGLib) for the host that implements the BGAPI protocol
BGScriptTM
scripting language and interpreter for implementing applications on the Bluetooth 4.0 single mode hardware
A Profile Toolkit for quick and easy development of GATT based Bluetooth services
7.2 Bluetooth 4.0 single mode stack
The Bluetooth 4.0 single mode stack is a full, embedded implementation of Bluetooth v.4.0 compatible stack software and it’s dedicated for Bluegiga’s Bluetooth 4.0 single mode modules. The stack implements all mandatory functionality for a single mode device. The structure and layers of the stack are illustrated in the figure below.
Figure 27: Bluetooth 4.0 single mode stack
Bluegiga Technologies Oy
Page 38 of 43
7.3 BGAPI protocol
For applications where a separate host is used to implement the end user application, a transport protocol is needed between the host and the Bluetooth stack. The transport protocol is used to communicate with the Bluetooth stack as well to transmit and receive data packets. his protocol is called BGAPI and it's a binary based communication protocol designed specifically for ease of implementation within host devices with limited resources.
The BGAPI provides access to the following layers:
Generic Access Profile - GAP allows the management of discoverability and connetability modes and open connections
Security manager - Provides access the Bluetooth low energy security functions
Attribute database - An class to access the local attribute database
Attribute client - Provides an interface to discover, read and write remote attributes
Connection - Provides an interface to manage Bluetooth low energy connections
Hardware - An interface to access the various hardware layers such as timers, ADC and other hardware interfaces
Persistent Store - User to access the parameters of the radio hardware and read/write data to non-volatile memory
System - Various system functions, such as querying the hardware status or reset it
The BGAPI protocol is intended to be used with:
a serial UART link or
a USB connection
Bluegiga Technologies Oy
Page 39 of 43
7.4 BGLib library
For easy implementation of BGAPI protocol an ANSI C host library is available. The library is easily portable ANSI C code delivered within the Bluetooth 4.0 single mode energy development suite. The purpose is to simplify the application development to various host environments.
Figure 28: BGLib host library
Bluegiga Technologies Oy
Page 40 of 43
7.5 BGScriptTM scripting language
Bluegiga's Bluetooth 4.0 single mode energy products allow application developers to create standalone devices without the need of a separate host. The Bluetooth low energy modules can run simple applications along the Bluetooth 4.0 single mode stack and this provides a benefit when one needs to minimize the end product size, cost and current consumption. For developing standalone Bluetooth low energy applications the development suite provides a simple BGScript scripting language. With BGScript provides access to the same software and hardware interfaces as the BGAPI protocol. The BGScript code can be developed and compiled with free tools provided by Bluegiga.
Figure 29: BGScript application model
BGScript code example:
# System Started
event system_boot(major, minor, patch, build, ll_version, protocol_version,hw)
#Enable advertising mode
call gap_set_mode(gap_general_discoverable,gap_undirected_connectable)
#Enable bondable mode
call sm_set_bondable_mode(1)
#Start timer at 1 second interval (32768 = crystal frequency)
call hardware_set_soft_timer(32768)
end
Bluegiga Technologies Oy
Page 41 of 43
7.6 Profile toolkit
The Bluetooth low energy profile toolkit a simple set of tools, which can used to create GATT based Bluetooth services. The profile toolkit consists of a simple XML based service description language template, which describes the devices local GATT database as a set of services. The profile toolkit also contains a compiler, which converts the XML to binary format and generates API to access the characteristic values.
Figure 30: A profile toolkit example of GAP service
Bluegiga Technologies Oy
Page 42 of 43
7.7 External resources
Bluetooth 4.0 software development kit is available at : http://techforum.bluegiga.com
BLE112 and DKBLE112 hardware documentation is available at : http://techforum.bluegiga.com
Heart Rate Profile can be downloaded from: Heart Rate Profile
Bluetooth SIG’s developer portal: https://developer.Bluetooth.org/
Bluegiga Technologies Oy
Page 43 of 43
8 Contact information
Sales: [email protected]
Technical support: [email protected]
http://techforum.bluegiga.com
Orders: [email protected]
WWW: www.bluegiga.com
www.bluegiga.hk
Head Office / Finland:
Phone: +358-9-4355 060
Fax: +358-9-4355 0660
Sinikalliontie 5A
02630 ESPOO
FINLAND
Postal address / Finland:
P.O. BOX 120
02631 ESPOO
FINLAND
Sales Office / USA:
Phone: +1 770 291 2181
Fax: +1 770 291 2183
Bluegiga Technologies, Inc.
3235 Satellite Boulevard, Building 400, Suite 300
Duluth, GA, 30096, USA
Sales Office / Hong-Kong:
Phone: +852 3972 2186
Bluegiga Technologies Ltd.
Unit 10-18
32/F, Tower 1, Millennium City 1
388 Kwun Tong Road
Kwun Tong, Kowloon
Hong Kong
