Unusual behaviour with specific model host (SM-T580) with nRF52

RE: Unusual behaviour with specific model host (SM-T580) with nRF52

Sigurd — Mon, 21 Aug 2017 20:10:13 GMT

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.

RE: Unusual behaviour with specific model host (SM-T580) with nRF52

Sigurd — Mon, 21 Aug 2017 19:54:43 GMT

I have seen some report about the SM-T580 sending version exchange and length request in parallel (i.e., does not wait for the peripheral to respond before sending the next control packet). I looked some more into the problem, and it might be solved without any code changes on your part.

We have released a version 4.0.4 of the S132 SoftDevice, where we have relaxed the spec abit by allowing overlapping peer-initiated Link Layer control procedures. You can download this S132 version 4.0.4 from here.

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"

This approach could be tested before doing any code changes. Even if the tablet is not following the BLE spec perfectly and have some bugs, it might be worth the trouble to solve this issue if your end-customers also are using these tablets to connect to your product. If v.4.0.4 does not work "out-of-the-box", try the code changes proposed in the answer above.

RE: Unusual behaviour with specific model host (SM-T580) with nRF52

Musa — Mon, 21 Aug 2017 17:40:49 GMT

I appreciate the detailed answer. "Galaxy TAB A tablets have been reported ... of breaking/not following the Bluetooth specification". That would explain it. It would have been nice of Samsung to mention that somewhere so I knew before I bought it. I feel obliged to at least attempt your suggested solutions, but I think I will return the tablet on principle because listing it as "Bluetooth 4.2 compatible" is false advertising.

Thanks for the help!

RE: Unusual behaviour with specific model host (SM-T580) with nRF52

Sigurd — Mon, 21 Aug 2017 12:22:29 GMT

Hi,

These Galaxy TAB A tablets have been reported several times of breaking/not following the Bluetooth specification.

With S132 v.3.1.0 (for nRF52) we added something called compatibility mode(compatibility mode 2) that can be enabled to still be able to connect to some of these devices that are not following the Bluetooth Specification. Since this tablet is working with S130, enabling this compatibility mode might not solve this specific issue, but it’s worth a try. You can enable it like this(You need to call the option-set function after you have enabled the SoftDevice, i.e after softdevice_enable(&ram_start);):

ble_opt_t ble_opt;
memset(&ble_opt, 0, sizeof(ble_opt));

ble_opt.gap_opt.compat_mode_2.enable = 1;

err_code = sd_ble_opt_set(BLE_GAP_OPT_COMPAT_MODE_2,&ble_opt); 
APP_ERROR_CHECK(err_code);

If this does not help, the problem is most likely that the tablet is not able to handle the DLE procedure (longer on-air data packets). In SDK 13 we have a GATT module that handles this. I suggest to use the default payload size (27), so that the DLE procedure is not initiated. By default, we set the DLE size to be equal the size of the ATT_MTU in the gatt module, so if we want to have a longer ATT_MTU but at the same time keep the default DLE size, we have to change this in the gatt module(nrf_ble_gatt.c).

In the function link_init(..) change the line

p_link->data_length_desired        = NRF_BLE_GATT_MAX_MTU_SIZE + LL_HEADER_LEN;

p_link->data_length_desired        = BLE_GATT_ATT_MTU_DEFAULT + LL_HEADER_LEN;

and in the function nrf_ble_gatt_init(…) change the line

p_gatt->data_length             = NRF_BLE_GATT_MAX_MTU_SIZE + LL_HEADER_LEN;

p_gatt->data_length             = BLE_GATT_ATT_MTU_DEFAULT + LL_HEADER_LEN;

If the issue is still there after this, try to set NRF_BLE_GATT_MAX_MTU_SIZE to 100.