pc-ble-driver-py throughput issues with write_req()

[grantrudd]

Hello,

I am currently working with pc-ble-driver-py and have observed write operations taking an exceedingly long time. Previous DevZone posts on this topic seem to be unresolved:

 pc-ble-driver-py - Maximum data rate 

 pc_ble_driver_py takes a lot of time to discover services, characteristics, and descriptors 

I am observing the write_req() function take upwards of 60ms to complete, most of which is waiting for the gattc_evt_write_rsp to come back from the _nrf_ble_driver_sd_api_v5 library. My connection interval is 15ms and the payload size is only 20 bytes. I would expect this function call to return within one connection interval.

The 60ms completion time of write_req() function does not seem to vary if I alter the connection interval (such that it is less than 60s) or payload size. Like others have noted, the latency seems to be within the shared library or interface between python and the shared library.

Have there been any updates or resolutions on this matter? 

Thanks!

[grantrudd]

Hi Sigurd,

I am still seeing this issue on v0.17.0, with Python 3.8 running an a machine with Ubuntu 22.04. I installed a fresh copy of pc-ble-driver-py from pip this morning and am still seeing slow performance with write_req().

This is what I'm seeing for timing with the connection parameters mentioned above:

write_req() time 0.05992388725280762
write_req() time 0.05992531776428223
write_req() time 0.059960365295410156
write_req() time 0.05984926223754883
write_req() time 0.05991005897521973
write_req() time 0.05988287925720215
write_req() time 0.059864044189453125

Is there a way to check the version of _nrf_ble_driver_sd_api.so (which I assume is the shared library created from pc-ble-driver-py)? The documentation at the top of the associated python file still says 4.0.1.

# This file was automatically generated by SWIG (http://www.swig.org).

# Version 4.0.1

#

# Do not make changes to this file unless you know what you are doing--modify

# the SWIG interface file instead.

[Sigurd]

Hi,

1) Could you check what get_connectivity_hex_version() returns?

2) If you have a spare DK or dongle, could you capture a sniffer trace? https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

[grantrudd]

Hi Sigurd,

Here is the return from get_connectivity_hex_version():

>>> config.get_connectivity_hex_version()
'4.1.4'

And here is the sniffer trace from when the devices connect and part of the DFU.

4505.trace.pcapng

Thanks,

Grant

[Sigurd]

Hi,

grantrudd said:

And here is the sniffer trace from when the devices connect and part of the DFU.

Not sure how you are measuring this, but what's happening on-air is as expected though, 

the write response is received in the next connection event. And a new write request is sent.

[grantrudd]

Hi SIgurd,

Thanks for confirming that the pc-ble-driver-py library is behaving properly. I was able to figure out the issue with my application and now am seeing the expected results.

Thanks,

Grant