As a 3rd party is there a viable way to correctly interpret data from a Bluetooth Low Energy device for which there is not a published GATT profile specification?
The BLE device is a body scale that supports weight, BMI, body fat, and hydration level. My understanding is that there is no adopted GATT profile for body scales like there are for, say, blood pressure devices or heart rate monitors (https://developer.bluetooth.org/gatt/profiles/Pages/ProfilesHome.aspx).
Using the following tools:
iPod (iOS 6.1.3) with various BLE utility apps (Ti BLE Multitool, LightBlue, and BLE Utility)
Android (4.3) tablet (Dell Venue 8 3830) with nRF Master Control Panel, plus a custom Xamarin developed solution
I can scan for, locate, connect to, and read the GATT services available on the scale. All of the above tools give me the same service information. There are 5 services discovered on the scale:
Generic Access (0x1800)
Generic Attribute (0x1801)
Device Information (0x180A)
Battery Service (0x180F)
An unknown service with a custom 128-bit UUID
All of the above tools are able to read from the known services, like retrieving the battery information or the device name. My assumption is that the unknown service with the custom UUID is the service that provides the scale data.
This service has 5 unknown characteristics with custom UUIDs:
Characteristic 1 is Read/Write
Characteristic 2 is Read
Characteristic 3 is Read/Write
Characteristic 4 is Notify
Characteristic 5 is Read
Using the tools that were specified above to read from characteristics 1, 2, and 3, each returns it's own value, but that value never changes. For example, a read of characteristic 1 always returns a value of 20 octets 0x01-0x05-0x06-0x07-0x08-and 15 0x00 octets. Subsequent reads of characteristic 1 always return that value. Characteristic 2 reads always return a value of 20 octets 0x02-and 19 0x00 octets. And so on.
Reading characteristic 5 appears to either not return a value, or more commonly on Android, issue a pairing request. No common pairing code (like 0000 or 1234, etc.) is valid.
Characteristic 4 appears to be what actually transmits the scale data. Using the tools above I can enable notifications and the applications retrieve 13 octets. For example:
FF-16-09-00-03-04-01-00-83-6F-F4-18-0F
FF-16-09-00-03-04-01-00-3E-88-F4-18-E3
FF-16-09-00-03-04-01-00-C8-89-F4-18-6E
Obviously all of those values begin with the same set of octets. The main problem though is what do those octets represent and how do they translate to weight/bmi/hydration/body fat values, if in fact they do at all.
The scale is built with the Ti CC2541 chip (http://www.ti.com/product/cc2541).
Using Ti's SmartRF Protocol Packet Sniffer along with the CC2540 USB Evaluation Module Kit I can capture packets going between an iPhone 5S (iOS 7.1) and the scale. This has provided some additional insight, but mostly just shows what I've already observed using the other tools, though albeit it at a lower level. Any additional information provided by the packet sniffer still leads back to the same question: what do these sets of octets the scale is sending represent and how do they translate to weight/bmi/etc? I've utilized the Bluetooth Core Specification documentation and that has helped to understand what octets for standard functionality mean/do, but that isn't helping understand the actual scale data.
I'm very new to Bluetooth development and this exercise has basically resulted in a crash course in the technology. Any help is appreciated.
Thanks.
You must contact the manufacturer and ask for clarification about the custom service and characteristics.
Characteristic 5 seems to have higher security settings, hence why it triggers pairing when you try to read it. Most likely contains some sensitive data.
Characteristics 1,2,3 are likely for configuration, while 4 notifies the useful data.
Since these are all custom, there's simply no way to find out what they mean without information from the manufacturer.
It's like you create your own "We're out of yogurt" notification profile... one can only guess by looking at the data.
Related
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
I need to advertise 2 different sets of data, 31 bytes each. It doesn't look possible when I look at the core specification v4.0.
What I understand when looking a bit further, beacons can be advertised in 3 different channels : 37, 38, 39. LE Set Advertising Parameters Command makes it possible to choose a specific channel as well as all at once.
Is it possible to advertise different data in different channels ?
If it is not possible, the only solution I remain with is changing the advertisement data periodically using LE Set Advertising Data Command.
I would be glad to see a bit insight on performance, stability and power consumption.
Yes, your device can act as several BLE beacons as long as you periodically change the advertising payload. Your suggestion of using LE Set Advertising Data Command is my recommended approach and you don't need to change the advertising channel for this purpose.
In other words, what you can do on your device is set up a timer, and then as soon as the timer expires, you can switch to a different set of BLE data that is being advertised, which will create the affect of your device acting as multiple beacons.
Please see the following links which may be helpful to your question as well:-
Can BLE devices act as beacons
advertise custom service uuid with bluez 5.4x
Linux BlueZ custom Manufacturing Scan Response Data
Bluez BLE peripheral advertise custom characteristic with ADV data
I hope this helps.
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 have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.