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]

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

[Lars M]

Now I have tested to connect via another phone, a Samsung Galaxy A13 5G. Everything seems to work fine: connection, reading button status, button notifications, controlling the LED and disconnecting. I have attached the Wireshark file where all these features are tested. Obviously, something differs from my first phone (Samsung Galaxy S21 5G). There is an opcode, LL_CONNECTION_UPDATE_IND, that is present in the communication where things don’t work. That is where the 7.5 ms connection interval is set. Can that be the problem?

After CONNECT_IND is sent from a phone, the next few opcodes differ in order between the two phones. Why is that? Does It matter?

I also notice that the RGB_LED is lit red on my nRF52840 dongle (with the sniffer firmware) as long as the connection is established. Is that correct?

/Lars

Capture dk and second phone.pcapng

[Einarh]

Lars M said:

There is an opcode, LL_CONNECTION_UPDATE_IND, that is present in the communication where things don’t work. That is where the 7.5 ms connection interval is set. Can that be the problem?

Yes this seems to be the main difference I can see. You could try to set a minimum preferred connection interval in your peripheral's prj.conf file:

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=[number]

You could for instance set it to 39, which seems to be the connection interval with the other phone.

Lars M said:

After CONNECT_IND is sent from a phone, the next few opcodes differ in order between the two phones. Why is that? Does It matter?

It looks like the phones are doing the same things just in a slightly different order, I don't think it should matter.

Lars M said:

I also notice that the RGB_LED is lit red on my nRF52840 dongle (with the sniffer firmware) as long as the connection is established. Is that correct?

I'm not sure what the led is supposed to indicate and I'm not sure where it's documented, but indicating an established connection would make sense yes.

-Einar

[Lars M]

Interesting suggestion. Now I have tested to set CONFIG_BT_PERIPHERAL_PREF_MIN_INT=39 in prj.conf, but it is the same behaviour. I see in autoconf.h that the setting has taken effect. Without this config in prj.conf, it is CONFIG_BT_PERIPHERAL_PREF_MIN_INT=24 in autoconf.h (should be 30 ms, not 7.5 ms). So even with the default 24 it should be much bigger than 7.5 ms. Is it my phone that doesn't care about it, or is there something wrong with the config?

Seems strange to use a red colour when something is correct. But maybe the LED is used that way.

/Lars

Capture dk and first phone, CONFIG_BT_PERIPHERAL_PREF_MIN_INT 39.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