For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

RE: For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

Edvin — Wed, 17 Jun 2020 10:28:35 GMT

I have used the ble_app_beacon example, and the attached ble_app_uart_c to print the advertisements:

devzone.nordicsemi.com/.../ble_5F00_app_5F00_uart_5F00_c_5F00_scan_5F00_addr.zip

Please note line 407 in main.c.

RE: For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

Embedded_Engineer — Wed, 17 Jun 2020 08:27:13 GMT

1. From the call stack we see that nrf_ble_scan_on_ble_adv_report() is called (which is from case BLE_GAP_EVT_ADV_REPORT in nrf_ble_scan_on_ble_evt(), so yes we are viewing the memory within the said case.

2. Yes all the optimization are disabled ( -O0 )

3. The frame can created using the raw data shown above. If its possible for you then please do so using ble_peripheral\ble_app_beacon . Otherwise I will create a project exhibiting this and share with you later.

Thank you.

RE: For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

Edvin — Wed, 17 Jun 2020 07:26:39 GMT

I have never seen that it doesn't before. Are you sure your breakpoint is in a BLE_GAP_EVT_ADV_REPORT event, and not in another type of event? Also, make sure to turn off optimization in your project if you want to monitor the RAM during runtime.

If you have a project that I can recreate this with, it would be interesting to see.

RE: For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

Embedded_Engineer — Wed, 17 Jun 2020 04:53:32 GMT

[quote userid="26071" url="~/f/nordic-q-a/62625/for-128bit-uuid-filter-p_adv_report--data-p_data-is-updated-differently-for-different-tags/255313"][/quote]

In the advertisement report event, data.p_data[0] will always point to the first byte of the advertising data.

Perhaps you can try to print out the data in the advertising packet using something like this to see the content of the packets:

Thank you for your reply. This is exactly my concern that the data.p_data[0] is not pointing to the start byte of the frame for the second beacon. I think viewing the memory in debugger is more useful than printing the same.I understand the BLE advertising packets and have explained them too in the table I shared earlier.

Here is the complete frame received using nrf Android App.

Please have a look at memory pointed by data.p_data (0x200040DC).

I still need help to find out why first byte of frame is not the first byte pointed by data.p_data. Please have a look at the images (Note: UUID is deliberately hidden).

RE: For 128bit UUID filter p_adv_report->data.p_data is updated differently for different tags.

Edvin — Tue, 16 Jun 2020 14:48:08 GMT

Hello,

In the advertisement report event, data.p_data[0] will always point to the first byte of the advertising data.

Perhaps you can try to print out the data in the advertising packet using something like this to see the content of the packets:

            NRF_LOG_INFO("addr: %02x:%02x:%02x:%02x:%02x:%02x", p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[0],
                                                                p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[1],
                                                                p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[2],
                                                                p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[3],
                                                                p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[4],
                                                                p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[5]);
            NRF_LOG_RAW_INFO("adv_data: ");
            for (uint16_t i = 0; i<p_adv_report->data.len; i++)
            {
                NRF_LOG_RAW_INFO("%02x:", p_adv_report->data.p_data[i]);
            }
            NRF_LOG_RAW_INFO("\r\n");

That being said, different manufacturers will build up their advertising packet differently. You should iterate through the different flags.

Scanning the ble_app_beacon example should give something like this:

adv_data: 02:01:04:1A:FF:59:00:02:15:01:12:23:34:45:56:67:78:89:9A:AB:BC:CD:DE:EF:F0:01:02:03:04:C3

If you study how BLE advertising packets are put together you can see that first there is the 02, which means the length of this section, the type is 01, which is the flags, and the 0x04 is the "payload" of the flags. The next section is 0x1A (26) long, type is 0xFF, which is manufacturer specific data, and the remaining 25 bytes is the payload:

59:00:02:15:01:12:23:34:45:56:67:78:89:9A:AB:BC:CD:DE:EF:F0:01:02:03:04:C3

BR,

Edvin