BLE send and receive speed, GATTS

RE: BLE send and receive speed, GATTS

Tim — Wed, 14 Dec 2016 13:25:11 GMT

Issue was that I was still searching for other devices, while sending. Same issue as here : devzone.nordicsemi.com/.../

RE: BLE send and receive speed, GATTS

Ole Bauck — Tue, 13 Dec 2016 16:01:14 GMT

127.8 kbps in each direction means that you can send and receive at 127.8 kbps. This number is basically just 6 TX/RX packets per connection event and a connection interval of 7.5ms:

6 packets per event * 8 bits per byte * 20 byte per packet / 7.5 ms = 128 kbps

Why you don't get that high throughput when sending and receiving, I don't know. It can be application processing or something else. As the SDS says:

Maximum throughput will only be possible when the application reads data packets as they are received, and
provides new data as packets are transmitted, without delay

You should take a look at the ATT MTU throughput example in SDK 12.2.0. This also shows how you can change the MTU or PDU (packet payload) size and connection event extension to get even higher speeds. Maximum speed with SoftDevice S132 v3 can be up to 765.8kbps, see here.

RE: BLE send and receive speed, GATTS

Tim — Mon, 12 Dec 2016 17:44:09 GMT

I found the issue, i was scanning while sending.... devzone.nordicsemi.com/.../, same issue as here.

another question: I am using the S132 V2, and i read this: 127.8 kbps (each direction) What does this mean , that i have 64kb/s send and receive?, since i reach 139kb/s to one deveice, but only 54kb/s whe the device is sending and receiving.

RE: BLE send and receive speed, GATTS

Ole Bauck — Fri, 09 Dec 2016 13:54:29 GMT

To update the connection parameters you will have to call sd_ble_gap_conn_param_update(..), with sd_ble_gap_ppcp_set(..) you are only setting the preferred connection parameters. Basically this is the way it goes:

The central will decide the initial connection parameters. If you are using an nRF device for the central, the desired connection parameters (the SoftDevice may choose higher values if it is not possible due to too many connections) are the last parameter in sd_ble_gap_connect(..).
The central or peripheral can later update or request to update the connection parameters by calling sd_ble_gap_conn_param_update(..)

Check what the connection parameters used by the central is. I also advise you to use the SDK connection parameters negotiation library which is used by most of our BLE examples.

RE: BLE send and receive speed, GATTS

Tim — Fri, 09 Dec 2016 13:16:28 GMT

I did the same test but now i send 100 packets with 20 bytes payload.

Average = 384,0847778 == 260 packet/s
Max = 537,5976563 == 186 packet/s
Min = 223,7243652 == 446 packet/s

I shouldn't be to reach 446 packets/s with 85 ms delay. With 446 packets/s = ~13,5 ms delay, 800 pakcets/s = 7.5 ms,

RE: BLE send and receive speed, GATTS

Tim — Fri, 09 Dec 2016 12:54:20 GMT

when i start sending i set a gpio pin high, this is measured on a other nrf52DK and i take a RTC timestamp wich is 30US per tick. When I receive the message on my other device, i am polling with:

sizeOfCurrentEvent = sizeOfEvent;
err = sd_ble_evt_get((u8*)currentEventBuffer, &sizeOfCurrentEvent);

if err == NRF_SUCCES then I check if it my messeage, if so I set another GPIO pin high. my 3rd NRF52Dk will take a second time stamp, timestamp2-timestamp1 = result/32768*1000 = result in ms

RE: BLE send and receive speed, GATTS

Tim — Fri, 09 Dec 2016 12:46:15 GMT

I am setting the interval here. with the setting above, also slavelatancy is 0.

ble_gap_conn_params_t gapConnectionParams;
	memset(&gapConnectionParams, 0, sizeof(gapConnectionParams));
	gapConnectionParams.min_conn_interval = Config->meshMinConnectionInterval;
	gapConnectionParams.max_conn_interval = Config->meshMaxConnectionInterval;
	gapConnectionParams.slave_latency = Config->meshPeripheralSlaveLatency;
	gapConnectionParams.conn_sup_timeout = Config->meshConnectionSupervisionTimeout;
	err = sd_ble_gap_ppcp_set(&gapConnectionParams);
	APP_ERROR_CHECK(err); //OK

RE: BLE send and receive speed, GATTS

Ole Bauck — Fri, 09 Dec 2016 12:28:56 GMT

How are you measuring? Do you measure from the sd_ble_gattc_write(..) command is sent to the TX complete event is received or to the packet is received on the other side?

You will naturally have variable latency in BLE because of the connection interval. If you manage to update the SoftDevice buffer right before the connection event, you will have the lowest latency, if you do it right after, you will have the highest latency (lowest + connection interval).

You should check that the connection interval is actually set to 7.5 ms, from your measurements it looks like it may be closer to 85 ms.

The application can also delay the measurements depending on interrupt levels and where you start/stop the measurements or where you call sd_ble_gattc_write(..).