when the SoftDevice Event rise SD_EVT_IRQ in Central Role? What's connect timing mode for multi-link in Central Role?

[wen jin zhang]

Hi:

    We are develop an Central Device can Connect 8 BLE Device in same time. and want max throughout. it use queue and freeRTOS.  the Central TX is simple.

    use  sd_ble_gattc_write() with BLE_GATT_OP_WRITE_CMD to write.  wait semaphore event rise by BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event. 

   but between the SD_EVT_IRQ interrupt rise(BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE ) and sd_ble_gattc_write, it  take about 7.5ms. not our expect 2.5ms(1Mbps) or 1.4ms(2Mbps).  When SD_EVT_IRQ interrupt rise by SoftDevice?  why it same value as NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL ? 

Is NRF_SDH_BLE_GAP_EVENT_LENGTH  use to reduce SD_EVT_IRQ  frequency?  Do the Nordic Semiconductor have guidebook for these config parameters? or have excel document can calculate these parameters?

   how the SoftDevice handle Multi-linked peripheral connect timing? 

   from "Connection timing as a Central" charter of S140_SDS_v2.1,  Do SoftDevice use one Big time Slot to scan each connected peripheral? each peripheral get equalization chance?

|  peripheral 1 connect timing(7.5ms) | peripheral 2 connect timing(7.5ms)  | .... | peripheral 8connect timing(7.5ms)|   --> Next loop

|_____________________________|_____________________________|_______________________________|

   or just each peripheral has random shift start connect timing? 

           |  peripheral 1 connect timing(7.5ms) |

                |  peripheral 2 connect timing(7.5ms) |

                 .....

                     | peripheral 8connect timing(7.5ms)| 

 

Here the Central Config:

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251

#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0

#define NRF_SDH_BLE_CENTRAL_LINK_COUNT  8

#define NRF_SDH_BLE_TOTAL_LINK_COUNT    8

#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6

#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 7.5

the "Connection Event Length Extension" is enabled.  and connect peripheral use min_conn_interval=max_conn_interval=7.5ms.  peripheral use  BLE_GATT_CHAR_PROPERTIES_WRITE_WITHOUT_RESPONSE/BLE_GATT_CHAR_PROPERTIES_NOTIFY.

[wen jin zhang]

Sorry for confuse. new attach files is really for BLE speed test.

the Connect interval is 7.5ms. the hvn queue size is 2 and 3. No big difference for throughout.   see attach trace files

double connection interval and connection event length

this will effect Other BLE devices.  The experimental\ble_app_att_mtu_throughput  use same 7.5ms. 

how much data you are trying to send each connection event?

we try use BLE as UART.  as much as possible.

 nrf52832 hx 3 with Connect.pcapng

the nrf52832 hx 3 with connect.pcapng  trace capture.  gateway is the NRF52840 dongle hardware with nRF Connect tools.

other two is our Gateway code on NRF52840  DK board.  

 nRF52832 hx queue 2.pcapngnRF52832 hx queue 3.pcapng

[Karl Ylvisaker]

wen jin zhang said:

we try use BLE as UART.  as much as possible.

If you are trying to achieve the highest possible throughput I recommend taking a look at the parameters described in the Throughput section of the SoftDevice documentation.

wen jin zhang said:

the nrf52832 hx 3 with connect.pcapng  trace capture.

In this trace you are still only sending a single notification per connection event.
There is plenty more time in the connection interval, and the peripheral reports that it has more data to transfer, and yet the central does not prompt it to send more data.
This leads me to believe that the connection event length is set too short. Could you try to set this to an arbitrary high number (like 500) to see if this changes the number of notifications per connection event? The event length can never be longer than the connection interval, so by setting an arbitrary high number the SoftDevice will cap it to be exactly the same as the connection interval.

In the nRF52832 hx queue 2 trace the peripheral does not report that it has more data to send each connection event. It seems to me that it only has a single notification ready each connection event. This is also true for the nRF52832 hx queue 3 trace.
Are you now only queuing notifications when you receive the HVN_COMPLETE event?
If so, that might be why the devices does not have more notifications ready each connection event.
Perhaps you could instead have a queue of say 5, and keep track of how many you have queued, and how many that are sent each connection event (if you look at the data in the HVN_COMPLETE event). This way, you can queue more than just the 1 notification for every connection event.

Best regards,
Karl