the speed can not reach 2Mbit/s

[Carey]

I want use two 52DK for BLE transfer demo, one 52DK download nRF5_SDK_15.0.0_a53641a\examples\ble_peripheral\ble_app_uart",  

other 52DK download "nRF5_SDK_15.0.0_a53641a\examples\ble_central\ble_app_uart_c",

and i changed the connection interval to 7.5ms, it seems the speed for two 52832 just can reach to (251B*1000/7.5)=33.5kbyte/s;  is it right?  is it possible to transfer more fast? i heard the speed of BLE5.0 can reach to 2Mbit/s, How to achieve it? 

[John]

You won't be able to do the 2Mbit on the nRF52832. It does not have the radio PHY that supports 2Mbit speeds. You will need to use the nRF52840 that supports the BLE 5 2M PHY. Nordic provides a throughput tester as one of their examples. It will allow you to configure the the nRF52840 PHY for 2M operation and larger MTU sizes needed to achieve the best throughput. Note that I doubt you will ever get to 2Mbit/s transfer rates because the protocol is not 100% efficient. I've gotten up to about 1.3Mbit/s, but not much better. Some of that may be because we have a very busy 2.4 radio spectrum in our office.

[Daniel Wang]

John said:

You won't be able to do the 2Mbit on the nRF52832

All nRF52 series devices support 2Mbit PHY, including nRF52832. It is CODED PHY that is only support on the nRF52840.

[John]

D'oh. Thanks!

[Carey]

ok, understand, but if i use two 52832 for test, could i transfer more fast?  now the speed just can reach to (251B*1000/7.5)=33.5kbyte/s.

[Ulrich Myhre]

2Mbit is the symbol rate, and includes non-payload data like the preamble, access address, CRC and various protocol-level headers. The theoretical maximum is a bit tricky to calculate, since it depends on a lot of factors. For instance, if you can live with a slower connection (higher connection interval), you gain some speed for huge transfers. With a slightly longer connection interval, longer event length, higher DLE and ATT MTU size, you avoid much of the overhead, since you spend more time sending data in each event.

Your brief calculation also doesn't take into account that you are able to send multiple packets in each connection event. The number of packets depends on the peer, as some will have a low buffer size and start to NACK packets after a few have gotten through. If the peer is sending you data too, instead of just sending empty ACKs, this will "steal" from the event time, leading to less packets sent.

I ran a quick example locally now with PHY=2Mbit, ATT_MTU=247, DLE Size=251, connection interval = event length* = 0x140 (401.25ms) and got about 1.4Mbit/s of user-controlled (ATT) data. That is excluding the L2CAP and ATT header. This was by sending write commands in one direction, with a peer that absorbs all the data without waiting. A connection interval that long sounds like it should be quite slow, but for long transfers it will actually be beneficial, given that the other parameters allow you to spend the entire event sending data. The result is that the event ends just as the new event is starting, reaching close to 100% utilization of the radio.

* Instead of setting the event length this high, you can enable event extension instead with the `BLE_COMMON_OPT_CONN_EVT_EXT`