I am trying to understand how Bluetooth BLE works on the iOS programming side. On page https://www.bluetooth.org/Technical/Specifications/adopted.htm, there are two specifications, heart rate profile and heart rate service.
On the introduction of Heart Rate Profile it says
The Heart Rate Profile is used to enable a data collection device to
obtain data from a Heart Rate Sensor that exposes the Heart Rate
Service
On some service like the battery level there is no corresponding profile. What's the difference between the two? One for the sender (service) and one for the receiver (profile)?
The Heart Rate Profile defines an application profile to let a client detect the device as a heart rate sensor.
This profile must include at least the GAP service and the Heart Rate Service for compliance
For battery, the monitoring of a battery level is not an application by itself (or it wouldn't be very useful as an application), but it is relevant to specify a Battery Service for monitoring the battery level within an application.
For example, a heart rate sensor should have a profile compliant with the Heart Rate Profile, so it includes at least the GAP service and the Heart Rate Service. It can also includes (as an option) a Battery Service to enable the monitoring of the battery level of the heart rate sensor
Regards
Related
What is the difference between broadcaster and beacons? From what I understand a broadcaster is a role in the GAP which sends out advertisements which contain data and are unable to make connections. They usually work in tandem with observers. Beacons do the same thing so what is the difference?
It's a bit like asking what is the difference between a HTTP server and a Web Server. A Web Server is a computer that stores web sites which it makes available over the internet, while a HTTP server is a piece of software that implements the server part of the HTTP protocol.
A Broadcaster is a role in the GAP specification which simply sends out advertisements, just as you say. It's defined in section 2.2.2.1 of the GAP chapter (in the Core v5.3 specification). Observer is the opposite role.
The word "beacon" is not present anywhere in the >3000 pages long Bluetooth Core specification. It's a term made up by industry, presumably because it works good in marketing or is generally a good name to describe this type of product. Beacons typically send out their positions using BLE advertisements for location tracking purposes but can also be connectable for various purposes.
Broadcaster is just a technical term and Broadcasters do not have a specific product purpose, which beacons on the other hand usually have. For example, iBeacon is a product which uses a specific data format containing identifiers. This product then uses the Broadcaster role and sends this data over BLE.
There is no difference. While broadcaster is a technical term used in the Bluetooth specification, beacon is simply the name of a class of products based on Bluetooth LE technology.
I have a question regarding BLE. It's my first time trying to use BLE and I am exploring some high level designs for a medical device. The structure would be that the device connects to a stand alone controller-device (wifi disabled) via BLE. The device would be collecting data such as heart rate throughout a 24 hour period. At some point the stand alone controller would be disconnected from the device and connected to an app to transfer the data collected. Can BLE handle the potential data size of this scenario? Is it fast enough to do it in a reasonable amount of time?
Thank you!
Take a look at the specification list provided by the Bluetooth SIG. Two documents describe the handling of heart rate measurements, the most interesting for you would be the Heart Rate Service specification (Download it here: https://www.bluetooth.com/specifications/specs/heart-rate-service-1-0/).
It contains a detailed description on how to transmit heart rate data via BLE. According to the specification you are supposed to use the 16-bit UUID 0x180Dfor the Heart Rate Service. You can find the UUIDs for other services and characteristics in the 16-bit UUID Numbers Document.
The specification for the BLE GATT battery service only lists the battery level characteristic although the descriptive text mentions "battery level and state". I would like to indicate the battery charging/discharging state, however the characteristic that allows that (2A1A) is not included in any defined service. It seems this is an oversight by Bluetooth SIG.
Will including an additional characteristic in the battery service for battery state be flagged as non-compliant with the specification?
Will the addition of the battery state characteristic cause any issue with iOS or android centrals? For example will ios core bluetooth allow accessing a characteristic that is not list in the battery service specification?
I tried asking Bluetooth SIG directly about this and got back a non-answer indicating I should post my question here.
Among the various officially registered Bluetooth device services, which are listed on the Bluetooth.org website, there is no mention of F002 or F003. But I recently was scanning for BLE in public and some unnamed device had these two services. Does anyone here know what device uses F002 or F003? Thanks.
Services in BLE can be adopted or custom. They have UUIDs that are 128bit long but are usually identified by their 16-bit offset:-
Adopted services are those listed by the Bluetooth SIG as
standard Bluetooth UUIDs. They're given a unique number and you have
probably already seen them here. Examples of those include the
Heart Rate (offset 180D), Health Thermometer (offset 1809), Battery
(offset 180F), etc. Those UUIDs are universal and if you see 180D
anywhere it should mean that it's the heart rate service.
Custom UUIDs on the other hand are undefined and in many cases can be just randomly generated. F002 is not an identified offset and therefore can belong to anyone using it for any random service.
I do remember coming across TI sensor tags with a similar UUID so it's worth investigating if you have any of those lying around.
A good read of UUIDs and BLE in general can be found here:-
https://www.safaribooksonline.com/library/view/getting-started-with/9781491900550/ch04.html
Recently I learned that the raw data from the heart rate optical sensor (what is called PPG signal) is available for Galaxy S5 devices using the new sensor extension SDK from Samsung, which means that the sensor physically outputs this data.
Since the same sensor is used in Gear watches, I'm wondering if there is any way to access this raw data from the watch's sensor.
I reviewed the Samsung developers site and different forums, but didn't find the way to do it, only to access the heart rate itself.
Will appreciate your advises.