In 1994, Swedish company Ericsson was the first to take steps towards Bluetooth communication. It was even a Dutchman employed by Ericsson who initially developed the technology.
Ericsson was looking for a cheap way to establish a wireless connection between (mobile) devices. Since that time there has been a lot of further development, with perhaps the most important update around 2010; Bluetooth 4.0 + LE. The letter LE stands for Low Energy, which according to these protocols must ensure that the Bluetooth chip itself uses relatively little energy. And that is ideal for a smartphone. Especially because the smartphones are getting thinner and faster, but the battery life should not suffer.
The development within the Bluetooth steering group does not stand still and in mid-2016 Bluetooth 5 saw the light of day. Bluetooth 5 focused mainly on the Internet of Things and doubling both speed and range. And again a reduction in energy consumption.
Of course, the distance of the transmitter relative to the receiver has an effect on the maximum speed.
That is all nice and nice, but what do we have?
Good question :)
A bluetooth chip varies in size between 5x5 and 10x10 mm, depending on the manufacturer. This allows it to be put into the smallest hardware solutions without having a major impact on the dimensions of the end product. This is especially a benefit for products that should be and remain as small as possible.
To communicate with devices, use is generally made of WiFi or bluetooth. Other methods such as IR (infrared) or RF (radio frequencies) are left out of consideration, because these are generally dated methods. The big difference between wifi and bluetooth is that, apart from any pairing, you do not have to go through a setup procedure at blueooth. You will have to set up a Wi-Fi device in order to get to the right (secure) network. While you should be 'just' close to bluetooth. Read here a more detailed comparison.
A device that has Bluetooth support can be connected (up to 7 devices per device) to a maximum of 7 other devices. Such a device is also called a peripheral. To connect to a peripheral, you first have to search for that device.
For example, imagine that we have a personal scale that has Bluetooth support and an iOS app. We turn on the scale and start the app. A bluetooth peripheral will always make itself known to the outside world to connect with. This is also called 'advertising'. In this way, other devices (such as an iPhone) can find this peripheral and connect to it. But nowadays there are a lot of devices that make use of bluetooth, so just connecting to the first one that you think will not be good enough.
All those bluetooth devices can be seen as a group of people, who at first sight all look exactly the same:
This group of people can be viewed by everyone and can be retrieved through the use of any bluetooth scanner. But only one of these people is actually the scale with which the app wants to connect.
Although all these peripherals have a name, the right one is not necessarily immediately recognizable. That is why all the peripherals send certain information, with which they 'advertise', called services.
A bluetooth service is a service that supports the peripheral. And that service again contains characteristics. A characteristic is a property or value that the service can change or return. So to make the connection with the right peripheral, you need to know whether the peripheral also supports the right services. In other words, you have to know whether the person you want to come into contact with also speaks your language.
Fortunately, all these peripherals advertise (a few) services that support them. So you know beforehand that you connect to the peripheral that also speaks your language. And you are 100% sure that the app also wants to connect with a scale and not with another device.
There are 2 types of services. A standard service that is supported in the GATT profiles and a customized service.
The bluetooth steering group has set up a list of standard services and characteristics, called GATT specifications , so that your product speaks a language that other apps or applications also understand. For example, a scale producer can choose that the data that is sent over bluetooth goes through a GATT service and characteristic profile. This means that communication takes place via a standard defined protocol. In other words via an official (world) language.
This has the great advantage that no technical documentation is required for the (app) developer to get data from the scale. The big disadvantage is that perhaps the official app of the scale producer is not used by consumers, but an improved 3rd-party app.
Another disadvantage is that the GATT profiles are fixed. If you want more data than the profile allows, you have to set up your own service (language) that the device should communicate with.
Once the correct device is found, a connection can be set up. Some devices use a pairing mechanism, in which both the peripheral and the client have to validate that they actually communicate with each other. This can be done by entering a code or by simply approving that a connection must be made. There are 3 methods for exchanging data with a bluetooth peripheral:
Reading in a value. Suggest that you want to get the battery percentage from your scale so that you can show a message that it needs to be charged. At that moment your client can request a read on the 'battery level' characteristic of the battery service. The peripheral will then return the percentage to use for the client, for example in an app.
Via a write the client (app) can write a value to the peripheral. For example if the same scale also calculates your BMI, you will have to give up your height. This can be done by having the client perform a write action on the 'height' service and characteristic. The periperhal must at that moment store the sent value for future use.
Notify
Finally, and perhaps most important, is notify . With this method, the client receives a signal as soon as a value of a specific characteristic changes. Again suggest that you are on that scale. As soon as the scale has your weight, it sends it via the 'weight' service and characteristic. The difference between notify and read is that you get a signal at a notify once the value has changed. If no notify would be available, the client should do a read every time to retrieve the value. What a) is cumbersome and b) costs more energy.
In addition to these 3 methods, there is also a difference in the way a connection is established. Usually a smartphone (via an app) automatically connects to the peripheral and always tries to maintain this connection, even if the app is closed. Nevertheless, at such moments, the peripheral can also send a notification , or a write or read request can be made. In between, nothing will happen in terms of communication, only the connection with each other will continue. But a Bluetooth connection (even if it is Low Energy) still costs energy. Thus, keeping the connection open continuously results in a faster decrease in the battery consumption than when it is switched off.
An alternative is that the app connects to the peripheral only at moments of user interaction and after the data exchange is completed, the connection closes again. Such methods therefore often only use a write and read request. As a result, a connection must first be established with each interaction and the data exchange will only take place with a successful connection.
To develop an app that communicates with a bluetooth device, the most important thing is that the app knows how to communicate with that device. Whether this is done through standard GATT profiles or via a customized solution set up by an engineer, in both cases documentation and (communication) agreements are of great importance. Without the app knowing how to send information to and from the peripheral, you have nothing left but a smartphone and a (bluetooth) device that exist independently of each other.
As soon as the app has received certain data, it can process this data. For example, by storing data locally and thus serving to the user. But in many cases the data is passed on again to an API, which in turn stores it in a database. In the case of you, for example, you can view your weight via an online (secured) portal and see it drop or rise over the course of months.
So there are a lot of things you need to know from, to be able to connect to a bluetooth device via an app. At E-sites we have written a standard communication layer, for iOS and Android apps. This offers the possibility to build customized solutions from a framework, without having to lay the foundations for each project.
Read Original Article On:
https://www.e-sites.nl/blog/531-bluetooth-in-app-development.html
Mobile Application Development Services
I am an Entrepreneur, marketer, and writer. I would like to write in-depth guides and case studies that teach users to guide mobile application development to grow and scale there business.