• State Not Answered
  • Replies 29 replies
  • Subscribers 68 subscribers
  • Views 6601 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 245334
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

jpo38

I am using a nRF52840-PCA10059 dongle to acquire data at a high rate (between 50Hz and 400Hz).

The connection is very unstable, after some seconds of acquisition, it sort of freezes: looks like the softdevice crashs as we stop receiving notifications and it won't respond to read/write requests (however we do not receive any information regarding a connection being lost).

I already reported a case here and it has never been fixed:

https://devzone.nordicsemi.com/f/nordic-q-a/44922/s140-pc-ble-driver-4-0-0-freezes-when-receiving-too-many-data

Surprisingly, we just noticed that having "nRF Connect - Bluetooth Low Energy" app opened (even if not connected to the dongle, just opened in Windows) makes everything work better:

- The services dicovery is much faster

- The connection is prefectly stable. I can receive notifications for hours

As soon as I close "nRF Connect - Bluetooth Low Energy", my other application stops receiving norifications an I observe the freeze.

Apparently, "nRF Connect - Bluetooth Low Energy" does something in the background that makes the dongle and/or the soft device be more stable. What could it be?

Parents
  • 0

    Hi,

    This sounds very strange. I now have a PC with an OS that has not been used for Bluetooth before. I will try to reproduce the behavior you describe on this one this week. Unfortunately, I have not received any feedback from our developers if they have managed to reproduce this yet.

    Best regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    Hi,

    I did, in fact, manage to reproduce it. I tested both on the nRF52840 Dongle and the nRF52840 DK using the nRF_USB connector (both running the USB connectivity firmware), and they both stop after 15-20 notifications. In order to get more logs, I built the connectivity FW with RTT logging enabled. When I retried the test with the J-Link RTT Viewer open, I was no longer able to reproduce the issue.

    I will try to do some more debugging, and also check with the developers again if they have had time to look into this.

    Best regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    Hello Jorgen,

    Thank you again for following this issue.

    We are still experiencing the same here and there's been no progress:

    - Reboot the PC
    - Start our software using NRF's pc-ble-driver, connect a APIv6 dongle, connect a device
    - Service discovery is slow (up to 4s)
    - Start notifications for data being sent by the device at high rate (100Hz)
    - After less than a 5s, driver reports "serial port read on port COM5 aborted." and I don't get any more notifications (I see the dongle LED blink once)
    - Kill our software, unplug/replug the dongle
    - Now start NRF connect, "Bluetooth Low Energy" app (I just open the app, do nothing more)
    - Start our software using NRF's pc-ble-driver, connect a APIv6 dongle, connect a device
    - Service discovery is at least twice faster (~2s)
    - Start notifications for data being sent by the device at high rate (100Hz)
    - After more than a minute, no error is reported
    - I close NRF connect, "Bluetooth Low Energy" app
    - Instantly, I get the "serial port read on port COM5 aborted." and I don't get any more notifications (I see the dongle LED blink once)

    I agree "Bluetooth Low Energy" can't open the port while my app uses it, however, it can change some Windows priority or anything else.

    I can do a video if you don't believe me, this is 100% reproductible.

    I tried bot hthe original hex file packaged with the NRF's pc-ble-driver and connectivity_4.1.1_usb_with_s140_6.1.1_critical_region_fix_increased_sched_queue_size.hex. With both I can reproduce the problem.

    Jean

  • 0 in reply to jpo38

    I will test out your instructions next week. Did you try the hex-file with scheduler queue size set to 64, which I posted in the linked thread (200505_ble_connectivity_s140_usb_hci_pca10056_lfxo_mergedsoftdevice.hex)?

  • 0 in reply to Jørgen Holmefjord

    Hi Jorgen,

    I originally only tested connectivity_4.1.1_usb_with_s140_6.1.1_critical_region_fix_increased_sched_queue_size.hex, this did not fix the issue.

    I just tested 200505_ble_connectivity_s140_usb_hci_pca10056_lfxo_mergedsoftdevice.hex, and this apparently fixes the issue!

    I'll ask other developers from my team to test this last hex file and confirm next week if this solves the problem for good or if I was just lucky when I tested it today.

    What's the difference between those tow files? Are they related to different issues?

    Please do not loose time trying to investigate this on Monday untill I come back to you.

    Kind regards,

    Jean

  • 0 in reply to jpo38
    jpo38 said:
    I just tested 200505_ble_connectivity_s140_usb_hci_pca10056_lfxo_mergedsoftdevice.hex, and this apparently fixes the issue!

    That is great, let me know how it goes! Are you also not seeing any timing-difference on BLE operations with and without nRF Connect open for this firmware?

    jpo38 said:
    What's the difference between those tow files? Are they related to different issues?

    They fix the same two issues (missing critical regions and increase scheduler queue size), but the first one had the queue size set to 32, while the latter has it set to 64.

    Best Regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    For the stability, we are doing more testing today, I'll let you know.

    For the speed, services discovery remains two times faster when nRF Connect/Blueotooth Low Energy app is opened...

Reply Children
Related