Why is BLE_ADDR_OFFSET 3?

[Tim]

I'm trying to do background transmission of an advertising packet using the timeslot API. I'm basing my code on the multi-role-conn-observer-advertiser example. My question is, why do they have the BLE_ADDR_OFFSET set to 3, when according to the BLE specification it is only 2 (after the 2 byte PDU header)? Is there some weird thing that you have to have a padding byte after the S1 part of the packet that doesn't get sent?

This extra byte is also skipped here (they skip a byte):

github.com/.../scanner_beacon.c

[Trond Einar Snekvik]

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.

[Tim]

Ah very clear, thanks!