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

[ankurt]

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

[haakonsh]

Do you run the MTU exchange after you changed the PHY?

I'm wondering if the connection event length is too short for a re-transmit + regular packet in one connection event on Coded PHY. 

[ankurt]

Didn't do MTU exchange after updating PHY, can try that now.

I was also thinking that connection interval might be too small for code PHY (8x slower) to re-transmit + send regular packet but after looking on the oscilloscope, it doesn't seem so. My regular packet size is 3 bytes and connection interval is 12.5 ms which is enough, in theory, to send regular packet & re-transmit

[haakonsh]

Yes, but the connection event length is usually much shorter than the connection interval. In a rough estimate, you'll need 3-6ms connection event length for 3-byte payload on Coded PHY.

Call sd_ble_gap_data_length_update to update the Connection Event Length as well as the number of bytes in each packet. 

[ankurt]

Let me explain the full use case so that you can help me better :)

I have three devices D1, D2, D3. Following are the roles of the devices:

D1 - central (for D2)

D2 - peripheral (for D1) and central (for D3)

D3 - peripheral (for D2)

D1 and D2 communicate using 1Mbps PHY with characteristic size of 20 bytes.

D2 and D3 communicate using coded PHY with characteristic size of 9 bytes.

Based upon my understanding of specification about connection intervals and connection event lengths, this is how configured the devices:

D1 & D2:

connection interval - 75 ms

connection event length(NRF_SDH_BLE_GAP_EVENT_LENGTH) - 10 ms

D2 & D3:

connection interval - 25 ms

connection event length(NRF_SDH_BLE_GAP_EVENT_LENGTH) - 10 ms

So now when the devices start to communicate, everything goes well but once in a while data loss happens between D2 & D3.

Flow of software connection is like this:

• D1 scanning using 1Mpbs PHY, with 75 ms as min & max connection interval 
• D2 scanning & advertising using 1Mpbs PHY, with 25 ms as min & 75 ms as max connection interval 
• D3 advertising using 1Mpbs PHY, with 25 ms as min & max connection interval
• D1 connects with D2
• D2 connects with D3 and send coded PHY update request

Any suggestions or improvement on how I am configuring the system to avoid data loss?

[haakonsh]

I think you need to increase the event length for the Coded PHY link. Try increasing the max value and see if it helps.

Also, we need logs and sniffer traces. 

I'm going on vacation for a week, but I'll assign your case to another Tech Supporter.

BR,

Håkon HoldhusI

[ankurt]

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

[haakonsh]

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?