This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Hi everyone.

I'm using pc_ble_driver_py with nRF52840 USB dongle with burned connectivity_4.1.1_usb_with_s140_6.1.1.hex.

pc_ble_driver_py is modified by me to support BLE5.0 features.

It looks like everything works well, but timings spent on the discovering services, characteristics, and descriptors are too long (up to 25-30 seconds) and depend on PC used.

I have localized the place where most of the time spent, it is between sending the command via UART (ASIO library) to BLE dongle and waiting for the response.

I was trying to decrease connection interval, but discovery timings stay the same.

Also, I have tried to use pc_ble_driver DLL in bare C, but here timings are well.

Does this issue is known? Or do you have any suggestions on how to decrease discovery timings?

Thanks.

Top Replies

Ingfu over 5 years ago in reply to Roman H +1 verified

Hi Roman, did you make any progress on this issue? I am still struggling with the pc-ble-driver-py performance myself.

Parents

0 Einar Thorsrud over 5 years ago

Hi,

It is difficult to say what could cause the delay(s) without knowing more. Do you have a log or similar showing the flow that you can upload here together with your code? A sniffer trace could also be useful so that we can see what happens on air.
0 Roman H over 5 years ago in reply to Einar Thorsrud

Unfortunately, I can't share the code. But I'm using the Python library provided by Nordic with some changes to support BLE 5.0. I haven't changed the procedures of the services, characteristics and descriptors discovery.
0 Einar Thorsrud over 5 years ago in reply to Roman H

Hi,

I see. The log shows that it takes a long time, but there is no hint as to why. Can you check with a sniffer what is actually happening on air? Particularly which connection interval is used, but it might give some other insight as well.

Reply

0 Einar Thorsrud over 5 years ago in reply to Roman H

Hi,

I see. The log shows that it takes a long time, but there is no hint as to why. Can you check with a sniffer what is actually happening on air? Particularly which connection interval is used, but it might give some other insight as well.

Children

0 Roman H over 5 years ago in reply to Einar Thorsrud

Hi, I'll try to get a sniffer log as soon as possible.

Also, I was playing with the connection interval, but the timing was almost the same as for 100 ms and as for 10 ms.
0 Roman H over 5 years ago in reply to Einar Thorsrud

ATT(py).csv

Hi. Log from sniffer attached.
0 Einar Thorsrud over 5 years ago in reply to Roman H

Hi,

This is just ATT traffic. Can you upload a full sniffer trace (with all layers)? Prefrably in the sniffers native format.
0 Roman H over 5 years ago in reply to Einar Thorsrud

Yes of course.

Here is also RAW sniffer log files.

We are using Frontline BPA low energy Bluetooth protocol analyzer.

SnifferLog.zip
0 Einar Thorsrud over 5 years ago in reply to Roman H

Hi,

Looking at the sniffer trace I see that the connection interval is 80 ms, but you are probably right that it doe snot have a large effect. There is a significant overhead using serialization. Also, I see a there is a lot of Find Information Requests and responses back and forth, so you are trying to discover all services. That takes a long time. You could speed it ut by looking for specific services, as suggested here.