Why having "nRF Connect - Bluetooth Low Energy" open makes my connection faster

[jpo38]

This topic follows devzone.nordicsemi.com/.../why-having-nrf-connect---bluetooth-low-energy-open-makes-my-connection-faster-and-more-stable which was partially fixed (with fix in SoftDevice, connection is more stable and does not freeze anymore, however, it remains slow).

I could reproduce the issue only with code delivered by Nordic:

* Board PCA10028 programmed with "Nordic_HRM" sample program

* pc-ble-driver's heart_rate_collector sample program with very few changes:

• Added "#include <time.h>" and "clock_t start;" on top of the file
• Added "start = clock();" after "printf("Discovering primary services\n");fflush(stdout);" in service_discovery_start()
• Added "clock_t stop = clock();double diffticks=stop-start;double diffms=(diffticks)/(CLOCKS_PER_SEC/1000);printf("time taken %fms\n",diffms);" before "m_hrm_cccd_handle = p_ble_gattc_evt->params.desc_disc_rsp.descs[i].handle;" in on_descriptor_discovery_response

So now the program reports how long service discovery took

Now I ran the sample program:

• Twice in a raw, without "nRF Connect - Bluetooth Low Energy" being opened, service discovery took around 200ms
• Then, I open "nRF Connect - Bluetooth Low Energy"
• Twice in a raw, service discovery took less than 50ms
• Then, I close "nRF Connect - Bluetooth Low Energy"
• Once again, service discovery took around 200ms
• Then, I reopen "nRF Connect - Bluetooth Low Energy"
• Once again, service discovery took less than 50ms

See the video:

So the fact that "nRF Connect - Bluetooth Low Energy" is opened apparently really makes device discovery faster. Later, for our devices, it also makes data acquisition faster, meaning that witout "nRF Connect - Bluetooth Low Energy" being installed and running on the computer, we cannot reach the throughpout we need for our applications.

Could you please help us understanding what is "nRF Connect - Bluetooth Low Energy" doing at Windows level (or elsewhere) that make the device communication be faster?

[Amanda Hsieh]

Hi Jean, 

Could you kindly provide the sniffer log to help check the issue? Thanks. 

-Amanda H.

[jpo38]

Hi again,

I must admit the documentation is now better than it used to be for the sniffer. I could install it and make it work easilly. Here are the logs, one with a slow service discovery (~200ms) (when "nRF Connect - Bluetooth Low Energy" was closed), one with a fast service discovery (~50ms) (when "nRF Connect - Bluetooth Low Energy" was opened).

Hope this can help,

kind regards,

Jean

sniffer_discovery_with_without_nrf_connect.zip

[jpo38]

OK. Enjoy the holidays and we'll see this in January!

Merry XMas and Happy New Year to you too.

Kind regards,

Jean

[jpo38]

Hello Amanda,

Did the team get a chance to look at this problem?

Kind regards,

Jean

[Amanda Hsieh]

Hi Jean, 

Unfortunately, the problem has not been uncovered due to the limited resource of the team. Is it a pressing matter would you say? May I know more about your concern? Please be free to let me know any thoughts. 

-Amanda H.

[jpo38]

Yes, this is definitely critical for us, as we are using BLE5 to transmit lots of data (notifications of 200 bytes data frames at 1kHz). This works fine when "nRF Connect" is opened on the machine, but has tones of data being lost when it's closed. So it makes it impossible for us to deploy the application to final users. 

[Amanda Hsieh]

Hi Jean, 

I think we should look into this, but can't promise how soon. have a bit resourcing issue at the moment which we need to resolve.

-Amanda H.

[jpo38]

If needed, I believe we could even consider hosting a Nordic engineer at our place (Grenoble/France) for some days to work together on the problem.

Jean

[jpo38]

If that could help, it looks like having JLInk.exe running also makes softdevice run in a faster way. Could there by any link between JLink and "USB CDC ACM" that could explain that?

[jpo38]

Did some more investigations.

If I rename "C:\Program Files (x86)\SEGGER\JLink" (as "Jlink_").

When I run "heart_rate_collector" sample program or my programs using pc-ble-driver 4.1.2, they still work the same.

But when I run "nRF Connect"/"Bluetooth Low Energy" app, it reports:

2021-02-05T15:37:00.123Z ERROR Error while probing devices: Error occured when get serial numbers. Errorcode: CouldNotCallFunction (0x9)
Lowlevel error: INVALID_OPERATION (fffffffe)

So there is dfinitely something done in the background by "nRF Connect"/"Bluetooth Low Energy" through JLink. And I bet that's what makes the dongle behave right (high speed) when "nRF Connect"/"Bluetooth Low Energy" is opened on the machine.

Any idea what this could be?

Kind regards,

Jean

[Amanda Hsieh]

Hi Jean, 

If you rename the path of the Jlink driver, the error might be expected because of the setting. Do you mean that the service discovery will not run faster in that case?

Could you also help to test if you open J-Link Commander? Does it also affect the time?

-Amanda H. 

[jpo38]

Hello,

I could do some more testing, here is what we observe here:

- When nor JLink, nor nRF Connect are opened, service discovery and data transmission is slow

- When JLink.exe is opened, service discovery and data transmission is faster

- When "nRF Connect - Bleototh Low Energy" is opened, service discovery and data transmission is faster

So we could conclude that "nRF Connect - Bleototh Low Energy" may start JLink in the background making everything work fine. But:

- If I rename "C:\Program Files (x86)\SEGGER", and open "nRF Connect - Bleototh Low Energy", I get an error and, surprisingly, service discovery and data transmission remain faster....while I would expect it to be slow again as "nRF Connect - Bleototh Low Energy" could not run JLink....

Jean