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,

From your code excerpt it is impossible to tell how large data_buffer is. Are you sure it is large enough?

You write that you experience problems when testing with two different smartphones. Are those the only devices that you have used for testing? Do you have a second DK or Dongle that you can use with nRF Connect and see what packets you receive there? Or a sniffer log?

What SoftDevice and version are you using?

What version of pc-ble-driver are you using?

Regards,
Terje

[Muniek]

- Are you sure it is large enough?
Yes i'm sure its large enough, because I'm able to make manufacturer data lager and its works.

- Are those the only devices that you have used for testing?
No, we tested it on many phones, about 20.

- What SoftDevice and version are you using?
sdk 14, softdevice 5

- What version of pc-ble-driver are you using?
Sorry I dont know how to check this, I downloaded it from (Monday, 29 October 2018):
https://github.com/NordicSemiconductor/pc-ble-driver

Sniffer:

[ 02 1d 00 ff ff 01 c7 04 68 12 0e f3 cf 80 02 01 05 0c ff 88 44 55 01 03 11 22 33 44 55 66 ] - doesn't work

[ 02 1d 00 ff ff 01 c7 04 68 12 0e f3 cf a0 02 01 05 10 ff 88 44 55 01 03 11 22 33 44 55 66 66 66 66 66 ] - OK

[ 02 1d 00 ff ff 01 c7 04 68 12 0e f3 cf 78 02 01 05 0b ff 88 44 55 01 03 11 22 33 44 55 ] - OK

As you can see one buye less is OK, and even 4 bytes more is also OK.

this is my devices mac address: F3:0E:12:68:04:C7

[Muniek]

Ok, so I tested it on v4.0.0 and it the same (heart_rate_monitor_v5)

To reproduce this bug just edit advertisement_data_set() function:

static uint32_t advertisement_data_set()
{
    uint32_t error_code;
    uint8_t  adv_index = 0;
    uint8_t  data_data[BUFFER_SIZE];

    // Advertisement
    data_data[adv_index++] = 0x02;
    data_data[adv_index++] = BLE_GAP_AD_TYPE_FLAGS; // 0x01
    data_data[adv_index++] = BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;

    data_data[adv_index++] = 0x0C;
    data_data[adv_index++] = 0xFF;
    data_data[adv_index++] = 0xAA;
    data_data[adv_index++] = 0xBB;
    data_data[adv_index++] = 0x02;
    data_data[adv_index++] = 0x01;
    data_data[adv_index++] = 0x03;
    data_data[adv_index++] = 0x11;
    data_data[adv_index++] = 0x22;
    data_data[adv_index++] = 0x33;
    data_data[adv_index++] = 0x44;
    data_data[adv_index++] = 0x55;
    data_data[adv_index++] = 0x66;

    // Scan response
    uint8_t  sr_index = 0;
    uint8_t sr_data[BUFFER_SIZE];
    sr_data[sr_index++] = 0x08;
    sr_data[sr_index++] = 0x09;
    sr_data[sr_index++] = 0x43;
    sr_data[sr_index++] = 0x6F;
    sr_data[sr_index++] = 0x6E;
    sr_data[sr_index++] = 0x6E;
    sr_data[sr_index++] = 0x65;
    sr_data[sr_index++] = 0x63;
    sr_data[sr_index++] = 0x74;
    error_code = sd_ble_gap_adv_data_set(m_adapter, data_data, adv_index, sr_data, sr_index);

    if (error_code != NRF_SUCCESS)
    {
        printf("Failed to set advertisement data. Error code: 0x%02X\n", error_code);
        fflush(stdout);
        return error_code;
    }

    printf("Advertising data set\n");
    fflush(stdout);
    return NRF_SUCCESS;
}

Thanks! 

[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

[Muniek]

Hi, 
Yes, your are correct.
Today I was able to sniff both devices:

++++++++++GOOD++++++++++
8413 2019-03-08 10:38:19,024142 0.000482 c8:68:8e:d4:52:6c Broadcast LE LL 40 SCAN_RSP

0000 86 21 00 02 58 0e 06 0a 01 26 3d 00 00 f4 00 00 .!..X....&=..ô..
0010 00 d6 be 89 8e 44 0e 6c 52 d4 8e 68 c8 07 09 53 .Ö¾..D.lRÔ.hÈ..S
0020 65 6e 73 6f 72 8c 7a 07 ensor.z.

8414 2019-03-08 10:38:19,025007 0.000865 c8:68:8e:d4:52:6c Broadcast LE LL 48 ADV_IND

0000 86 29 00 02 59 0e 06 0a 01 27 45 00 00 be 01 00 .)..Y....'E..¾..
0010 00 d6 be 89 8e 40 16 6c 52 d4 8e 68 c8 02 01 05 .Ö¾[email protected]Ô.hÈ...
0020 0c ff 8d 04 04 03 01 70 b3 d5 c5 32 63 b2 35 48 .ÿ.....p³ÕÅ2c²5H

++++++++++++BAD++++++++++
276 2019-03-08 10:37:43,278682 0.000268 f3:0e:12:68:04:c7 Broadcast LE LL 40 SCAN_RSP

0000 86 21 00 02 ec ea 06 0a 01 27 39 00 00 c3 01 00 .!..ìê...'9..Ã..
0010 00 d6 be 89 8e 44 0e c7 04 68 12 0e f3 07 09 53 .Ö¾..D.Ç.h..ó..S
0020 65 6e 73 6f 72 24 38 38 ensor$88

277 2019-03-08 10:37:43,278955 0.000273 f3:0e:12:68:04:c7 Broadcast LE LL 48 ADV_IND

0000 86 29 00 02 ed ea 06 0a 01 25 3c 00 00 2c 01 00 .)..íê...%<..,..
0010 00 d6 be 89 8e 60 16 c7 04 68 12 0e f3 02 01 05 .Ö¾..`.Ç.h..ó...
0020 0c ff 8d 04 04 03 01 70 b3 d5 c5 32 63 75 3e 6f .ÿ.....p³ÕÅ2cu>o

WIRESHARK FILE:
wireshark.pcapng

[tesc]

Hi,

I have had a look at the wireshark file, and the advertisement packets look good in both cases.

However, the "bad" advertisement comes from a Bluetooth 5.0 compliant SoftDevice (as the ChSel field, that is the LE Channel Selection Algorithm field, is set indicating that the device supports Algorithm #2 from Bluetooth 5.0.)

This suggests that the issue might be related to the SoftDevice used, and not to pc-ble-driver.

What are the exact SoftDevices used for those two cases? (I.e. for the "good" and for the "bad" as listed from the wireshark file.)

What nRF52 SoCs (full chip markings) and boards (pca10040, custom, etc.) are used, also for both "good" and "bad" scenario?

Regards,
Terje

[Muniek]

GOOD - SoftDevice 4.0.2
BAD - SoftDevice 5.1

Both, good and bad is on the same devkit, PCA10040 v.1.1.0 2016.17
N52832
QFAAB0
1511AN

[tesc]

Hi,

I assume that you use S132. Let me know if that assumption is false.

Can you check if you get the "bad" behavior if you use a SD v5.1 version of the DK based application, instead of the SDv4.0.2 application?

There are quite a few bugfixes between v5.1.0 and v6.1.1 which is currently the latest version of the SoftDevice. It may be worth checking if the examples from SDK v15.3.0, using that latest SoftDevice, works with the affected phones, and then if pc-ble-driver v4.0.0 works when using SoftDevice s132 API version 6 and SoftDevice 6.1.1.

Regards,
Terje