BLE location data packet format UWB-1001-dev

Good afternoon,
I’m trying to set up RPi Zero W V1.1 as an interface between UWB network and internet using BLE (so RPi is going to be uploading location information to the server). Reading through the BLE API guide provided, I was able to connect to the tag and request location data information (operation mode 2 so location+distances), but I have trouble deciphering the packet that I get. I know the first 12 bytes are supposed to represent the tag’s position (x,y,z), but when I convert the bytestring to integers, there is some structure, but I don’t know exactly what each integer means.

I tried finding more information on this in documentation, but I wasn’t able to find it. I’m using bluepy library in Python. I have only 3 anchors and a tag so I can’t set up a gateway for this proof of concept. Trying to use Python struct to interpret the data, more info: struct — Interpret bytes as packed binary data — Python 3.10.4 documentation.

Basically what I’m looking for is the format argument for characteristic with UUID: 003bbdf2-c634-4b3d-ab56-7ec889b89a37 (Location data, more info: API guide section 7.1.3)

Hi mrkier,

from documentation:
“X, Y, Z coordinates (each 4 bytes) and quality factor (1 byte), total size: 13

the X, Y, Z are signed integers, 4 byte wide, in little endian and the last byte is the unsigned int which represets a quality factor. If you are asking how to parse a byte stream in python I would suggest to study some examples and tutorials on how to do that.


Hi JF,
Thank you for your response. I know how to parse a byte stream in python. With little endian formatting for a 32-bit float in IEEE754 standard I can input 4 bytes of hex values D0 0F 49 40 to get 3.14159 (checked for correctness here)

A sample raw packet in operation mode 2 (location+data) I’m getting is: b’\x02\xdf\x00\x00\x00\x9a\x00\x00\x00\xf5\xff\xff\xff<\x03\x86M\x00\x00\x00\x00d\x82\x94\x00\x00\x00\x00d\x01\x96\x00\x00\x00\x00d’

Using the first 12 bytes of data and converting it to 32-bit float in IEEE754 standard I get:
02 df 00 00 → 8.000013e-41
00 9a 00 00 → 5.524479e-41
00 f5 ff ff → nan

In case the quality factor is the initial byte I can take bytes 2 through 13 to get:
df 00 00 00 → 3.124896e-43
9a 00 00 00 → 2.158e-43
f5 ff ff ff → nan

I’m looking at many different decoding approaches (big endian, little endian, mid-big, mid-little with these values and nothing makes sense so far.

I know the set up is working, because I’ve tested it with my phone successfully and the location data from the presented packet should have values similar to: x=0.2m, y=0.2m, z = 0m

Could you confirm with me the following?

  • upon read of tag’s BLE characteristic with UUID: 003bbdf2-c634-4b3d-ab56-7ec889b89a37 I should get position data and distance readings
  • the first 12 bytes in operation mode 2 represent position x,y,z (each a 32-bit float representing location in meters)
  • quality factor is the 13th byte (uint8)

Please kindly correct me if I’m mistaken in my assumptions, let me know if anything needs clarification

Hi @mrkier
the encoded data are not in Float but they are 32bit integer as it is described in chapter 4.4.2 - see the description below.

4.4.2 position
13-byte position information of the node (anchor or tag).
position = x, y, z, pqf : bytes 0-12, position coordinates and quality factor
x : bytes 0-3, 32-bit integer, in millimeters
y : bytes 4-7, 32-bit integer, in millimeters
z : bytes 8-11, 32-bit integer, in millimeters
pqf : bytes 12, 8-bit integer, position quality factor in percent

Regarding BLE characteristics - you need to select a Location data mode by writing into a02b947e-df97-4516-996a-1882521e0ead characteristics. And then you can read data from Location data characteristics which will return you the data with the regards of the Location data mode setting.

Im not sure if you output is correct as you have there characters ("<" and “M”) that should not be in the output.

Please note that first byte is the Location data type, then follows XYZ and then QF.

Cheers JK


1 Like

Hi JK from @leapslabs,

I should have been more thorough with reading the API guide. Maybe a quick reference to generic API info in BLE guide would be helpful in cases like mine. I wanted to say other than that, the guide was very clear so kudos. Works like a charm now, thank you so much.