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

[Einarh]

Hello

What phone and OS are you using when the connection doesn't work? It could be the case that the connection parameters aren't compatible with your phone OS or something similar.

If you could set up a BLE sniffer and share logs of the communication between your devices as the disconnection happens, that would be very helpful.

Best regards,

Einar

[Lars M]

Hi,

I have a Samsung S21 5G with Android version 13. My computer runs Windows 10.

Now I have installed the BLE Sniffer and captured some communication. In this file I should have recorded two attempts to connect.

Best regards,
Lars

4214.Capture.pcapng

[Einarh]

It's probably your phone that ignores it yes. The peripheral can state its preferences but in the end it's up to the central unit to set the connection parameters. You could play around with other parameters and see if they make a difference, maybe you're able to communicate with your phone if you request to use PHY 1M for example.

[Lars M]

I have made my own BLE-program (called MMS), which is a light version of NUS. Here the connection works fine. It is also possible to send characters to and receive notifications from my dk, and also disconnect. The only difference in the connection process seems to be the lack of LL_CONNECTION_UPDATE_IND in my project. Instead there is an empty PDU (packet 116 compared to 213). Maybe there is some info from the device that makes the phone want to use 7.5 ms in the first case, but not in my project. I have tried to compare the autoconf.h-files, but haven’t yet found something that could be interesting to adjust. Do you see something in the connection process that may cause different behaviours of the phone?

PHY 2M seems to work, and there is 50 ms connection interval.

/Lars

Capture MMS first phone, connect UART disconnect.pcapng

[Einarh]

Hi

I stumbled over this case very similar to yours:

 Disconnect after connect parameters update 

It seems to indicate that in a noisy radio environments, as your office might be judging by your first capture logs, you might have more luck using a smaller connection interval. So maybe it could be a good idea to request 7.5ms from the peripheral right away.

This one is similar too, but I'm not sure there is anything directly applicable to your problem there:

 LL_CONNECTION_UPDATE_IND before response to Connection Parameters Update Request causes disconnect 

[Lars M]

Hi,

Now I have tested to set 7.5 ms, but with exactly the same behaviour.

I have tested the project both at my office and at home (the original version, not 7.5 ms). At home there should be much less devices communicating. Now I also have tested lesson 2 exercise 3, lesson 3 exercise 1, and lesson 4 exercise 1, and the same connection problem happens there. The different behaviours between the my project and those I have tested from DevAcademy can be repeated, it doesn't seem to be depending on the environment.

The differences I see in Wireshark begins with packets 213/116 during the connection process. Then some more differeces can be seen before only the master sends from packet 219 (where things go wrong), while the master and slave both send when connection works fine. So it seems that something makes my phone behave differently between the projects. Though, I haven't been able to figure out where the difference is.

/Lars

[Lars M]

Hi,

Now I have completed the three first lessons with all exercises. Suddenly on the last part in lesson 3 exercise 2, the connection started to work. After a while when I had palyed around a bit with the configs in prj.conf, I went back to earlier exercises. And now they also work without any updates. So strange! I have captured several wiresharkfiles for lesson 1 exercise 1. They differ a bit, but every time the connection process works. There are some things that differ between these files and "Capture dk and phone, 3 tries.pcapng" that I attached earlier. On packet no 214 (LL_PHY_REQ) in "Capture dk and phone, 3 tries.pcapng", there is a red mark telling something is wrong. Corresponding packet in a new file where connection works, doesn't show an error (I attach two files for lesson 1 exercise 1). But I can't see what causes the red mark in the old file. Is it wrong expected answer on LL_CONNECTION_UPDATE_IND sent just before?

Another difference is that LL_CONNECTION_UPDATE_IND is not present when connection works. In the exercise where connection suddenly started to work, connection parameters are adjusted. Can something in this process have affected my phone to behave differently in coming connections? Feels a bit strange, but maybe?

/Lars

Capture dk first phone less1 exer1 working.pcapng

Capture dk first phone less1 exer1 working 2.pcapng

[Einarh]

Hm interesting, yes it seems to be the LL_CONNECTION_UPDATE_IND packet that causes this, but I'm not sure what causes it to appear.

It would be interesting to see the difference in your configuration for exercise 1 when it works and doesn't.

-Einar

[Lars M]

That's the problem, I can't make it not work anymore. After the last part of lesson 3 exercise 2, connection always works. And that part has to do with some connection parameters (data length and time). Can something in this process have affected my phone to behave differently in coming connections?

It's a little while ago so I don't really remember, but most likely the file "Capture dk and phone, 3 tries.pcapng" is capture from lesson 1. As the two files I attached in previous post.

Can you say something about the red mark in packet 214? Why is it red when corresponding packet in another capture is not red? They look pretty much the same, apart from the red-marked comes after LL_CONNECTION_UPDATE_IND.

Another thing that I have encountered is that during these connection problems I have run the desktop program. Every time that I power on the dk that I used with the desktop program (I am playing with two dk:s) the PC automatically connects to it. I go into Windows settings and tell the computer to forget the device. Everything seems to work (the device disappears from the device list), but nonetheless the computer connects to it when it is turned on. I have manually added the dk, and then removed it, but it doesn't help. The computer connects to the dk no matter if it is in the list or not. The only way that I have found out to prevent my computer to connect to it is to turn off Bluetooth in the computer. Is there anything I can do to make the computer to really forget my dk?

/Lars

[Lars M]

Hi again,

The last part in previous post is solved. I had to restart my computer, and after that there is no automatic connection.

/Lars

[Einarh]

Lars M said:

After the last part of lesson 3 exercise 2, connection always works. And that part has to do with some connection parameters (data length and time).

Then it seems like this was the tweaking of parameters needed to make it work, and it also seems like your phone remembers these parameters. Hard to say exactly what made the difference without being able to reproduce the error though.

Lars M said:

Can you say something about the red mark in packet 214? Why is it red when corresponding packet in another capture is not red? They look pretty much the same, apart from the red-marked comes after LL_CONNECTION_UPDATE_IND.

The red mark seems to indicate an unexpected sequencing of packets yes, the peripheral sending a PHY_REQ when the central expects a reply to its CONNECTION_UPDATE_IND.

[Lars M]

Einarh said:

Then it seems like this was the tweaking of parameters needed to make it work, and it also seems like your phone remembers these parameters.

Ok, it's maybe like that. Though, it would be nice to know it for sure. But maybe it's hard to get to know that.

But if it is like this, these update of parameters used in lesson 3 exercise 2 should be present in all BLE-programs to prevent a phone to behave like mine.

/Lars