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.
Related
I'm posting for the first time in this forum and English is not my first language so sorry for any mistakes ;) .
I'm trying to find out if it's possible to live stream audio using Bluetooth LE 4.X technology maintaining a very low latency. Namely below 10 ms. I'm trying to live stream a music instrument via bluetooth and the difference between the instant the instrument is played and the musician hears it should be negligible.
I'm asking in particular for the BLE because of what i saw in this page: https://en.m.wikipedia.org/wiki/Bluetooth_low_energy.
In the technical specifications it says: Latency (from a non-connected state) 6 ms. but i cant find where that value came from and even so i don't know if that is the value that I'm looking for.
Thanks! :)
BLE is specifically for sending small amounts of data with an emphasis on saving power by sacrificing speed. If you're concerned about speed and latency then you probably shouldn't be using BLE.
To answer your question, though, the latency is dependent on the connection interval. The connection interval is how long the two devices wait between transfers of data.
The 6ms the wikipedia page is talking about the length of time it takes to do the initial connection between the two devices (BLE is faster at making initial connections than "classic" Bluetooth because I think they made it simpler), but that isn't related to the latency during the regular usage after the connection is established.
Most Bluetooth 4.0 devices that support BLE also support regular Bluetooth, so I'd suggest using that if at all possible (since your concern is latency and not power consumption).
Is there any way to read data continuously upon request without using notifications? Thank you for your help.
If you want an app capable of working with all the sensors from CC2541DK, CC2650STK, ThunderBoard React and Sense (e.g. accelerometer., magnetometer, gyroscope etc.), you can download it from: BLE SensorTags (blessTags) – the software is able of giving new uses (movement & magnetic security, accelerometer mouse, PC remote control and wireless presenters) to all these IoT SensorTags. For more info: Bluetooth low energy SensorTag.
Yes, it is possible. You have notifying and reading mechanism of data transfer - in CC2650 almost all characteristics support both mechanism of data transfer. But other characteristics can only be accessed based only one method of data reading. One such example is the reading of the buttons states on the CC2650STK and CC2541DK that can only be read by means of the notification mechanism. But, notifications is preferred if you need a higher data transfer rate between the SensorTag and your application.
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
Let's say I want to start transmitting advertising packets from a Blueooth 4 module attached to a Raspberry Pi. I am planning to use BlueZ library for the same. Have a basic questions regarding the same -
How much memory does a typical Bluetooth device contains (is it standard or something that can change from vendor to vendor) ? In both the cases, does the advertisement has to be 27 bytes (iBeacon) and 28 bytes (Altbeacon and URIBeacon) or can it be extended to any number limited by bluetooth memory size or any other guidelines? Wish to understand a little bit about this topic.
Thanks in advance!
Device memory is not what limits the Bluetooth LE advertisement size. The limitation is imposed by the Bluetooth 4.0 Core specification, which allows for a maximum of 28 bytes in a manufacturer advertisement PDU (including the one-byte PDU length field).
While you can't transmit more data in a single advertisement, it is possible to send more data using other techniques including:
Interleaving multiple advertisements from the same transmitter. You can differentiate these advertisements with a "type" byte, and then use this to stitch them together with the receiving device. Disadvantage: complex implementation.
Using a scan response packet to send additional data. Disadvantage: scan responses may not arrive in a timely manner.
Provide a connectable GATT service that can be used to fetch additional data. Disadvantage: once connected, advertising stops.
Use a web service to look up additional data based on a unique identifier in the advertisement. Disadvantage: It won't work with out an internet connection.
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