在没有已发布的GATT配置文件的情况下解释来自BLE设备的数据

Question

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.

Answer 1

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.