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]

The sample I shared works, but I wonder if ther could be an issue with lifetime fo the moemory you are using (perhaps you re-start scanning before having parced the received advertising packet?). Can you share your whole project so that I get a better picture of the application?

Edit: I forgot to answer this specfic question:

SteveHx said:

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?

Note that you get the same struct on both. But of corse, when using the scan module you filter out some packets (which is the main point of the module), so if you filter out the packets you want for some reason, it would not show up. Also, you have the problem that information can be split across scan response and regular advertising packets. To match that up, you should use the address as you write, yes. That is not handled in the scan module, so it would be up to you.

[SteveHx]

This seems really clumsy and not as designed, but it'll do for now. I still don't understand why the p_adv_report returned in scan_evt_handler() appears to be complete gibberish, but I'll run with this solution for now.