RE: Why is BLE_ADDR_OFFSET 3?

Tim — Thu, 29 Oct 2015 12:35:23 GMT

Ah very clear, thanks!

RE: Why is BLE_ADDR_OFFSET 3?

Trond Einar Snekvik — Thu, 29 Oct 2015 10:42:38 GMT

Hi,

You are correct about the BLE-specification, and the nRF51 radio has some additional conditions on the S1:

According to the nRF51 reference manual v3.0 ch. 17.1.2 (last paragraph), the header fields S0, Length and S1 will be represented as a whole byte in memory if they have more than 0 bit lengths.

In the BLE 4.0 spec, the length-field of a packet is only 6bits, leaving 2 bits as RFU. RFU bits should be set to zero by the transmitting radio and ignored by the receiving. On the nRF51, these two bits are represented by S1, but because of the byte-rule mentioned above, S1 must be represented as a whole byte in memory. So yes, there is a whole padding byte after the length, even though that field is only two bits in the BLE spec. If the packet for some reason breaks the BLE specification by having the two padding bits set to 1, it will get pushed into the two least significant bits of S1.

If we were to leave the Length field as 8bit (and S1 as 0bits), we could avoid this padding in memory, but the radio would not ignore these bits when calculating the length of an incoming packet. If another radio sets any of those bits, the nRF51 would then take them into account when calculating packet length and the position of the CRC field at the end, and attempt to receive a packet that is way too long, and has a seemingly invalid CRC.