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

[Lars M]

Hi again,

Another thing that makes this not really satisfactory is that I had my phone working with my own-made BLE-project at the same time as the phone didn't work with the DevAcademy-projects. For my project, the phone didn't send LL_CONNECTION_UPDATE_IND as every other time when the connection works.

Lars M said:

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.

So maybe there is more to this than just the possibility that the parameter updates have made my phone behave in a new way. It obviously behaved differently depending on project before.

/Lars

[Lars M]

It feels this never comes to an end. Now I have run lesson 4 exercise 1, and now the connection problem is back. Lesson 3 exercise 2 works fine, and also MMS. But when I go back to lesson 4 exercise 1, the connection problem is still there, the phone hasn't changed behaviour (at least not to make this program work). I also tried lesson 1, and now that works.

I have captured a lot. I attach the files, numbered in the order they are logged. Though, actually there is nothing new. Every time conenction works, LL_CONNECTION_UPDATE_IND is missing. And every time connection doesn't work, LL_CONNECTION_UPDATE_IND is present.

/Lars

1 Capture dk first phone less4 exer1 not working, before less3 exer2.pcapng

2 Capture dk first phone MMS working, before less3 exer2.pcapng

3 Capture dk first phone less4 exer1 not working, before less3 exer2 after MMS.pcapng

4 Capture dk first phone less3 exer2 working.pcapng

5 Capture dk first phone less4 exer1 not working, after MMS after less3 exer2.pcapng

6 Capture dk first phone less1 exer1 working, after MMS after less3 exer2.pcapng

7 Capture dk first phone less4 exer1 not working, after MMS after less3 exer2 after less1.pcapng

[Einarh]

Hi, ignore the "suggested answer", I misclicked..

I've forwarded this internally at Nordic now, and someone is trying to reproduce this with a phone similar to yours.

I'll let you know if I get any updates.

-Einar

[Einarh]

Hello

I just received an update clarifying that this is a known issue with some Samsung phones related to the PHY update procedure.

It should work if you disable the PHY update from the peripheral side.

In order for this to work with the PHY update on your Samsung phone, this issue would have to be addressed by Samsung.

Best regards,

Einar

[Lars M]

By setting CONFIG_BT_PHY_UPDATE=n I get connection in the exercises working, great! At least those exercises in lesson 4. But now I can't use 2M, doesn't feel good.

After I set CONFIG_BT_PHY_UPDATE=n, I also tested to set back to CONFIG_BT_PHY_UPDATE=y. Then connection works. Strange. And 2M is used with 50 ms communication interval. The LL_CONNECTION_UPDATE_IND is missing this time.

Testing connection for another unaltered exercise from lesson 4 does not work, just as before. But setting CONFIG_BT_PHY_UPDATE=n makes it work. And connection works after setting it back to "y". Just as the scenario for previous exercise. This holds for all three exercises in lesson 4.

It feels like my phone recognizes the various projects. Can it be like that?

I have captured some logfiles, I attach four files from lesson 4 exercise 2. In the first file the exercise is unchanged, and connection doesn't work. The second file has CONFIG_BT_PHY_UPDATE=n. There is an LL_CONNECTION_UPDATE_IND with 7.5 ms as before, but then a lot of "new" communicaton goes on before the connection is established. Can you get some interesting information from this? Right before the connection is established there is a new LL_CONNECTION_UPDATE_IND with new parameters.

In the third file is CONFIG_BT_PHY_UPDATE set to "y" again. As mentioned above, now connection works. The fourth file has CONFIG_BT_PHY_UPDATE=n. Here all the "new" communication is missing.

Another thing that I don't understand is that CONFIG_BT_PERIPHERAL_PREF_MIN_INT says that the connection interval can be 7.5 ms, which my phone asks for when the connection doesn't work. Shouldn't LL_CONNECTION_UPDATE_IND with 7.5 ms work? Or is there something else that causes connection to not work?

Does any of Samsung or Nordic not follow the BLE standard?

Einarh said:

this is a known issue with some Samsung phones related to the PHY update procedure.

Do you know which/how many phones from Samsung that have this issue?

Is it only Samsung?

Best regards,
Lars

1 Capture Samsung S21 less4 exer2 CONFIG_BT_PHY_UPDATE=y.pcapng

2 Capture Samsung S21 less4 exer2 CONFIG_BT_PHY_UPDATE=n.pcapng

3 Capture Samsung S21 less4 exer2 CONFIG_BT_PHY_UPDATE=y.pcapng

4 Capture Samsung S21 less4 exer2 CONFIG_BT_PHY_UPDATE=n.pcapng

[Einarh]

Lars M said:

Does any of Samsung or Nordic not follow the BLE standard?

Yes exactly, the problem is that some Samsung phones don't follow the BLE standard.

So in your specific connection procedure, you end up in an undefined state and time out. Once you've established the first successful connection, your phone will remember the connection parameters, and the connection procedure will be different which means the error does not occur anymore.

I'm not sure exactly what phones are affected, only that it's a known issue with some Samsung phones right now. There have also been similar issues with iPhones previously. If it's important to you I could look into more specifically what phones are affected.

-Einar

[Lars M]

In what way does Samsung not follow the standard? It seems it is LL_CONNECTION_UPDATE_IND with 7.5 ms that is the problem. But the information about CONFIG_BT_PERIPHERAL_PREF_MIN_INT says that the connection interval can be 7.5 ms. So why does it not work?

I'm wondering what could be expected if I develop a device that will be used by a lot of customers. Then for sure some will get connection problem. It would not be pleasant if a customer buys a device and his/her phone can't connect. If this is a known issue for some phones this must have happened a lot of times before. Do you know how that is handled? It feels that the safest way to go is to set CONFIG_BT_PHY_UPDATE=n. But then 2M can't be used. Or are there other ways?

Will a problematic phone model always behave the same way? I mean, if I test another Samsung S21 with an unchanged exercise, will it also fail to connect?

It might be interesting to know what exact models that have problem. But it would be more interesting to know the proportion between problematic phones and those that work. I guess it's hard to say an exact ratio, but how many phones are known to have connection problems?

Are there any tablets that also show connection problems?

I haven't had any problems with with my phone and any Bluetooth devices before. Though, I'm not sure how many that are classic Bluetooth and how many that are BLE.

Best regards,
Lars

[Einarh]

The way it doesn't follow the standard has to do with the timing and sequencing of these update procedures.

In this specific case, LL_CONNECTION_UPDATE_IND is a procedure that takes several BLE events to complete, but when the phone receives the LL_PHY_REQ from the peripheral it responds to this immediately instead of waiting for LL_CONNECTION_UPDATE_IND to complete first. That's where it violates the specification.

The phones that are affected are the ones with the same Broadcom Bluetooth controller chipset as your Samsung phone. Possibly devices other than Samsung with the same chipset also.

This firmware bug has actually been fixed by Broadcom, but Samsung has yet to push this fix to their phones.

-Einar

[Lars M]

Thanks a lot Einar for your help! This makes sense.

I try to find the name of the chipset, but I'm not sure if I'm successful. Do you know if it is BCM4389? It seems to be for the Ultra-version of S21, but maybe it's also for the one just named S21 (SM-G991B/DS).

/Lars

[Jas39]

I have also stumbled into this issue with a Samsung 21. Works fine with a Sony Experia.

I have tried Lars approach of setting: 

CONFIG_BT_PHY_UPDATE=n

But to no avail. I got the same behaviour on the Samsung regardless.

But alas, removing the bond and restarting the phone makes it work!

Hopefully this can save someone else some time...