How to calculate effective throughput in nRF52

RE: How to calculate effective throughput in nRF52

UBAN — Mon, 23 Jan 2017 06:32:22 GMT

Thank you for your detailed explanation. I understand.

RE: How to calculate effective throughput in nRF52

Ole Bauck — Thu, 19 Jan 2017 13:11:10 GMT

Since you have turned off DLE, the PDU (packet size) will be 27 bytes, of which 23 bytes will be ATT data.

With 247 bytes ATT MTU you will have to send 247/23 ~= 11 packets per ATT MTU.

The ATT MTU has 3 byte header (1 byte OPCODE_LENGTH and 2 byte HANDLE_LENGTH), so the effective data payload is 244 bytes per ATT MTU. So effective data per packet will be 244/11 ~= 22 bytes per packet.

How many packets you get per connection event is a bit tricky to figure out. With 2Mbps PHY, a 27 byte packet (PDU) takes about 160us to send, an empty packet takes about 40us. Between each RX or TX packet there is a 150us interframing space. One RX/TX pair where you send 27 bytes and receives an empty packet will take about 160us + 150us + 40us + 150us = 500us. You would then guess that you could send 15 packets per connection event when the connection interval is 7.5ms, but there have to be a little bit of space between the last packet sent on one connection event, and the first packet sent the next connection event. I did a quick check and you will get 13 packets sent every connection event with your configuration.

Adding all these pieces together the total throughput will be:

22 bytes pr packet * 8 bits pr byte * 13 packets pr conn event / 7.5ms conn int = 305kbps

RE: How to calculate effective throughput in nRF52

UBAN — Thu, 19 Jan 2017 08:22:07 GMT

Thanks for the reply and the explanation about Connection event extension. Yes, connection event length extension is set to enable. Of course, both ends are nRF 52 DK.

RE: How to calculate effective throughput in nRF52

Ole Bauck — Wed, 11 Jan 2017 16:14:15 GMT

It depends on how many packets you can send on each connection event. Do you intend to enable connection event length extension? Connection event extension will enable the SoftDevice to keep sending packets until the next connection event if there is data ready and no other roles are requestion radio time, See here. If not, the number of packets will be limited by the buffer size allocated by the SoftDevice, which again is dependent on the bandwidth (BW) configuration.

Is there an nRF in both ends? If there is not an nRF in the other end, the number of packets sent each connection event may be less.