Confusion about writing/reading and decoding frames and frame formats - two way ranging

Ultra-Wideband
, ,
#1

In the application note “APS013: DW1000 and two-way ranging”, pg 6 - section 2.3.1 “General ranging frame format” there is a brief explanation of the frame format set out in the 802.15.4-2011 std.

Seeing as I don’t have a copy of the standard, nor would I fancy spending 255USD in acquiring this document, and Decawave’s documentation doesn’t provide a clear understanding of this issue beyond auto-appending of the FCS octet, I am turning to the forums for clarification.

Is anyone able to share information regarding the following:

  • In fig 4, there are hex values underneath the Frame Control and PAN ID octets, are these default values?

  • How much of these raw frames must be written/read by the host? Are we only meant to write the message portion? If note, is there any portion of the frame that is extracted from other registers (apart from the automatically incremented sequence number and the auto-generated CRC placed in the FCS octect) i.e. PAN ID, FC (Frame Control), Dest Addr, Src Addr etc… ?

  • If configuring a raw frame is necessary, does anyone have the bit encodings for the Frame Control, PAN ID, Dest Addr, Src Addr octets? Most importantly the Frame Control octets.

  • On a slightly related note: if writing and reading raw frames is not necessary, is a ‘range init’ frame sent automatically or does the host need to decode the blink frame and respond?

Any information or guidance would be greatly appreciated.

Kind Regards,
medicineman25

#2

Ok so I can see now that the entire raw frame needs to be written. That’s fine.

However, I am still at a loss as to the MAC headers for each message format. If anyone could share this information that would be great, because I’m not shelling out $500 for two standards (one an amendment) that I don’t actually need, outside of one small piece of information that quite frankly: should have been freely distributed with this product.

#3

The way I look at it is that if you need to be compatible with the standard then buying a copy is probably a good idea, if not for this detail then for other details at higher levels within the protocol.

If you don’t need to be compatible with the standard then do whatever you want and don’t worry about it.

#4

Yeh definitely, I get that a payload can be arbitrary or to a standard… but so what you’re saying is this portion of the frame has precisely zero bearing on anything functionality-wise except standards compliance?

Ok cool. I’ll just do something arbitrary for dev until I need compliance.