Raw advertisement as a whole when BLE_GAP_EVT_ADV_REPORT is being fired - worked with v5, doesn't work with v7

[daten]

Hello,

I'm currently levelling up a project based on an older SDK which involved SoftDevice v5 (S132) to SoftDevice v7 (S140).

As far as I understand S132 and S140 are practically the same, just used on different hardware (correct me if I'm wrong), so I'm only differentiating between the release versions here.

While I managed to migrate almost everything to the new version (SDK / SoftDevice) one thing is puzzling me:

Apparently the event structure for BLE_GAP_EVT_ADV_REPORT changed.

The project I'm taking care of relies on the advertisement packet as a whole being being available - which works fine with v5.

With v7 however (and, considering the docs, probably v6 as well) I only get *part* of the advertisement packet. At least the structure is different.

When, for example, I'm receiving an advertisement from an iBeacon, p_gap_evt->params.adv_report.data.p_data used to contain the raw advertisement, beginning - in my case - with 0x02, 0x01, 0x06, .. while with v7 it starts with the (short) local name of the beacon.

Docs for v5: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v5.0.0%2Fstructble__gap__evt__adv__report__t.html&resultof=%22%62%6c%65%5f%67%61%70%5f%65%76%74%5f%61%64%76%5f%72%65%70%6f%72%74%5f%74%22%20%22%53%74%72%75%63%74%22%20%22%73%74%72%75%63%74%22%20%22%52%65%66%65%72%65%6e%63%65%22%20%22%72%65%66%65%72%22%20

Docs for v6: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v6.0.0%2Fstructble__gap__evt__adv__report__t.html&resultof=%22%62%6c%65%5f%67%61%70%5f%65%76%74%5f%61%64%76%5f%72%65%70%6f%72%74%5f%74%22%20%22%53%74%72%75%63%74%22%20%22%73%74%72%75%63%74%22%20%22%52%65%66%65%72%65%6e%63%65%22%20%22%72%65%66%65%72%22%20

How and where do I get the complete raw advertisement when BLE_GAP_EVT_ADV_REPORT is fired?

Thanks!

[Susheel Nuguru]

I think the advertising report struct has changed to support the features of BLE5.0 advertising extensions.

Have you looked into the SDK16\examples\ble_peripheral to see how the advertising report event is decoded?

[daten]

Well, I did. My nrf52 is acting as a *central*, though, *scanning* for beacons and parsing their advertisements.

As far as I can see, exampels/ble_peripheral contains example code for a nrf5x acting as a *peripheral* where the advertisement packets are crafted and sent out instead of scanned for, received and parsed.

Maybe my question was misunderstood?

[Susheel Nuguru]

sorry my bad, your question is very clear, I mistyped ble_peripheral instead of ble_central.

more specifically look at the example SDK_16.0.0_98a08e2\examples\ble_central\experimental\ble_nfc_pairing_reference_c\ble_m.c->on_adv_report()

[daten]

Hey, thanks for coming back to me. Looking at the provided example, on_adv_report() also only accesses p_adv_report->data.p_data and searches for the "local name" within that uint8_t-string.

As written initially, I already access p_gap_evt->params.adv_report.data.p_data and can see exactly the data the example you mentioned tries to access and parse.

However I need to access the raw advertisement packet *as a whole* - starting with the length+type+value of the first first.

That was possible via the same struct (p_gap_evt->params.adv_report.data.p_data) with previous SDK/SoftDevice versions.

[Susheel Nuguru]

looking at the nRF5_SDK_16.0.0_98a08e2\components\ble\common\ble_advdata.c->ble_advdata_search the contents of the adv_data seems to be the same as they were in SDv5, that is Length+Type+Data

So the contents of adv data given in p_adv_report->data.p_data with both versions seems compatible.

[daten]

Aye, I think I got to the bottom of this:

The beacon advertisement consists of the advertisement and a scan-response while in the advertisement report I only get *either*.

Within the levelled up project I'm using scanning with whitelists and filtered for the short local name of the beacon manufacturer.

However the short local name is not part of the advertisement packet but of the scan response.

When now the NRF_BLE_SCAN_EVT_FILTER_MATCH event is being fired and I look at adv_report.data.p_data I only see the data of the scan-response packet, which obviously doesn't match/start with the byte string I'm expecting (which would be the one from the advertisement packet).

That's how I came to the conclusion the API changed and I'm only having partial access. As a matter of fact I was filtering for and looking at the wrong packet.

I'm sorry for having wasted your time Susheel. Trying to make up with above explanation so it might be useful to somebody. Thank you!

While cause is clear now, solution isn't really: can I whitelist for manufacturer data (field type 0xFF) or the flags (field type 0x01)? Cause that's the only fields being transmitted in the advertisement packet I would be able to filter for. *Or* can I get the corresponding advertisement packet from the scan-response packet, as I'm able to filter for the latter one?