LSByte first in radio payload field?

[Erlend]

Reading the nRF51 RM. On page 82 there is this:

But it doesn't make sense to me to talk about the LSByte of the PAYLOAD field, as it's just arbitrary data, and the Radio specs are agnostic of what is in it.

So what does this actually mean? Will I have to reorder bytes or bits when I specify payload data that is to be used in Bluetooth protocol?

[butch]

That just means the order over-the-air is the same as the order in RAM. (Some other radio hardware COULD do it differently.) Unless you are implementing your own BT stack, it is immaterial. If you are implementing your own BT stack, then it only matters if the BT specification requires a different over-the-air order?

[Erlend]

If I have understood it correctly: I just read that in general, nRF51 memory is little-endian (byte order). So by this premise, radio 'LSByte first' intuitively means that the order of bytes on air 'matches' the order of bytes in memory. Kind of imprecise and intuitive way to put it, in my opinion. What confuses me about it is that the radio wouldn't know where multi-byte integers reside in the payload and thus could have no concept of LSByte/MSByte. While it makes sense to talk about LSByte in the context of nRF memory implementation. So can I conclude: Bytes of the payload are transmitted in the order they reside in memory, while bit order depends on PCNF1?

[butch]

I agree with your interpretation. The radio doesn't know it as integers, just a stream of bytes. The language means the low address byte in memory is transmitted first, and as you say, the low bit of each byte is transmitted first/last according to PCNF1.

[David Edwin]

agree, as @butch states the stream cannot have endianness and the payload should be stated to be transmitted in the order they reside in memory.

[Stian Røed Hafskjold]

This has been reported internally