Sporadic Bluetooth Connection That Won't Stay Connected on nRF52840dk boards

[robbsadler]

I attempted to create bluetooth central and peripheral apps using two nRF52840 boards that connect to each other and no one else using the device name. I had limited success, but often the firmware would not connect and I would have to restart it. So I added logic to retry the connection when it dropped, and now it connects an even smaller percentage of the time, and when it does, it ends up dropping the connection as soon as it gets it. I believe that it is due to not stopping the scan once I have a connection, but even though I have logic in the central code to stop scanning, it seems to still restart the scan. But that's an added problem. I've put many days into trying to sort this out, and am hoping someone may be able to set me and the code straight.

The code is zipped in the attached file, with the central in one folder and the peripheral in another. 3252.Firmware.zip

[Hung Bui]

Hi Robb, 
Have you gone through our BLE fundamental academy course : https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/

Even though it doesn't touch the central part but at least at lesson 6 you will learn how to use the sniffer and can use it to help debuging your application. 

In your central application why do you continue scanning after getting connected ? I see you configured CONFIG_BT_MAX_CONN=1 

We need to see why it disconnect. which side of the connection causing the termination. Did you test on a Dev kit? 

[robbsadler]

Hi Hung Bui,

Yes, I went through the course. Was disappointed that there was no coverage of two units communicating via peripheral and central logic.

I'm testing on two nRF52840dk boards. I started with one of the samples that spins up a central. I'll do some more digging and I'll bring up the sniffer. I actually have two pre-production boards I'm also testing with, but limiting this bug to the dk boards. And of course, I'm in a time crunch.

I have the max connection count set to one so that I can ensure that I'm not creating multiple connections to the same device with dangling connections until I have a single, good, clean, connection that behaves properly. Then that count will be increased to allow multiple connections which will be an added challenge. Trying to keep scope limited to as few simultaneous bugs as possible.

I had hoped to have someone look at the code, and see something obvious I'm missing, but the sniffer is a good idea.

Our project is bootstrapping funding as we go, so there's not a huge amount of cash to pour into this, but if you all have a recommendation for someone who could assist on an ad hoc basis, I'd be interested in chatting with them. I need to get this Bluetooth to robust code that is ready for production.

Thanks!

[Hung Bui]

Hi Robb, 
I would suggest to try testing with our samples for example the pair: peripheral_uart and central_uart. 
Let us know if you don't see a stable connection between the these two. 

[robbsadler]

Hi Hung Bui,

I have ordered a third DK board for usage as a sniffer. In the meantime, I will open these back up. I used the central_uart sample as my starting point. If I remember right I had to pull out a bunch of terminal code and replace it with some simple 2-way messaging, which is all I need.