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)
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, locationByteArray, locationByteArray, locationByteArray)
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
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.
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.