Advertisement packet loss in Coded PHY vs 1 Mb PHY

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Fri, 03 Jul 2020 09:04:42 GMT

Hi Kurtis

When you're increasing the scan interval and scan window, that also increases the time of how long you scan on each channel, so that might cause the packet loss you're seeing. See the picture below for reference (note that this is for "regular" BLE scanning, but it should be similar for Coded PHY as well AFAIK):

The only other thing I can think of is that your custom HW's antenna layout isn't optimal, and that causes the radio to drift and lose more packets when it is scanning for a longer amount of time.

Best regards,

Simon

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Thu, 02 Jul 2020 14:34:05 GMT

Simon,

To verify the packets were lost on air, I simultaneously debugged the BLE application through SWD printing what was received, and monitored the output from the host processor. When the host processor showed a missing packet, the debugger output also showed a missing packet.

Delays are not an issue at this point. I don't see using a shorter scan interval as an issue, although I am curious as to why it would make a difference.

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Thu, 02 Jul 2020 09:24:00 GMT

Could you provide any details as to how you confirmed the packets were lost on air? You could also try using SPI for transmission on the DK as well, just to make sure that it provides the same output as the UART.

If it is indeed on the air I think I'll have to see your hardware files to make sure the antenna matching, etc. all look good. Please let me know if you'd like me to set this case to private before you share any files and I'll do so.

Please note that we're entering the summer vacation period here in Norway, so delays must be expected as we are low on staff for the month of July. Sorry about the inconvenience!

Best regards,

Simon

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Wed, 01 Jul 2020 13:57:53 GMT

I haven't had a chance to test the longer interval on the dev board, but I did verify that it was being lost on air and not in the SPI.

In this application the central only scans and for this testing was only scanning the coded PHY.

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Wed, 01 Jul 2020 08:45:08 GMT

Does this apply to both the custom board and the UBlox BMD-360? It might be that the buffer fills up before the SPI/UART is able to pass it on on longer scan intervals, or are you positive that the data is lost on air?

Does this central application switch between scanning or advertising? If so, it might be that the longer scan intervals/windows are interfered by the device advertising (or trying to).

Best regards,

Simon

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Tue, 30 Jun 2020 20:18:49 GMT

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.

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Tue, 30 Jun 2020 13:24:03 GMT

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

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Tue, 30 Jun 2020 00:06:28 GMT

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.

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Wed, 24 Jun 2020 09:44:17 GMT

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

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Tue, 23 Jun 2020 20:38:47 GMT

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);
}

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Fri, 15 May 2020 09:11:58 GMT

Thank you for the update Kurt

This seems very strange indeed. You should have a much larger success rate with the setup you're describing. Coded PHY should definitely not be losing this many packets compared to the other PHY(s). Can you show me how your advertising initialization function looks?

You can also take a look at this example, where the ble_app_uart and ble_app_uart_c projects have been modified to use Coded PHY. Please keep in mind that you should set the advertising flag to GENERAL_DISC_MODE in this example to make it work properly.

devzone.nordicsemi.com/.../Long_5F00_range_5F00_15.2.zip

Best regards,

Simon

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Thu, 14 May 2020 19:21:03 GMT

I've repeated the experiment with 15 fewer data bytes, so now the GAP event structure reports a size of 15 bytes. I am still getting a packet loss rate of approximately 50%. I have verified that the advertiser is not reporting errors in sending.

I have performed another limited experiment where I have sent 15 advertisements with a delay of 100ms between them. In approximately 50% of those cases, the first advertisement is not detected. All the remaining advertisements are detected.

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Tue, 12 May 2020 07:37:55 GMT

Hi Kurt

Packets with a data length of more than 27 bytes in Coded PHY has an increased chance of losing packets. It would be better to transmit two smaller packets than one larger one when using Coded PHY.

Best regards,

Simon

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Kcecil — Mon, 11 May 2020 13:59:42 GMT

Simon,

Thank you for the quick response.

I want to make sure I understand. The 27 bytes per packet you reference, is that an extended advertising limit and if exceeded requires a second packet, thereby increasing the likelihood of interference?

Thank you,

Kurt

RE: Advertisement packet loss in Coded PHY vs 1 Mb PHY

Simonr — Mon, 11 May 2020 11:58:28 GMT

Hi Kurtis

Coded PHY is still limited to a data length of 27 bytes per packet. Longer packets than this will cause interference on longer ranges and will have a bigger chance for packet loss than when using 27 bytes or less per packet.

Best regards,

Simon