Has the format of ble_gap_evt_adv_report_t changed recently?

[SteveHx]

I have modified code for the Dongle to allow reporting multiple advertising devices, and select one device to connect to the USB/serial port. I can display the 64-bit unit ID and can connect and transfer data in both directions. My device inserts the name of the software in the advertising packet per some Nordic examples, and it shows up on the Android nRF Connect app. That app also shows "Raw Data" where I can clearly see the same field. When I attempt to make use of the name field in the Dongle code, sometimes it shows up, sometimes it's shifted a few bytes, and sometimes I get complete gibberish. From what I read, there is a ble_data_t field named data, with elements p_data that should point to the string, and len that gives the number of bytes. How should I use these to extract the text sent from my device?

[Einar Thorsrud]

I am a bit confused here. Did you fix the issue described i my previous post? Can you share your code so that I can see? If not, this is expected.

If you don't make progress you can instead refer to this sample that works and does the job of extracting short and full name, from advertising and scan respons packets. ble_app_name_scanner.zip

[SteveHx]

The suggested example is exactly the same code (with different formatting) as what I'm using from a Nordic-provided example (so long ago that I don't remember the specifics). I have tried looking up to 128 bytes out from p_data and the text is not present. Here's my code. Why doesn't p_data get pointed properly to the COMPLETE_LOCAL_NAME?

   case NRF_BLE_SCAN_EVT_FILTER_MATCH:
      {
      int i;
      nrf_ble_scan_evt_filter_match_t const * p_filter_match = &(p_scan_evt -> params.filter_match);
      if (NumSeen >= 50) NumSeen = 0;
      if (NumSeen < 50)
         {
         Seen [NumSeen].Adv = *(p_filter_match -> p_adv_report);
         ble_data_t const *p_d;
         p_d = &p_filter_match -> p_adv_report -> data;
         offset = 0;
         name_len = ble_advdata_search (p_d->p_data, p_d->len, &offset, BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME);
         if (!name_len) name_len = p_d -> len;
         if (name_len == 0)
            {
            offset = 0;
            name_len = ble_advdata_search (p_d->p_data, p_d->len, &offset, BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME);
            }

[Einar Thorsrud]

Hi,

I have several problems with this. Most importantly, you have not fixed th eproblem where your check for "if (name_len == 0)" can never be true as I explained in this post. That must be fixed. But I have general problems with this code and have seen and commented on several issues (and that is without having the full picture). I strongly recommend that you simply use and copy-past from the project I provided in my previosu post, which I have veriified works as expected, extracting both short and full name from addvertising and scan response packets.

[SteveHx]

Now back to this after a couple days' interruption by "life"....

I had removed the if (name_len == 0) line already, just hadn't updated the copy in the note above. Still, there's surely a clue in that ble_advdata_search returns 0, which would be perfectly reasonable as a flag that the pointer returned is not usable.

I copy-pasted your code in place of mine, and it behaves exactly the same, which would be expected since it's syntactically identical except for formatting. I started from the same example code you did, apparently.

Now what? I'm guessing that you're several hours ahead of me and thus about to leave for the weekend.

[SteveHx]

Since you're offline for the weekend, I did a bit more research. I found an example that extracts the name from the same struct, but uses the one passed to nrf_ble_scan_on_ble_evt() rather than the one passed to scan_evt_handler(). Works a treat! Now, how best to synchronize the two. Is it fair game to match up the peer_addr field of the ble_gap_evt_adv_report_t struct, to guarantee the name belongs to that unit?