BLE GATT characteristic parsing

Hi There,

Sorry if this has already been answered elsewhere but I wanted to know what the easiest way of parsing BlueTooth characteristic types, in particular ones such as the example below which have several fields to pick from:

https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Characteristics/org.bluetooth.characteristic.rsc_measurement.xml

I have managed to extract the heart rate data but just by messing with string manipulation but for more complex ones I don’t see how it’s possible in App Inventor. If there is an extension which allows you to use an XML spec to expose each field that would be ideal.

Martin

Look into the Web Component for XML decoding.

Also see

1 Like

I have been using the BytesReceved for sensor data like Heart Rate and Speed Sensor. Then you can manipulate each byte as needed.

1 Like

Thanks - I’ll see how I get on :slight_smile:

Hi guys - I’m trying to filter what’s coming through the bytes received, but wondered if the data can easily get mixed up e.g power value and battery level - is this possible? I’ve been selecting the 3rd string along for power but think it might be a moving target:

. Heart rate works all the time and HRM battery level.

I think you just need to register for bytes once for each device. I am using an HRM, Speed Sensor and Cadence Sensor and Register for bytes once for each one. I use three Bluetooth LE components one for each device.

I’ve figured out what’s happening, when the PWR gets above 255W it clips and I just get the left-over e.g if it’s 257W I get 2W, so looks like I was only getting literally one byte, but when I tried to get the one next to it no luck. Ideally I’d have a bit mask I can AND over the whole data - think that’s what I need to do. Think it’s the 2nd block of 16 bits I need to focus on for cycling power data.

I tidied up all characteristic literals so it’s all done with lookups in plain English. I was also doing > 1 read bytes operation per bytes received which didn’t help! So stored it in a local variable at the top :slight_smile:

Hi @Martin_Wood,

If the characteristic is intended to be larger than a single byte (and it’s fixed width), consider using RegisterForShorts instead as that will give you 2-byte wide values, which implies an unsigned range of 0-65535. Do you have a pointer to the exact characteristic you’re reading that’s going beyond a single byte?

H there @ewpatton - using RegisterForShorts worked great - thank you!! Now to see what other similar data items I can poll e.g cadence data. If there’s anything that changes position within the data that’s going to be more challenging, so leave that for now eh :slight_smile:

Yes, unfortunately we don’t have a good solution right now for more arbitrarily structured BLE packets. You can use the bytes version for this but you end up needing to implement a bit of math to reconstruct the larger values from the individual bytes.