Interpretting data from a BLE device without a published GATT profile

7
votes

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.

1
bluetoothbluetooth-lowenergyandroid-bluetoothtexas-instrumentsios-bluetooth
Since this is coming from a custom UUID, chances are the scale is using a custom handshake for the data. Unless you can figure out the algorithm that the manufacturer of the scale is using or get someone who created the scale to tell you what the data means you might be out of luck. Does the scale have any sort of developer documentation? – Zomb
It doesn't appear that they have developer documentation, or at least not on the web. Would it be possible to determine the handshake using the Ti packet sniffer? Or would that basically put me back in the same position? – Chrisgh
Sometimes you have to write a specific string of bytes to a certain characteristics to get data from the device. You can't catch that unless you have an already working app / software that properly communicates with the device. – benka
However you should convert those bytes (HEX) to decimals and compare them to the on-screen readings: E.g: FF-16-09-00-03-04-01-00-83-6F-F4-18-0F reads 256-22-09-00-03-04-01-00-131-111-244-24-15 Sometimes they have high bytes and low bytes in reverse order. Meaning low-byte first e.g.: 16 then high-byte: 09 will read 09-16 -> decimal: 922. – benka
Yeah, I tried parsing through the bytes and converting to various data types (decimal, int8, int16, uint8, etc.) None of the values particularly jumped out at me when comparing them to the weight and bmi the device displayed. I tried checking them as both lbs and kg and as deltas between previous readings rather than direct values. Nothing really stood out. Thanks though. – Chrisgh

1 Answers

1
votes

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.