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

Advertisement packet loss in Coded PHY vs 1 Mb PHY

Using the following:

Rigado BMD-360 nRF52811 development board.

Softdevice S140 7.0.1

SDK 16.0

Using two development boards inches apart, one development board sends a single advertising event every 12 seconds.  The other development board is continuously scanning (interval and window = 7s).  The packets have 30 bytes of data including a sequence number.  I calculated packet loss based on the missing sequence numbers.

Sending and scanning using the 1 MB/s PHY, in a test of approx. 20 minutes  I get 100% reception of packets.

Sending and scanning using the Coded PHY, in the same test I get ~43% reception of packets, ~57% packet loss.

Is this expected behavior, or could I be configuring something wrong when advertising using Coded PHY?

Another behavior I've seen is for the above condition using the Coded PHY to have a repeating pattern of receiving 3 and missing 2.

  • Simon,

    After being pulled away to work on other things, I am investigating this further.

    I am now using custom boards as well as development boards.  Currently I am experiencing approximately 20% packet loss under the original conditions.

    I have attached snippets of the ble stack init and the advertising init.

    static void ble_stack_init(void)
    {
        ret_code_t err_code;
    
        err_code = nrf_sdh_enable_request();
        APP_ERROR_CHECK(err_code);
    
        // Configure the BLE stack using the default settings.
        // Fetch the start address of the application RAM.
        uint32_t ram_start = 0;
        err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
        APP_ERROR_CHECK(err_code);
    
        // Enable BLE stack.
        err_code = nrf_sdh_ble_enable(&ram_start);
        APP_ERROR_CHECK(err_code);
    
    }
    
    static void advertising_init(void)
    {
    
        ble_gap_adv_params_t m_adv_params;
        uint32_t      err_code;
        ble_advdata_t advdata;
        uint8_t       flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
    
        ble_advdata_manuf_data_t manuf_specific_data;
    
        manuf_specific_data.company_identifier = APP_COMPANY_IDENTIFIER;
    
        manuf_specific_data.data.p_data = (uint8_t *) binData;
        manuf_specific_data.data.size   = BIN_DATA_SIZE;
    
        // Build and set advertising data.
        memset(&advdata, 0, sizeof(advdata));
    
        advdata.name_type             = BLE_ADVDATA_NO_NAME;
        advdata.flags                 = flags;
        advdata.p_manuf_specific_data = &manuf_specific_data;
    
    ...
        // Initialize advertising parameters (used when starting advertising).
        memset(&m_adv_params, 0, sizeof(m_adv_params));
    
        m_adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED;
        m_adv_params.p_peer_addr     = NULL;    // Undirected advertisement.
        m_adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
        m_adv_params.interval        = APP_ADV_INTERVAL;
        m_adv_params.duration        = APP_ADV_DURATION;
        m_adv_params.primary_phy	 = BLE_GAP_PHY_CODED;
        m_adv_params.secondary_phy	 = BLE_GAP_PHY_CODED;
        m_adv_params.max_adv_evts	 = NUM_ADV_EVENTS;
    
        err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
        if (err_code != NRF_SUCCESS)
    	printf("encode=%x\n", err_code);
    
        err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &m_adv_params);
        if (err_code != NRF_SUCCESS)
    	printf("cfg=%x\n", err_code);
        
        m_adv_data.adv_data.p_data[0] = 30;
        m_adv_data.adv_data.p_data[1] = 1;
        uint16_t *manuf_ptr = (uint16_t *)&m_adv_data.adv_data.p_data[2];
        *manuf_ptr = APP_COMPANY_IDENTIFIER;
    ...
        err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV, m_adv_handle, TRANSMIT_POWER);
        if (err_code != NRF_SUCCESS)
    	printf("power set failed=%x\n", err_code);
    }
    

  • Hi Kurtis

    Can you try to increase the advertising interval of your peripheral to see if that increases/decreases the packet loss?

    Also, have you checked out the example I uploaded in my last reply to see if the same packet loss can be seen there? I'd also like to know what device the scanner/central is here? Is this a DK as well or are you testing with some other device?

    Best regards,

    Simon

  • Simon,

    When sending a single advertisement, does advertising interval make a difference.  My understanding is that it is the time between advertising events, which should be irrelevant with a single advertisement.  I did some testing with 2 advertising events with various advertising intervals with very little difference in packet loss.

    It looks like the central example you uploaded doesn't fit in the nRF52811.  I don't know how relevant it is anyway, as it establishes a connection and my application is advertisement only.

    I have done more testing with the original conditions and with the receiving unit a custom board. In all tests the unit sending the advertisements is the Rigado BMD-360 dev board.  I have made some minor changes to both the sending and receiving code from the original testing, including changing the LF clock source from RC to Synth.  The code run on the nRF52811 on both the receiving dev board and the custom board are identical.  The BLE module in the custom board is the Rigado/UBlox BMD-360.

    On the dev board I am communicating with the module via UART, on the custom board it is via SPI.  The code determines which interface it is receiving data from and stops transmitting to the unused interface.

    With the receiving unit a BMD-360, with max advertising events set to 1, I am getting 0% packet loss.

    With the receiving unit a custom board, with max advertising events set to 1, I am getting 14% packet loss.

    With the receiving unit a custom board, with max advertising events set to 2, 30ms advertising interval, I got 80% receiving both packets and 20% receiving only 1 packet.  Upping the advertising interval, to 187.5ms and 375ms, I got 82% receiving both packets and 18% receiving only 1 packet. 

    When I first experienced the high packet loss with a dev board as the receiver, it was before I changed the LF clock source.

  • Hi Kurtis

    Thank you for the update. Can you provide some more details regarding your test setup? What kind of environment are you performing these tests in? What pins on the nRF52811 are you using for SPI communication, and what pins on the UBlox BMD-360 are you using for UART? 

    Seeing as the packet loss is now only seen on your custom board, I think we might have a hardware issue on our hands, as it might be that the custom board's antenna is not tuned optimally. If you'd like we can do a review of your schematics and HW layout for you, but I suggest you create a new (private) ticket for that, so we can keep this one public. This is entirely up to you though, and if you'd like, we can keep it in this ticket as well, and I'll set this one to Private mode if you prefer that.

    Best regards,

    Simon

  • Simon,

    It looks like the dropped packets are due to the scan interval/window.  I'm seeing a loss rate of ~15% with interval/window = 10.24s, 4% with interval/window = 7s, 0% with interval/window = 3.125.

Related