In this example we will monitor the heart rate pulse coming out of a simulated heart rate sensor. We are using simulated heart rate sensor for simplicity. It’s a simple counter which counts from 100 to 175 and then resets back to 100. The code can be easily extended to use the real heart rate sensor. The key goal here is to demonstrate how to use the following services using mbed APIs.

• Heart Rate Service: The Heart Rate Service exposes heart rate and other data related to a heart rate sensor intended for fitness applications.
• Device Information Service: The Device Information Service exposes manufacturer and/or vendor information about a device.
• Battery Service: The Battery Service exposes the Battery State and Battery Level of a single battery or set of batteries in a device.

mbed APIs abstracts the low level details of these services and makes it very easy to use.. The high-level abstractions around BLE mean you don’t have to spend a lot of time learning about the specifics of your BLE SoC or module

Now let us see the events that makes the communication between the Heart Rate Monitor (HRM) and your smart phone possible.

• Your HRM monitor periodically transmits an advertising signal to let the other BLE devices (such as your smart phone) know that it exists. For the HRM application, this signal is of the type CONNECTABLE UNDIRECTED, which means that it is willing to receive connections from any ‘master’ (also termed as ‘GAP Central’)—for other applications where the peripheral doesn’t solicit connections, such as the iBeacon, the advertisement type is NON CONNECTABLE. To establish a connection, a master first starts scanning to look for advertisers that are currently accepting connection requests. When a suitable advertising slave (such as the HRM) is detected, the master sends a connection request packet to the slave, and provided the slave responds, establishes a connection.
• Upon receiving a connection request, the HRM stops transmitting the CONNECTABLE advertising broadcasts and enters into the connected state.
• Once connection-oriented communication is setup between the HRM and your smartphone, the two start exchanging data periodically.

In this example we have 2 devices – HRM and a smart phone. In BLE paradigm your HRM playing a role of Peripheral (and a server) device and your smart phone of Central (and a client) device.

Generic Attribute profile (GATT) also defines two roles for the devices – server and client. Client - It sends requests to a server and receives responses (and server initiated updates) from it Server - It receives requests from a client and sends responses back. It also sends server-initiated updates when configured to do so, and it is the role responsible for storing and making the user data available to the client,

In our example - HRM acts as a server - Smart phone acts as a client