DevAcademy Bluetooth LE connection problems

[Lars M]

Hi,

I am going through the DevAcademy Bluetooth LE lessons, using nRF5 DK. But I run into problems directly in the exercise of the first lesson. Everything goes fine to step 4.2, but connecting doesn’t work. Connection is established, but almost immediately disconnection happens. LED2 is lit for a short moment. The print outs are like this:

No matter how many times I try, disconnection always happens this way. I have also tested to connect via the Bluetooth low energy desktop app using the Nordic BLE dongle. Then the connection works fine. I have tested with both nRF Connect SDK 2.3.0 and 2.0.0, and the scenario is the same for both versions.

In the desktop app it is possible to read the button state and activate notifications (and receive updates when the button is pressed). But I am not able to control LED3. I have put a breakpoint in write_led() in lbs.c (C:\...\v2.3.0\nrf\subsys\bluetooth\services\lbs.c), but the breakpoint isn't hit when I write to the LED characteristic. Though, a breakpoint in read_button() will be hit when I click "Nordic LED and Button Service", so I should be in the correct file.

 

Best regards,

Lars

[Lars M]

Now I have captured another bunch of data. It seems that I have succeeded in filtering my DK-data.

I have only this selected:

I guess this selects LE LL, correct?

I have also made this selection:

I’m not sure what selection I had when I captured previous files, but now I get more info about the communication. Does this tell you something more interesting?

I have not yet tested with another phone, but will hopefully have the possibility pretty soon.

In the files from my previous post there were only my DK, phone and computer. But quite a lot of addresses were present, of which may appear just a few times. What are these addresses?

Capture dk and phone, 3 tries.pcapng

[Einarh]

Hi

Lars M said:

now I get more info about the communication. Does this tell you something more interesting?

Yes this data is more interesting! You can see the devices set up a connection, negotiating connection parameters. Your DK requests to use 2M PHY, your phone acknowledges this and then starts sending read requests, but the strange part is that your DK never seems to answer any of these requests, so the phone repeats this request every 50ms for 5 seconds until it reaches a timeout. I'm not entirely sure why this happens, but it looks like the DK never receives these requests, maybe something goes wrong when the connection is supposed to swap to 2M PHY..

Lars M said:

In the files from my previous post there were only my DK, phone and computer. But quite a lot of addresses were present, of which may appear just a few times. What are these addresses?

The random addresses that seem to just appear once I believe are from corrupted BLE packets. Not sure if this happens when the packet is sent or when it is sniffed, but I don't think those are real addresses, just corrupted data.

I have put a breakpoint in write_led() in lbs.c

Also, don't think this is the current issue, but you should avoid breakpoints when doing BLE, breakpoints in BLE functions can break BLE entirely.

-Einar

[Lars M]

Hi,

Packet number 214 is LL_PHY_REQ seems to contain some error. Can that give a clue to why there is problem with the communication?

It seems that the time between the requests is 50 ms in the beginning, packet number 219 – 223. But then the read requests come much more frequent, about 7 – 8 ms (maybe 7.5 ms?).

There is a gap in communication (of about 5 sec) after the last read request. Why is that?

When the phone sends read requests, the red LED on my nRF52840 dongle is lit. Maybe it is turned on when packet number 214 arrives to the dongle? The LED is turned off after the 5 sec communication gap.

Einarh said:

Also, don't think this is the current issue, but you should avoid breakpoints when doing BLE, breakpoints in BLE functions can break BLE entirely.

Yes, I know that breakpoints in BLE-applications probably will cause the application to crash. But setting a breakpoint and coming there will give a proof that the program comes to a certain row. And since I didn’t see expected behaviour of LED3, I put a breakpoint there to see if the code was executed. Which it wasn’t.

Best regards,

Lars

[Einarh]

Lars M said:

Packet number 214 is LL_PHY_REQ seems to contain some error.

Yes, I was looking at that one, if you look at its contents it's saying that the DK prefers 2M PHY. In packet 217 the phone responds "2M PHY shall be used".

Lars M said:

But then the read requests come much more frequent, about 7 – 8 ms (maybe 7.5 ms?)

Hm, it looks like you're right, and it looks like in packet 213 the phone sets the connection interval to 7,5ms so I guess that makes sense. I can't see the DK acknowledging that though, maybe that transaction is interrupted by packet 214.

Lars M said:

There is a gap in communication (of about 5 sec) after the last read request. Why is that?

Hm, maybe the DK doesn't start timing out until the phone stops sending requests.

It would be very interesting to see a capture with another phone that is able to communicate successfully to have something to compare this with, I might try later today if I have time.

-EInar

[Lars M]

Hi Einar,

Now I have tested nRF Connect for Desktop, and captured a sequence. Everything seems to work fine. I have connected, clicked in nRF Connect for Desktop to update button status, I have activated notifications and pressed the button, I have turned on and off the LED, and I have disconnected. I guess it would look something like this when using the phone?

/Lars

Capture nRF Connect for Desktop.pcapng