Backhaul response structure

Wireless Connectivity Ultra-Wideband
, ,
1

Greetings,

I would like to know what is the structure of the data that comes in the response message using dwm_backhaul_xfer through SPI communication. How should it be read? What are the response message components? For example to a request that is defined in the documentation (0x37 0x02 0xf4 0x00) I’m able to receive responses about the network anchors in various forms where one of the forms look like:

6E 04 87 00 00 00
79 02 10 01 8F 41
89 78 00 20 11 44
57 34 31 38 46 00
00 00 00 00 00 00
00 00 00 00 78 00
00 00 00 00 01 00
C0 40 67 66 E6 3F
00 00 00 00 00 05
32 00 32 00 00 00
00 00 00 00 00 00

Where all of the bytes are static (meaning that different messages contain the same values) except the first lines last four bytes. Which maybe are IOT data taking granted that the IOT uplink response message byte is after these bytes (79). After the byte 79 I believe that there could be backhaul status values (bytes 02 10 and 01) and at the end of line two there is two byte node id in little endian.

The response message about the tag (bytes are modified with spaces for optimal readability of my understanding of the possible format):

6E 04 26 04 00 00

78 02 10 01 2A 1C

0D 00
00 00 C0 7F
00 00 C0 7F
00 00 C0 7F

79 02 10 01 2A 1C

88 32 00 20
12 44 57 31 43 32
41 00 00 00 00 00
00 00 00 00 00 05
32 00 32 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00

Message without spaces applied:

6E 04 26 04 00 00
78 02 10 01 2A 1C
0D 00 00 00 C0 7F
00 00 C0 7F 00 00
C0 7F 79 02 10 01
2A 1C 88 32 00 20
12 44 57 31 43 32
41 00 00 00 00 00
00 00 00 00 00 05
32 00 32 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00

Here we can see response message about the tag that in my opinion is not able to calculate its location hence the three lines with the same values (00 00 C0 7F), that could mean the value “NaN” which shows when the calculation is unsuccessful. Similarly to the anchor response message, the first lines last four bytes change from message to message. Further there is location data response byte (78) and, analogous to the line containing the byte 79 both in this message and in the anchors message, also tree bytes of static data after which the node id (in this case the tag node id) in little endian. The location data has 1 byte more than the location data value defined in the documentation (Firmware API guide “dwm_pos_get”) so this creates a little bit of an uncertainty.

Example of a response message with a successful (in theory) location calculation.

6E 04 86 02 02 00

78 01 10 01 2A 1C

0D 7E
CE 26 A0 3D
E3 98 9F 3E
04 14 C6 3F

79 01 10 01 2A 1C

88 32 00 20
12 44 57 31 43 32
41 00 00 00 00 00
00 00 00 00 00 05
32 00 32 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00

Message without spaces applied:

6E 04 86 02 02 00
78 01 10 01 2A 1C
0D 7E CE 26 A0 3D
E3 98 9F 3E 04 14
C6 3F 79 01 10 01
2A 1C 88 32 00 20
12 44 57 31 43 32
41 00 00 00 00 00
00 00 00 00 00 05
32 00 32 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00

There already are posts about this question to which sadly there are no answers yet. But I still hope that someone can clarify this.

Respectfully,
Audris

2

I’ve found a new pattern in the data, but still it didn’t help to understand the whole picture.

0B 92 | F4D118 40 | 2A520E 40 | E9D412 3F

04 B9 | 6A0147 3F | 87332E 40 | CA21A5 3F

02 A2 | 84BE24 3F | 299EEF 3F | 5FC2A6 3F

0C 8E | 777CF4 3E | B63CF2 3F | 10B419 3F

0B A2 | 70C4ED 3F | 32DA13 40 | C9DC00 3F

0D 7E | CE26A0 3D | E3989F 3E | 0414C6 3F

01 97 | 94B1DE 3F | E072F1 3F | CE5A9A 3F

0D 00 | 0000C0 7F | 0000C0 7F | 0000C0 7F

Here you can supposedly see the location data (comes after the data - 78 … … … XY ZV where XY ZV is node id in little endian just the same as the examples above). I saw some similarities with the dwm_loc_get because of the first byte which is between 00 and 0F (the count of the distances to the anchors which limit is 15). After that i came across the pattern of 3F, 3D and so on. Which seems like the quality factor of the distances received. So now it got me thinking that these could be the distances to the anchors. It seemed odd that there are only three for both networks - 3 anchors and 4 anchors (data that I acquired came from these types of networks). And now I started to doubt my theory. Although the documentation (Firmware API Guide, page 53) states and i quote: “2-byte long for SPI/UART response for Tag” which applies to qf, distance UWB address and the actual distance value. It seemed odd to me that qf now has 2 bytes to work with even though it’s limited to 0 - 100. By taking into account all of these new features that might be working here, it still didn’t make anything as clear as needed for being able to actually read the data.

Can someone bring clarity upon these uncertainties?

P.S. The communication was established through bridge node not the tag node, although the data that was received is from a tag, so that’s why i thought that the cited sentence about the specific message length applies also here, taking granted that the message technically comes from the tag.