Problem with getting location data and how to read Location data of hex value

Wireless Connectivity Ultra-Wideband
1

Hi,
I got the location data from my tag in position and distance location data mode.
But there are only 14 bytes data.
(There are at least 21 bytes data for postion(13byte) and distance(8~29 byte) following the API guide.)
What’s the problem?

And could you tell me how to read position data?
API guide only tell the data location of x,y,z but doesn’t tell how to change it to the actual units of m(?).
(I got the ‘00 12 00 00 00 CC 01 00 00 00 00 00 00 00 64’ data from tag that have x=0.02, y=0.46, z=0.00 coordinates in dacawave DRTLS app)

Thank you.

2

Hi,

Which interface do you use (UART/SPI/…)? It is likely the issue is in your read function. You should indeed receive more bytes. Check that the error code in the response is 0.

See the documentation https://www.decawave.com/sites/default/files/dwm1001-api-guide.pdf
(command dwm_pos_get): it says “32 bit value in little endian is x coordinate in millimeters” etc.

Cheers,
TDK

1 Like
3

Hey,

It looks like your location mode is set to position only. Do you use BLE to retrieve the data?
If yes, have a look at the DWM1001 API Guide at Section 7.1.3.
If you want to receive the positiong data among the actual distances, you should set the location data mode to 2.
For a description of different location data modes, have a lookout for “Location Data Mode” in the table in section 7.1.1.

Regarding the issue how to transform the received data into decimal based integers, keep in mind that each 32 bit integer is received in little endian.
Let’s say in position only mode you receive 14 bytes, right? For completeness, even though the docs say that only 13 bytes should be received, there’s actually 14 bytes received. Maybe the very first byte refers to an error code or the current location data mode, I don’t really know.

So, the next 4 bytes in the received byte array are the x coordinate. As stated earlier, this x coordinate was received in little endian. That is, in order to compose the x coordinate now, you have to create a new array and add the following data into it (in this order!):

val xByteArray = byteArrayOf(locationByteArray[4], locationByteArray[3], locationByteArray[2], locationByteArray[1])

As you can see, you simply need to reverse the order of the bytes because that’s how little endianess works. Next, compose the x coordinate with ‘xByteArray’ and go on and do the same with the y and z coordinate.

Have a look at my Kotlin implementation on github:
Location App

4

Hey max,

I took a look at your kotlin implementation, great stuff! Am wondering if you encountered any issues when filter the Mdek tags via UUID. I see that you have done so via MAC address filtering and am attempting to filter via the given service UUID in the mdek1001 API documentation.

5

I used the DWM1001 Dev Kits and not the MDEK Kits. What UUID issues are you referring to? AFAIK I didn’t have any troubles with them.

6

Thanks for the response! When inputting this uuid 680c21d9-c946-4c1f-9c11-baa1c21329e7 (given in the api doc) into the ScanFilter nothing shows up. So far only MAC address filtering works.

7

I think it depends on the OS you are running. Are you working on macOS? I think the macOS Bluetooth Adapter only works with MAC addresses whereas Windows, Linux and Android use UUIDs of a Bluetooth device. Could also be vice-versa but it fits to your problem. I had the same issues back then as I was developing the Android app on macOS.