Multi peripheral with windows device API (BluetoothLEDevice/C#

RE: Multi peripheral with windows device API (BluetoothLEDevice/C#

mhassan@thoughttechnology.com — Sat, 09 Apr 2022 21:18:35 GMT

I could find the reason of problem 1, The problem was my BT dongle adapter which is "Laird BT820-2" it seems the dongle does not support 2M PHY also the connection event always get one packet each 7.5ms., now I'm using laptop dongle which is

LMP 10

Bluetooth Core Specification 5.1

I could achieve 800K throughput , and the optimized connection interval in my case is 30ms, maybe windows only accept (specific number of packet each interval because in theory longer interval should result less overhead of interval event itself).

ATT MTU size: 247
hvn_tx_queue_size = 32
#define NRF_SDH_BLE_GAP_EVENT_LENGTH MSEC_TO_UNITS(30, UNIT_1_25_MS) 
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(30, UNIT_1_25_MS) 
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(30, UNIT_1_25_MS)		
.tx_phys = BLE_GAP_PHY_2MBPS,
.rx_phys = BLE_GAP_PHY_2MBPS
opt.common_opt.conn_evt_ext.enable = 1;

TX Buffer size increased to 32 has very high effect on speed(couldn't set more because of memory error but I believe we can fix this problem)

The problem 2 still remained, the simple definition is when we connect several devices only one of them connects with maximum speed an the others connect with lower speed for example in the last test, 4 devices connected as , A:550K , B:80K . C:80k , D:80k

RE: Multi peripheral with windows device API (BluetoothLEDevice/C#

mhassan@thoughttechnology.com — Fri, 08 Apr 2022 23:03:50 GMT

So, for the sending process, I have an application buffer which is 16K and each time I send part of this buffer (each tx packet 244 bytes), I've either tested :

1- pooling mode by checking sd_ble_gatts_hvx to push data and if it returns NRF_SUCCESS will prepare another 244 bytes to send. the pooling is very fast and most of time is less than 1ms.

2- Event mode by waiting for BLE_GATTS_EVT_HVN_TX_COMPLETE to send the next tx packet

for the measurement In the FW side I'm using UART to see successfully sd_ble_gatts_hvx buffering time also can see BLE_GATTS_EVT_HVN_TX_COMPLETE time and distance between 2 subsequent events , The log shows almost each 7.5ms one packet is accepted as we can see in the logs here.

In the application side I measure received RX bytes and it is 220 kb/s. It seems windows always receive packets each 7.5ms and it doesn't matter what is connection interval time!. is there any solution for that or is there anyone could achieve more than one packet each 7.5ms (more than 260kb) with windows?

and why even when i don't send data, connecting second device reduces first connected device speed!?

thanks!

Maximum rate is in the PHY RX rate field

this log above, is for 7.5ms connection interval with conn_evt_ext enabled

this log above, is for 23.75ms connection interval with conn_evt_ext enabled

this log above, is for 23.75ms connection interval with conn_evt_ext disabled, this one shows if we disable multipacket each interval only receives one packet and if it is enabled windows acts like 7.5ms connection interval.

RE: Multi peripheral with windows device API (BluetoothLEDevice/C#

Edvin — Fri, 08 Apr 2022 13:26:16 GMT

Hello,

How do you send your packets that you measure the throughput on? And what is your event length? I see that you have a definition NRF_SDH_BLE_GAP_EVENT_LENGTH, but where do you use that in your application? By default it is used in nrf_sdh_ble.c, so unless you have changed it, it should be used there.

Throughput on BLE with many connections is really quite complex. I suggest you test the example ble_app_att_mtu_throughput from SDK\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput

Regarding Issue 2: Does it consistently happen only when you use device A and B? And is A, B and C running the exact same application?

Best regards,

Edvin

RE: Multi peripheral with windows device API (BluetoothLEDevice/C#

mhassan@thoughttechnology.com — Fri, 08 Apr 2022 06:44:58 GMT

I tested more devices for the problem 2, so device #A and #B have this effect but (A# with #C ) or (B# with #C ) working fine, so is there any id or some identification number which causes conflict between 2 specific devices? or is there any RF Frequency conflict between this 2 devices?