Using pc-ble-driver in a C# app with large number of notifications from the peripheral is slower

Hi all, 

I am currently using Raytac dongle https://www.raytac.com/product/ins.php?index_id=89 with connectivity FW on the dongle and pc-ble-driver version 4.1.4 and sd_api=v6 and S140 from https://github.com/NordicSemiconductor/pc-ble-driver on the host side windows 10.

Using a baud rate of 1M, based on the examples in \pc-ble-driver-master\examples\heart_rate_monitor\ 

static adapter_t * adapter_init(char * serial_port, uint32_t baud_rate)
{
physical_layer_t * phy;
data_link_layer_t * data_link_layer;
transport_layer_t * transport_layer;

phy = sd_rpc_physical_layer_create_uart(serial_port,
baud_rate,
SD_RPC_FLOW_CONTROL_NONE,
SD_RPC_PARITY_NONE);
data_link_layer = sd_rpc_data_link_layer_create_bt_three_wire(phy, 250);
transport_layer = sd_rpc_transport_layer_create(data_link_layer, 1500);
return sd_rpc_adapter_create(transport_layer);
}

Currently the dongle is used to communicate with a single peripheral at a time with ATT MTU size set to default 23 and a connection interval of 7.5 ms. The issue we are facing is when the peripheral is sending large number of notification packets (usually 1000's of packets) the dongle and the peripheral seems to exchange only 3 packets per every connection interval (7.5 ms). The rest of the connection interval the dongle seems to be inactive and is not making a request to the peripheral to send more packets even though the peripheral indicates that there is more data to be sent through the MD bit in the link layer packet.

The peripheral is known to be sending up to 9 packets per connection event, if the master (central ) continues to make such requests. So we know the peripheral is probably ok. One other observation is, even if we increase the connection interval to say 50 ms, still only 3 packets are exchanged , bulk of the connection event is wasted.

Current architecture is whenever the pc-ble-driver publishes the event, the event handler on the C# side only copies the data in-memory and exits.

static void ble_evt_dispatch(adapter_t* adapter, ble_evt_t* p_ble_evt)

{

case BLE_GATTC_EVT_HVX:
managedSoftDeviceWrapper->onHandleValueResponse(adapter, &(p_ble_evt->evt.gattc_evt));
break;

}

I would like to get some info / guidance on:

  1. Are there any known limitations of using nrf52840 with large number of notifications?
  2. Are there any configuration in pc-ble-driver or the connectivity FW in the dongle that is limiting the number packets?
  3. Are there any known windows issue that slows it down?
  4. Any other ideas?

Let me know if I need to provide more information on any aspect. Any inputs / feedback are welcome.

Thank you very much in advance.

  • Hi,

    Are there any known limitations of using nrf52840 with large number of notifications?

    Not per se. But incoming data must be buffered and processed fat enough.

    Are there any configuration in pc-ble-driver or the connectivity FW in the dongle that is limiting the number packets?

    There is significant delay and overhead in the serialization, which probably explains this. I doubt you will be able to increase the number of notifications per connection event further.

    Update: double check that the event length is as long as you want it to be (essentially the same as the connection interval for maximum throughput). See for instance how NRF_SDH_BLE_GAP_EVENT_LENGTH used in the NUS client example.

    Are there any known windows issue that slows it down?

    Not that I am aware of.

    Any other ideas?

    Is it possible to change the conditions so that you send fewer notifications with more data instead?

Related