Max. throughput on BLE UART using coded phy

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Wed, 15 May 2019 09:35:44 GMT

Hi!

Does anybody know if the sniffer will support coded PHY in future? And maybe when?

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Wed, 15 May 2019 09:32:25 GMT

That is interesting. I also would like to know if data length extension is not working with coded phy. As far as I can see it sdk does not return with an error if set. I have no sniffer so I cannot tell if it is used.

RE: Max. throughput on BLE UART using coded phy

4xM — Thu, 09 May 2019 07:13:12 GMT

https://devzone.nordicsemi.com/f/nordic-q-a/47010/support-for-coded-phy-and-data-length-extension-together

HI i found this which is telling Data length Extension is not working which explains why the data throughput is so low. I can not manage to geht the 32Kbs which should be possible too so this are my calc perhaps there is something wrong:

1sec/connection interval*packnumber per interval/(6)phycodedslow down factor*20bytes of data use*8bit

1000ms/7.5ms*6/4*20*8=32000bit

with mtu i would expect a little bit more but i can not reach 20Kbs perhaps the max number off pack per interval is wrong. i m using on both sides the NRF52840 but on the one side with Zephyre which should can handle that too.

Can you please provide the setting you are using to get a rate over 24Kbs?

Interval 7,5ms

Data Length extension Yes but not working?

extended MTU 247

connection event Length extension 7.5ms?

latency 5

supervision timeout 4sec

Edit

I found that if i start a scanner for BLE to get the advertisement while i m connected the connection is dropped

so what is there the relation ship? i guess it is sharing the time so that's why it is disconnected

If i plan to connect to devices i guess my max data throughput is just the half of the total?

RE: Max. throughput on BLE UART using coded phy

haakonsh — Thu, 02 May 2019 08:21:56 GMT

The differences are the connection settings that you use in the throughput example.

There are four BLE connection settings that you want to tweak:

1. Connection interval

I belive the minimum connection interval for BLE is 7.5ms at the moment. For standard packet sizes of 23 byte payload the Connection Interval is the determining factor for throughput, other than your Link Budget that is (who's determined by the physical RF link quality).
This is because you will only send one packet per Connection Interval.
You can request to update the Connection Interval by calling sd_ble_gap_conn_param_update with the wanted settings.

When using the lowest possible connection interval it might be difficult for your devices to maintain multiple connections (larger networks). If you want the device to be able to connect to multiple devices I suggest you choose a longer Connection Interval of approx 20-30ms and use Extended MTU.

2. Extended MTU

The MTU is the payload that is sendt between the application layers and the BLE Host layers (L2CAP) in each peer. By increasing the MTU from the standard 23bytes to 247bytes you can send longer packets and this reduces the overall overhead.
There's a caveat thought, a 247byte MTU packet will be split into 23 byte packets in the BLE Controllers unless your Link Layers have enabled Data Length Extension.

This can be set by first calling sd_ble_cfg_set with a cfg_id of BLE_CONN_CFGS, a p_cfg pointer that points to a ble_conn_cfg_t that contains a ble_gatt_conn_cfg_t with a att_mtu of 23-247 bytes. This configuration must be set prior to calling sd_ble_enable.

Then you can start negotiating for new MTU sizes with a call to sd_ble_gattc_exchange_mtu_request. This is done upon connection establishment by our GATT library in our SDK by a call to sd_ble_gattc_exchange_mtu_request.

3. Data Length Extension

In order for the two Link Layers to use larger packet sizes they have to request the use of DLE.

This can be enabled by calling sd_ble_opt_set with a ble_opt_t of common_opt where conn_evt_ext is set to 1/true.

After this is done the SoftDevice will negotiate the use of DLE automatically.

4. Connection Event Length Extension

At this point you're still limited to one packet per Connection Event. Connection Event Length Extensions enables the Link Layers to continuously transmit packets throughout each Connection Interval, limited by the time set aside with a call to sd_ble_cfg_set with a cfg_id of BLE_CONN_CFGS, a p_cfg pointer that points to a ble_conn_cfg_t that contains a ble_gap_conn_cfg_t with an event_length of x multiple of 1.25ms units.

If you have a 20ms Connection Interval you'll want to set an event_length of 20ms / 1.25ms = 16.

Summary
There's a trade-off between low Connection Intervals and BLE coexistence, shorter intervals will make it more difficult for the BLE Controller to establish connections to other devices.

There's also a trade-off between packet sizes and packet loss, because lost packets are re-transmitted, longer packets are more susceptible to noise, and longer packets takes more time to transmit, you might not want to use the maximum packet size available in noisy environments as you will spend more time re-transmitting lost packets.

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Tue, 30 Apr 2019 10:35:05 GMT

If I set the slave latency to 2 (if higher app crashes?) than throughput decreases from about 57 kbps to 17 kbps?

another question: What is the difference between the ATT MTU Throughput Example and UART Example? I can't get the same througput from the UART as from the ATT MTU?

Sorry for all that questions, but I am fairly new to BLE...

RE: Max. throughput on BLE UART using coded phy

haakonsh — Tue, 30 Apr 2019 08:21:24 GMT

You really should increase the slave latency to at least 5. If you miss a connection event with a slave latency of zero then your link is dead and you'll spend time re-initiating the link. This is true for all BLE links.

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Tue, 30 Apr 2019 08:12:35 GMT

Supervisor timeout is 4 seconds an slave latency is 0.

I really would appreciate if you could try this tommorow. Thanks.

RE: Max. throughput on BLE UART using coded phy

haakonsh — Tue, 30 Apr 2019 07:55:57 GMT

You can use a PCA10040 or a PCA10056 as the sniffer, and two PCA10059 as the BLE peers. Do note that the sniffer does not support Coded PHY yet, but we're interrested in finding the true Connection interval so it does not really matter in this case.

I just estimated 80-90kbps as being 1/8th of a decent 1mbps link. There is one factor that might reduce the throughput and that is packet loss. Coded PHY is more susceptible to interference because of its packets being 8 times as long, this in turn means that you will have to re-transmit packets that are themselves more susceptible to noise.
I suggest lowering the MTU and DLE to 1/8 of maximum as well as decreasing the Connection Interval to 400/8 = 50ms, and event length of 50ms. This way you'll reduce both the chance of packet loss and the time it takes to re-transmit a lost packet.

I can get 57 kbps. Is this the practical limit?
It might be, I've not checked myself, I'll do that tomorrow.

What's your Supervisor Timeout and Slave Latency settings?

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Tue, 30 Apr 2019 06:48:59 GMT

Hi!

I have two PCA10056 and two PCA10059. As far as I see it, I would need a third PCA10056 to run the sniffer on?

Did you or someone else have some real results with this setup (example and PCA10056)? I think your mentioned 80-90 kbps is just an estimation, right? I read another post and tried connection intervall 400 and data length 247. I can get 57 kbps. Is this the practical limit?

RE: Max. throughput on BLE UART using coded phy

haakonsh — Mon, 29 Apr 2019 14:34:32 GMT

It looks like you're getting the correct options, but I can't see the actual connection interval.

I suggest you set up as sniffer as described here: nRF Sniffer User Guide v2.1.

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Mon, 29 Apr 2019 12:45:30 GMT

Well, UART log is simple, but how to make a sniffer trace?

throughput example:~$ config print
==== Current test configuration ====
Board role: tester
ATT MTU size: 247
Data length: 27
Connection interval: 6 units
Connection length ext: on
Preferred PHY: Coded
GAP event length: 400
throughput example:~$ config data_length 244
Data length set to 244.
throughput example:~$ run
[00:00:00.083,435] <info> app: Preparing the test.
[00:00:00.083,465] <info> app: Starting advertising.
[00:00:00.083,587] <info> app: Starting scanning.
[00:00:00.087,707] <info> app: Connected as a peripheral.
[00:00:00.087,738] <info> app: Discovering GATT database...
[00:00:00.087,768] <info> app: Sending PHY Update, Coded.
[00:00:00.003,692] <info> app: Data length updated to 244 bytes.
[00:00:00.010,894] <info> app: ATT MTU exchange completed. MTU set to 247 bytes.
[00:00:00.084,075] <info> app: PHY update accepted. PHY set to Coded.
[00:00:00.009,002] <info> app: AMT service discovered at peer.
[00:00:00.016,540] <info> app: Notifications enabled.
[00:00:00.022,216] <info> app: Test started
[00:00:00.005,401] <info> app: Sent 1 KBytes
[00:00:00.018,737] <info> app: Sent 2 KBytes
[00:00:00.031,951] <info> app: Sent 3 KBytes
[00:00:00.060,302] <info> app: Sent 4 KBytes
[00:00:00.018,066] <info> app: Sent 5 KBytes
[00:00:00.005,706] <info> app: Sent 6 KBytes
[00:00:00.034,027] <info> app: Sent 7 KBytes
[00:00:00.006,774] <info> app: Sent 8 KBytes
[00:00:00.027,526] <info> app: Sent 9 KBytes
[00:00:00.048,339] <info> app: Sent 10 KBytes
[00:00:00.028,564] <info> app: Sent 11 KBytes
...
[00:00:00.030,822] <info> app: Sent 1020 KBytes
[00:00:00.074,157] <info> app: Sent 1021 KBytes
[00:00:00.091,918] <info> app: Sent 1022 KBytes
[00:00:00.041,992] <info> app: Sent 1023 KBytes
[00:00:00.029,724] <info> app: Sent 1024 KBytes
[00:00:00.004,119] <info> app: Done.
[00:00:00.004,119] <info> app: =============================
[00:00:00.004,119] <info> app: Time: 378.844 seconds elapsed.
[00:00:00.004,150] <info> app: Throughput: 22.14 Kbps.
[00:00:00.004,150] <info> app: =============================
[00:00:00.004,150] <info> app: Sent 1048712 bytes of ATT payload.
[00:00:00.004,150] <info> app: Retrieving amount of bytes received from peer...
[00:00:00.010,498] <info> app: Peer received 1048712 bytes of ATT payload.
[00:00:00.010,498] <info> app: Disconnecting...

I did a test with 1M. There i get Throughput of around 260 kbps. So 1/8 would be around 32.5 kbps on coded PHY which I can see under good conditions. It seems that regardless of actual PHY my set-up is to "slow"...

RE: Max. throughput on BLE UART using coded phy

haakonsh — Mon, 29 Apr 2019 12:32:15 GMT

Can you share the UART log, I'd like to see if the negotiated parameters are what you think they are. A sniffer trace would also be very helpful.

RE: Max. throughput on BLE UART using coded phy

Andreas48752 — Mon, 29 Apr 2019 11:43:09 GMT

Thank you for your reply.

I am already playing around with this example but I cannot get more than 32 kbps even if the boards are close together. I am using coded phy, connection interval 7.5 ms, GAP event length 400, data length 244, ATT MTU size 247.

Changing connection interval or other parameters does not increase throughput...

RE: Max. throughput on BLE UART using coded phy

haakonsh — Mon, 29 Apr 2019 11:37:26 GMT

You should try the Experimental: ATT_MTU Throughput Example.

You should be able to get almost 1/8th the throughput of 1mbps who's about 700kbps practical limit. I'm guessing that you should be able to get 80-90kbps with Coded PHY on a decent link.