As a third party, is there a viable way to correctly interpret data from a Bluetooth Low Energy device for which there is no published GATT profile specification?
The BLE device is a body scale that supports weight, BMI, body fat and hydration levels. I understand that there is no approved GATT profile for body scales, such as 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 applications (Ti BLE Multitool, LightBlue and BLE utility)
- The Android platform (4.3) (Dell Venue 8 3830) with the nRF main control panel, as well as the usual Xamarin solution.
I can scan, find, connect and read the GATT services available on the scale. All of the above tools provide me with the same overhead information. 5 services were found on the scale:
- Sharing (0x1800)
- General Attribute (0x1801)
- Device Information (0x180A)
- Battery Maintenance (0x180F)
- Unknown service with custom 128-bit UUID
All of the above tools can be read from known services, for example, to obtain information about the battery or the name of the device. My guess is that an unknown service with a user UUID is a service that provides scale data.
This service has 5 unknown characteristics with custom UUIDs:
- Feature 1 - Read / Write
- Feature 2 Read
- Feature 3 - Read / Write
- Feature 4 - Notification
- Feature 5 is read
Using the tools that were indicated above for reading from characteristics 1, 2 and 3, each returns its own value, but this value never changes. For example, reading characteristic 1 always returns 20 octets 0x01-0x05-0x06-0x07-0x08- and 15 0x00 octets. Subsequent reads of characteristic 1 always return this value. The read characteristic 2 always returns the value of 20 octets 0x02- and 19 0x00 octets. And so on.
A read index of 5 either does not return a value, or, most often, on Android, issues a pairing request. There is no common pairing code (e.g. 0000 or 1234, etc.).
Indicator 4 is what actually conveys scale data. Using the tools above, I can turn on notifications, and applications extract 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 these values begin with the same set of octets. The main problem is what these octets are and how they are converted to weight / bmi / hydration / body fat, if they actually do.
The scale is built with a Ti CC2541 microcircuit ( http://www.ti.com/product/cc2541 ).
Using the Snipe SmartPF packet package with the CC2540 analyzer package, I can capture packets between the iPhone 5S (iOS 7.1) and the scale. This provided additional information, but basically just shows what I have already observed using other tools, albeit at a lower level. Any additional information provided by the packet sniffer still leads to the same question: what are these sets of octets that the scale sends, and how do they convert to weight / bmi / etc? I used the documentation for the basic bluetooth specifications and it helped to understand what octets mean for standard / do functions, but it does not help to understand the actual scale data.
I am very new to the development of Bluetooth, and this exercise basically led to a course crash in this technology. Any help is appreciated.
Thanks.