nrf52840pdk AAR and Extended advertising

[rymek]

Is there a way to configure AAR so it can do address match for extended advertising packets? For legacy we had to:

• put address into DAB[] and DAP[] registers
• set DACNF to 1
• set ADDRPTR to beginning of the packet

This seems NOT to work for Extended advertising. Do we miss anything?

[Jørgen Holmefjord]

Hi,

The AAR was not intended for use with extended advertising when designed, as the device address is no logner located at the start of the PDU. You will need to add an offset to the ADDRPTR for the extended advertising PDUs and use the method you describe for legacy packets.

The address (if present in the packet) should be offset by two bytes from the start of the PDU. You will need to make use of pdu type, extended header length, and the extended header flags to set the correct offset. This should be described in the Bluetooth Core Specifications 5.0.

Best regards,

Jørgen

[rymek]

Hi,

Thanks for answer.

I'm afraid it will not work, as I understand that ADDRPTR was set to beginning of packet for the purpose to read address type from the Header flags. When I move ADDRPTR by offset you mentioned, AAR will not have the way to get addr type. Is this correct?

Best regards

Łukasz

[Jørgen Holmefjord]

According to the AAR documentation, the module should not care about address type:

The AAR will only do a comparison of the received address to those programmed in the module. And not check what type of address it actually is.

[rymek]

Ah yes, this is probably because address type is always RPA. Ok so it should work for address resolving. Thanks

[rymek]

BTW - whiltelist will not work for extended advertising at all, right?