Connection issue with Samsung Galaxy A5 (2017)

RE: Connection issue with Samsung Galaxy A5 (2017)

Dmitry — Tue, 29 Aug 2017 05:06:11 GMT

Hi,

I've created new question since comment doesn't allow to write full message: devzone.nordicsemi.com/.../

RE: Connection issue with Samsung Galaxy A5 (2017)

Sigurd — Mon, 28 Aug 2017 14:52:42 GMT

Is the any special steps we should take in order to enable concurrent scanner/peripheral modes using SDK 14 and softdevice 5.0.0?

Have you tried debugging? Do you get any error-code when you try to do this? You could also try to increase NRF_SDH_BLE_PERIPHERAL_LINK_COUNT and NRF_SDH_BLE_TOTAL_LINK_COUNT in sdk_config.h

RE: Connection issue with Samsung Galaxy A5 (2017)

Dmitry — Mon, 28 Aug 2017 13:50:20 GMT

Hi,

We tried softdevice 4.0.4 and it were able to establish connection from Samsung Galaxy A5. Also we've completed migration to SDK 14/softdevice 5.0.0 and were able to connect to the device from smartphone as well but we faced new serious problem: the connectivity chip doesn't work until we disable scanner mode. As a side note, when we worked on SDK 13 and softdevice 4.0.2 or 4.0.4 we didn't have any problems with concurrent scanner/peripheral modes operation. Is the any special steps we should take in order to enable concurrent scanner/peripheral modes using SDK 14 and softdevice 5.0.0?

RE: Connection issue with Samsung Galaxy A5 (2017)

JustinLee — Tue, 22 Aug 2017 23:50:38 GMT

With a Samsung Galaxy A7 and A6, those phones send a new LLCP packet before completing previous connection procedure especially while exchanging Data Length Extension packets. This is a misbehavior from a phone side. This situation has been reported to Samsung. Just for information, Samsung will release the new S/W for a Galaxy A7 for that.

RE: Connection issue with Samsung Galaxy A5 (2017)

Sigurd — Tue, 22 Aug 2017 10:30:24 GMT

Hi,

There have been some reports that some Samsung phones and tablets are sending version exchange and length request in parallel (i.e., does not wait for the peripheral to respond before sending the next control packet). From the sniffer-trace you uploaded, I only see one connection request, and a LL_FEATURE_RSP packet, and then there is nothing for the next 20 seconds, before the peripheral starts to advertising again. So it's hard to say something conclusive based only on that, and a nrf_log with debug information could maybe have revealed something more about the issue.

We have released a version 4.0.4 of the S132 SoftDevice where we are allowing overlapping peer-initiated Link Layer control procedures. You can download this S132 version 4.0.4 from here. So I suggest that you try that SoftDevice version, and see if that solves the issue.

From s132 v.4.0.4 release notes:

"The SoftDevice slave role now accepts overlapping peer-initiated Link Layer control procedures (DRGN-8623,DRGN-8975). The following LL control procedures can be executed in parallel with any other control procedure, except forthemselves: LE Ping, Feature Exchange, Data Length Update, and Version Exchange. This is done for compatibility reasons. As a result of this, BLE_GAP_OPT_COMPAT_MODE_2 has no effect"

Note that migrating from S132 v4.0.2, to S132 v4.0.4 should be fairly simple. Replace the header files in the SDK(located in the folder SDK_folder\components\softdevice\s132\headers) with the ones you download(located in folder s132_nrf52_4.0.4\s132_nrf52_4.0.4_API\include), and remember to flash the new softdevice hex(s132_nrf52_4.0.4_softdevice.hex) to your device.