PC-BLE-Driver - Some advertisement lengths faulty/forbidden? [sdk5 v14.0.0]

[Muniek]

Hi,
I have strange problem using pc-ble-driver on nrf52 with heart_rate_monitor example.
When I set advertisement data to be 16 bytes long, two of our testing phones cannont see proper advertisement data (iPhone 6 iOS 10.2.1 and Sony Xperia Z5 Android 7.1.1)
It should me seen as connectable with 11 bytes of manufacturer data, but it's seen as unconnectable and without manufacturer data at all.
When I change manufacturer data to be one byte shorter, then everything is ok, one or two bytes more and it doesn't work, 6 bytes more and it start working again.

This is (not working) my setup:

    data_buffer[index++] = 0x02;
    data_buffer[index++] = BLE_GAP_AD_TYPE_FLAGS; // 0x01
    data_buffer[index++] = BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;

    data_buffer[index++] = 0x0C;
    data_buffer[index++] = 0xFF;
    data_buffer[index++] = 0x88;
    data_buffer[index++] = 0x44;
    data_buffer[index++] = 0x55;
    data_buffer[index++] = 0x34;
    data_buffer[index++] = 0x03;
    data_buffer[index++] = 0x11;
    data_buffer[index++] = 0x22;
    data_buffer[index++] = 0x33;
    data_buffer[index++] = 0x44;
    data_buffer[index++] = 0x55;
    data_buffer[index++] = 0x66;

    uint8_t sr_data[9];
    sr_data[0] = 0x08;
    sr_data[1] = 0x09;
    sr_data[2] = 0x43;
    sr_data[3] = 0x6F;
    sr_data[4] = 0x6E;
    sr_data[5] = 0x6E;
    sr_data[6] = 0x65;
    sr_data[7] = 0x63;
    sr_data[8] = 0x74;
    error_code = sd_ble_gap_adv_data_set(m_adapter, data_buffer, index, sr_data, 0x09);

Thanks for any help :)

[tesc]

Hi,

I have not reproduced this locally yet, (need to get hold of particular phone,) but:

The sniffer packets that you provided looks perfectly fine. The contents of the manufacturer specific data, on the other hand, is not, since the first two bytes of the manufacturer specific data should contain a company identifier:

"The first two data octets shall contain a company identifier code from the Assigned Numbers - Company Identifiers document." - Core Specification Supplement v7, Part A, section 1.4.1.

I do not think that it should matter in this situation, that the first two bytes are outside of the range of assigned company identifiers, but you could try using for instance the identifier of Nordic Semiconductor (0x0059) for testing.

In my end I will try to find a phone that lets me reproduce, but this looks more and more like an issue in the phone end... It may be that the only workaround for this issue is to keep to data lengths that are known to be working.

Regards,
Terje

[Muniek]

Actualy at first I have tried with valid company identifier used by my company but with the same result.

I think the problem is deeper and I need to sniff whole frame sent by device including CRC, because we also produce our own BLE devices with nordic nRF52 chip, with excatly the same Advertisement/ScanResponse and every phone we have can see whole manufacturer data without any problems, so it makes me think that pc-ble-driver has some kind of weird bug in it.

But how can I sniff whole frame using nRF52 DevKit or Dongle?

Thanks!

[tesc]

Hi,

You can use the nRF Sniffer, which lets you use an nRF DK or Dongle with Wireshark.

I might have misunderstood the situation, can you confirm that you saw this on two phones but not on the others?

Regards,
Terje

[Muniek]

Sorry for late response, I missed your message.
Yes, as I wrote in first post, we have tested this on oabout 20 phones, and only on two of those we see that problem.
But when we dont use pc-ble-driver, but just our own ble devices with nRF52 chip with excatly the same advertisement and scan response, this problem doesn't exist at all.

[tesc]

Hi,

So to summarize: The issue is seen when you combine the "right" amount of advertising data, with pc-ble-driver advertiser, with either of two particular smartphones scanning (iPhone 6 iOS 10.2.1 and Sony Xperia Z5 Android 7.1.1). Other phones work with the same pc-ble-driver advertiser, and similar advertiser on nRF52 SoC work with the two phones. Other advertising data lengths also work fine with pc-ble-driver + particular smart phones.

It would still be interesting to look at a sniffer log of the advertisements, to see if anything is off there. I.e. sniffer traces of both pc-ble-driver version and native nRF version of the failing advertising, and also the working and non-working advertising lengths with pc-ble-driver.

I will try again to locate one of the particular phones so that we can try to reproduce locally.

Regards,
Terje