This post got pretty far off topic with some good exchanges of information, but for those of you interested in the original topic, I have an update if you’ve made it this far. The recommendation to use pMsg->connOpen.peerRpa[0] to locate the friendly name, gets you in the ball park by coincidence but is not the best way. The advertised data, including the friendly name, is packaged in the data for a scan report. The start of this data can be accessed using pMsg->scanReport.pData[0]. The length of the data field is obtained from pMsg->scanReport.len. The actual data is made up of packets that begin with a packet length, then a type and then the packet data. The data type, the second byte of a packet, is 0x9 for the friendly name (i.e. DM_ADV_TYPE_LOCAL NAME) if it exists and the name will begin at the third byte. A type 0x8, if it exists, is for a shortened version of the name DM_ADV_TYPE_SHORT_NAME. A friendly name packet, if it exists, may not be the first data packet. Therefore, the data field has to be searched for a type 0x8 or 0x9 to find the name. To perform this search one starts at location pData[0], which contains the length of the first data packet (Length1). However, the length only includes the type and data bytes. The second byte of the first packet at pData[1] will be the type. If the type is not 0x8 or 0x9 then the next data packet begins at pData[Length1+1] and the next data packet type is at pData[Length1+2}. The entire data field, up to the length pMsg->scanReport.len can then be searched by hopping from one data packet to the next. Not all devices advertise a friendly name so the search may come up empty and the device will have to be identified by it’s address found at pMsg->scanReport.addr.