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

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

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 :)

Parents
  • 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

  • - 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




  • Hi,

    Thank you for elaborate answers and logs!

    If you took the master branch from October 2018 then it was not equal to any stable release. The stable release at the time would have been pc-ble-driver v2.3.2, which uses a patched connectivity example from nRF5 SDK v12.2 and SoftDevices version 3.1. Currently, the stable release is pc-ble-driver v4.0.0 (which was released right before christmas) and it uses patched connectivity examples from nRF5 SDK v15.2 and SoftDevices version 6.1.0.

    Master branch at the time used SoftDevice 5 if I recall correctly, but it was not a finished release and although I do not know the specifics I know that there were quite a few unsolved problems with it. I highly recommend porting either to 4.0.0 (preferred) or to 2.3.2, in order to avoid further issues. I cannot guarantee that the issue that you see is solved in 4.0.0, but the team spent a lot of time on that release, mainly focusing on stability and robustness.

    Hopefully I can get the team to look at the logs and see if they find anything, but given that it was on an unknown non-production release I think it is little we can do. We would need to reproduce on 4.0.0 for registering a bug report and prioritizing fixing it. Would you be able to provide a minimal example reproducing this on 4.0.0?

    Regards,
    Terje

Reply
  • Hi,

    Thank you for elaborate answers and logs!

    If you took the master branch from October 2018 then it was not equal to any stable release. The stable release at the time would have been pc-ble-driver v2.3.2, which uses a patched connectivity example from nRF5 SDK v12.2 and SoftDevices version 3.1. Currently, the stable release is pc-ble-driver v4.0.0 (which was released right before christmas) and it uses patched connectivity examples from nRF5 SDK v15.2 and SoftDevices version 6.1.0.

    Master branch at the time used SoftDevice 5 if I recall correctly, but it was not a finished release and although I do not know the specifics I know that there were quite a few unsolved problems with it. I highly recommend porting either to 4.0.0 (preferred) or to 2.3.2, in order to avoid further issues. I cannot guarantee that the issue that you see is solved in 4.0.0, but the team spent a lot of time on that release, mainly focusing on stability and robustness.

    Hopefully I can get the team to look at the logs and see if they find anything, but given that it was on an unknown non-production release I think it is little we can do. We would need to reproduce on 4.0.0 for registering a bug report and prioritizing fixing it. Would you be able to provide a minimal example reproducing this on 4.0.0?

    Regards,
    Terje

Children
  • 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! 

  • 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

  • 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!

  • 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

  • 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.

Related