nrf52840pdk AAR and Extended advertising

RE: nrf52840pdk AAR and Extended advertising

Jørgen Holmefjord — Fri, 30 Jun 2017 14:11:39 GMT

No, HW does not support whitelist for Advertising Extensions.

RE: nrf52840pdk AAR and Extended advertising

rymek — Fri, 30 Jun 2017 13:48:12 GMT

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

RE: nrf52840pdk AAR and Extended advertising

rymek — Fri, 30 Jun 2017 13:38:47 GMT

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

RE: nrf52840pdk AAR and Extended advertising

Jørgen Holmefjord — Fri, 30 Jun 2017 13:33:38 GMT

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.

RE: nrf52840pdk AAR and Extended advertising

rymek — Fri, 30 Jun 2017 11:50:12 GMT

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

RE: nrf52840pdk AAR and Extended advertising

Jørgen Holmefjord — Fri, 30 Jun 2017 11:33:48 GMT

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