This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Scanning for the Short Local Name of an iOS device from an nRF52 based product

In the products that I am developing we use advertising packets in the scan response to pass some data around our devices. We wanted a way for the app we've made for iOS to participate. Mac doesn't give us full control over the Bluetooth stack, but it gives us the option to change the Short Local Name (BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME). We are having it modify that name to pack our data in it and modifying the scanner code I've written to parse the Short Local Name. The problem is I never receive the Short Local Name data from in the event data pointer. I've checked the raw data and see all the other devices I'm working on around the office, but never the altered Short Local Name. Using nRF Connect I can find the device and watch it update values live. It seems like the Softdevice filters away data from iOS devices or even all smart phones. I'm not sure what it is and I haven't any documents that suggest that. So my question is: am I not getting the data because it's not passed along by the Softdevice and are there some settings that I can change to reconfigure the Softdevice to pass that information along to my code.

The below code parses out the device Short Local Names fine, but I don't think that the data is ever getting passes to this snippet of code from the iPod I'm using to test, but the iPod does seem to broadcast the altered Short Local Name. There are a few log hex dumps where I can observe the raw packets and what has been found.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
NRF_SDH_BLE_OBSERVER(scanner_observer, SCANNER_BLE_OBSERVER_PRIO, scan_on_ble_evt, NULL);
static uint32_t _adv_report_parse(uint8_t type, uint8_array_t * p_advdata, uint8_array_t * p_typedata)
{
uint32_t index = 0;
uint8_t * p_data;
p_data = p_advdata->p_data;
// NRF_LOG_HEXDUMP_DEBUG(p_data, 31);
while (index < p_advdata->size) {
uint8_t field_length = p_data[index];
uint8_t field_type = p_data[index + 1];
if (field_type == type) {
p_typedata->p_data = &p_data[index + 2];
p_typedata->size = field_length - 1;
return NRF_SUCCESS;
}
index += field_length + 1;
}
return NRF_ERROR_NOT_FOUND;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Here's a screen shot of the correct data in nRF Connect:

I'm using SDK15.3 and Softdevice 6.1.1 with my Windows 10 workstation running Segger Embedded Studio V4.50

  • HI Ryjan, 

    so there is no AD element with AD type 0x08 «Shortened Local Name» ? https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/

    Can you post the raw hex data that p_ble_evt->evt.gap_evt.params.adv_report.data.p_data points to?

    Best regards

    Bjørn

  • I'm able to find the advertising type 0x08 Shortened Local Name for several other devices that are nearby (and based on the nRF52), but I cannot find any advertising packets that I can identify are from the iPod that is programmed to have a unique identifier in the Short Local Name type. Below is a hex dump of the data that you asked for:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    scanner: BB 27 BF 02 AB 45 48 1E|.'...EH.
    scanner: D7 01 00 96 05 09 08 52|..... .R
    scanner: 00 53 |.S
    scanner: 02 01 1A 0C 09 4B 40 61|.... K@a
    scanner: C3 94 05 64 19 07 0B 22|...d..."
    scanner: D7 01 00 96 05 09 08 52|..... .R
    scanner: 6F 6C 6C 65 72 53 68 |ollerSh
    scanner: D7 01 00 96 05 09 08 52|..... .R
    scanner: 6F 6C 6C 65 72 53 68 |ollerSh
    scanner: 02 01 1B 0B FF 4C 00 09|.....L.
    scanner: 06 03 19 C0 A8 02 04 22|......."
    scanner: D7 01 00 96 05 09 08 52|..... .R
    scanner: 6F 6C 6C 65 72 53 68 |ollerSh
    scanner: 6C 69 6E 64 5F 44 46 55|lind_DFU
    scanner: 02 01 06 96 05 09 08 52|..... .R
    scanner: 6F 6C 6C 65 72 53 68 |ollerSh
    scanner: 02 01 1B 0B FF 4C 00 09|.....L.
    scanner: 14 FF 01 04 00 00 00 00|........
    scanner: 00 00 00 00 00 00 00 00|........
    scanner: 00 00 00 00 00 09 16 DD|..... ..
    scanner: 0A 88 0F 0B 83 45 E9 |.....E.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    In this case ";n̺©S"(3B 6E CC BA A9 53) should appear as the first 6 bytes of the Short Local Name type, but it does not show up in any of the data I get.

    Also here is a look at the terminal print out when I am filtering on the Short Local Name type:

  • Hi Ryjan, 

    Are the hex dumps of the advertisment data payload from the iPod only or is multiple devices? To me it seems like its the latter? Can you filter the advertisment reports on the ipod address so that we only see the advertisment payload from said device?

    or 

    Would it be possible for you to capture the on-air advertisment packets from the iPOD using the nRF Sniffer and a NRF52 DK?

  • That did include all the advertisements because I could not find the correct advertisement. At this point I'm finding the data I was looking for, but I'm verifying a few things before I report my findings. I'll be undoing some of the things we tried to see what actually made the difference. Then I'll update this thread.

  • Ok,  that makes sense. Good to hear that you're now seeing the data in the adv.packet payload.  I just wondered if the hexdumps were from the iPod only as I could see a 0x08 AD type in the data, but there was something weird with some of the packets

    scanner: 02 01 1A 0C 09 4B 40 61|.... K@a
    scanner: C3 94 05 64 19 07 0B 22|...d..."
    scanner: D7 01 00 96 05 09 08 52|..... .R
    scanner: 6F 6C 6C 65 72 53 68 |ollerSh

    02 01 1A is a two byte AD element of the Flags AD type with value 1A

    0C 09 4B 40 61 C3 94 05 64 19 07 0B 22 is a 12-byte AD element of the Complete Local Name type (0x09) 

    after that it could look like its a AD element of length D7 of the type 0x01 type, which doesnt make any sense. Then some bytes later there is 

    09 08 52 6F 6C 6C 65 72 53 68  which corresponds to a nine byte AD element of type 0x08 ( Shortened  Local Name ) with value RollerSh

1 2