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

Different transmission behavior between coded PHY (125kbps) and 1Mbps PHY

Hi,

During our development, we observed that when BLE central and peripheral devices are communicating, then often central device will not receive data from peripheral device at the specified connection interval but receive new data and old data in the next connection interval.

for example, if connection interval is 12.5ms and peripheral device need to send data (assume an incrementing number for simplicity) to central device then central device receives data at following times:

t = 0 ms, received data = 1

t = 12.5 ms, received data = 2

t = 25 ms, no data received

t = 37.5 ms, received data = 3

t = 37.5 ms, received data = 4

t = 50 ms, received data = 5

So when peripheral and central device failed to exchange data at t = 25 ms, then in next connection interval, peripheral soft device not only transmitted new data but also transmitted data queued for transmission in the previous connection interval. Which means soft device must be keeping data in some queue and as long as there is enough guard interval in between connection intervals, it will transmit all queued data. This is happening with 1Mbps PHY.

But when we switched to coded PHY for improved sensitivity, then we are observing difference in this behavior. Upon missing data transmission in a connection interval, peripheral soft device no longer re-transmits the queued data.

 

t = 0 ms, received data = 1

t = 12.5 ms, received data = 2

t = 25 ms, no data received

t = 37.5 ms, received data = 4

t = 50 ms, received data = 5

This is leading to loss of data which is not acceptable in our application. 

So I would like to know that is this a known/expected behavior of soft device when using coded PHY? or am I missing some configuration in coded PHY mode?

My application is using "s140_nrf52_6.1.1_softdevice.hex" and to update PHY after central and peripheral devices have connected, central device uses sd_ble_gap_phy_update() API.

regards

Ankur

  • I tried increasing event length to maximum on D3 (25ms).

    Since D2 is running multiple roles at the same time and I couldn't figure out the way to set different event length for different connections, I also set event length as 25ms on D2 as well.

    att_mtu_throughput examples also has this comment about event length

    static void gap_evt_len_cmd(nrf_cli_t const * p_cli, size_t argc, char ** argv)
    {
        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, "This value cannot be set at runtime.\n"
                                               "Modify NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h "
                                               "and recompile the application.\n");
    }

    But packet loss is still occurring. I also tried enabling event length extension but no improvement.

    Is there anything else that would recommend?

    Now I am trying to setup sniffer to capture packets bewteen D2 & D3. This is what I am doing:

    • Configured following versions of s/w: nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3, Wireshark 3.2.1 as per nRF_Sniffer_UG_v2.2.pdf
    • I can see nRF Sniffer for Bluetooth LE COM29 in interfaces and select it to start capture
    • Select device D3 in list of devices (WLSab6da871, MAC db:3c:ab:6d:a8:71)
    • Start connection bewteen D3 & D2
    • I see connection request on D3 but then capture stops and no data between D2 & D3 is captured. Sniffer automatically starts capturing some other devices

    Is there any other constraint for sniffer to work? Since D3 & D2 uses coded PHY to communicate, can sniffer capture coded PHY packets?

    thanks

    Ankur

  • I suggest you use Rev 3.1 of the sniffer: Revision history

    That sniffer trace looks alright. A CONNECT_REQ, followed by empty PDUs (to maintain the connection), and a LL_PHY_REQ. 

    Can you share the rest of the sniffer trace? 

Related