Max packet number per CI for nRF5340

[PengLiu]

Hi, Experts,

We are evaluating BLE throughput (sdk-nrf-2.7.0 throughput sample) using nRF5340DKs. The CI is set to 6 i.e. 7.5ms. The PDU size is set to 251, PHY is 2Mbps.

The measured throughput is around 1040kbps, far less than the theoretical value 1300kbps.

The times include transmitting + IFS + receiving + IFS is 1400us, so the theoretical packet number within 7.5ms is calculated as 7500/1400=5. We suspects packet number of 4 is used instead of 5, thus the actual rate is 80% of theoretical value. Can anyone help confirm whether packet number of 4 is used for this case and for what reason the number is reduced by 1.

Thanks,

Peng,

[Hung Bui]

Hi Peng, 
It would be easier to investigate if you can capture a sniffer trace. 

Could you try to increase the connection interval to 18.75ms ? 
I made a blog post earlier here that actually compare the throughput between 7.5ms CI and 18.75ms CI.
Building a Bluetooth application on nRF Connect SDK - Part 3 Optimizing the connection

Please look for the test near the end of the blog. What you suspect maybe correct. Only 4 notification per connection event are sent. In your calculation of the transmission time, have you calculated the overhead when sending a packet ? This would include the crystal ramp up time, the stand by time. 
If you want to measure the transmission time, you can try using either the online power profiler or the actual power profiler. 
Online Power Profiler for Bluetooth LE

I did a quick check here and the calculation on the online power profiler show that there should be only 4 packets fit into a 7.5ms CI: 

[PengLiu]

Hi, Hung,

Thanks for the detail information. We don't have a sniffer so can't trace BLE communication. When using Online power profile, I noticed overhead including RF ramp-up, post-processing and standby. Is there any specification about what is the maximum time of RF ramp-up(start radio) and post-processing time?

Another question is that three is a pretty long standby time. I thought this standby time could be reduced if I set more than 1004 byte TX payload per event, but couldn't succeed. (e.g. I set 1100 byte TX payload, the online power profile changed it back to 1004). Is there some criterial to set this payload per event? 

Peng,

  

[Hung Bui]

Hi Peng, 

You can just use any nRF52 DK as the sniffer. You can take a look here: https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-6-bluetooth-le-sniffer/

The reason for a large Standby period is that the scheduler need to be able to fit the maximum payload possible of a pair of TX&RX in to the slot (worst case scenario). Meaning max size TX and max size RX need to fit there otherwise the scheduler will skip them and wait for the next connection event. 

[PengLiu]

Hi, Hung,

Can you elaborate a little about "the scheduler need to be able to fit the maximum payload possible of a pair of TX&RX in to the slot (worst case scenario). "

Does this mean in the standby period of one CI, the scheduler fills in the data package in TX FIFO for the first transmission in next CI? if this is not done, in the beginning of next CI, TX FIFO has to be filled first for the first package data, thus adding waiting time(standby time)?

Thanks,

Peng,

[Hung Bui]

Hi Peng, 

No what I mean is that to be able to fit 5 packets in stead of 4 the scheduler need to be sure the 5th slot has to be big enough to receive max size RX packet. Usually it's an empty packet (the RX) but it can't be guarantee that it's always an empty packet, the peripheral can send a packet with max size. So that's why it can only fit 4 packets. The solution is to increase the CI so that the 5th packet can fit.