Hi there,
I am testing the anchor location setup function on the android app.
For anchors, the position contains 13 bytes, as x, y, z for 4 bytes each, and 1 byte for qf.
However, when I try to set some bytes to the x/y/z fields, and read them again, the bytes I got are not the ones I initially put into.
For example:
Initially I put 0x002519ee007e1a880007000000 as the byte stream into DWM1001-Dev through the android app. When I decode it, I got 0x012519ee807d1a880007000000.
Everytime the erroneous bytes aren’t giving me consistent values.
It seems to me that some indices within this byte stream have problems. They happen to be the LSB or Less-SB of the integers used by X, Y, Z in millimeters. After the rounding activities they are not quite obvious or won’t even render an error.
What is going on here and can anybody tell me what is the cause of this problem?
Thanks a lot
Anyone can also test the same thing to see if it behaves similar:
Encode some specific Position class 13-byte into an anchor, using the Android DRTLS app with logs. Decode again from the anchor and compare. It might not be the same.
Would love to learn why this happens. Thank you very much
New discovery:
In regular uses, the error exists but won’t do much damage to the data integrity because:
- The bytes with errors are often the LSB for each integer storing X, Y, Z mm values.
- The mm integer values are rounded or precision-lowered into cm or inches so that the error won’t affect much.
However, in our use case, we would love to re-use these bytes to store other information with different precision levels. Therefore, we are wondering: is there anything inside the closed-source firmware that does any processing over the 13-bytes transferred from BLE? What is the purpose of doing so?
If anyone is interested in reproduce this bug, please let me know and I am happy to help and instruct in details. Thanks a lot.