Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Question

We have a discovery issue that seemingly only happens with the Samsung Galaxy S8. 
 We are using the nRF52832 with SoftDevice S132 v2.0.1, and do directed advertisements to the last connected peer when disconnecting. We do not use pairing or bonding. If we connect to a second device, such as an iPhone, and disconnect from the iPhone, the radio goes into fast directed advertising, and if it doesn't find the last connected peer, it goes to fast undirected advertising. 
 Our problem is that the Samsung Galaxy S8 does not discover the nRF52 after the fast directed advertising mode is over and undirected advertisements starts. We have tried having 4 different brand phones running in parallel with the nRF Go scanner app open, and only on the Galaxy S8 it cannot discover the nRF. If we restart the nRF and start immediately in fast undirected advertisement, the S8 finds the nRF instantly. Also disabling directed advertisements altogether seem to resolve the connectivity issues with the S8, but this seems like a non-solution to me as we are giving up the fast reconnect feature of having directed advertisements. 
 The problem appears not only with the scanner app, but also when using our own BLE Android application. 
 Below is the config we are currently passing to the advertising module (SDK 12.3) 
 #define APP_ADV_INTERVAL_FAST 20 // ms
#define APP_ADV_TIMEOUT_FAST_IN_SECONDS 30 // s

#define APP_ADV_INTERVAL_SLOW 1285 // ms
#define APP_ADV_TIMEOUT_SLOW_IN_SECONDS BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED

static const ble_adv_modes_config_t options = {
 .ble_adv_whitelist_enabled = false,
 .ble_adv_directed_enabled = true, // Disable this due to Samsung S8
 .ble_adv_directed_slow_enabled = false,
 .ble_adv_fast_enabled = true,
 .ble_adv_slow_enabled = true,
 .ble_adv_directed_slow_interval = 0,
 .ble_adv_directed_slow_timeout = 0,
 .ble_adv_fast_interval = (uint32_t) MSEC_TO_UNITS(APP_ADV_INTERVAL_FAST, UNIT_0_625_MS),
 .ble_adv_fast_timeout = APP_ADV_TIMEOUT_FAST_IN_SECONDS,
 .ble_adv_slow_interval = (uint32_t) MSEC_TO_UNITS(APP_ADV_INTERVAL_SLOW, UNIT_0_625_MS),
 .ble_adv_slow_timeout = APP_ADV_TIMEOUT_SLOW_IN_SECONDS
};
 
 Are we doing anything wrong from our side, or is this most likely an issue with the BLE stack on the Samsung S8? Regardless, any ideas for fixes or workarounds would be appreciated

MartinBL · Accepted Answer

Hi, 
 I have finally been able to reproduce the problem. For testing I used: 
 
 Samsung Galaxy S8 running Android 7.0 
 Nexus 7 Tablet running Android 6.0 
 Nexus 5X running Android 8.1 
 nRF Connect for Mobile 
 The ble_app_hids_mouse example: 
 nRF52, SDK 14.2, S132 v5.0.0 
 nRF52, SDK 12.3, S132 v3.0.0 
 User @Matej also sees the issue with nRF51, SDK 12.3, S130 v2.0.1 
 
 The steps to reproduce it are: 
 
 Start advertising with the ble_app_hids_mouse example. 
 All Android devices are now able to scan for, and see the hids_mouse peripheral. 
 Connect to the peripheral with the Nexus 7. 
 Bond the peripheral and the Nexus 7 
 Nexus 7 is added to the whitelist in the peripheral 
 Disconnect Nexus 7 and peripheral 
 Using the hids_mouse example, the peripheral will now start directed advertising 
 Shortly after, the peripheral will start normal undirected advertising again 
 Now the S8 is no longer able to see the peripheral, but the Nexus 7 and 5X still can. 
 A simple reset of the peripheral is all it takes to fix it. 
 
 
 Background 
 The problem seems to be caused by an obscure corner case triggered by a combination of two things: 
 
 A specification violation in the Softdevice 
 A specification violation in the Samsung Galaxy S7/S8 software, the chipset they use, or a combination of both. 
 
 The following arguments refer to the Bluetooth Core Specification Version 5.0, but also applies to Version 4.x (chapter numbers and phrasing might be different). 
 The core of the matter is the RxAdd bit field in the Advertising Channel PDU, and how it is being used in directed and undirected advertising. 
 Refer to Vol 6, Part B, Ch 2.3 ADVERTISING CHANNEL PDU: 
 
 The chapter states that: 
 
 The ChSel, TxAdd and RxAdd fields of
the advertising channel PDU that are
contained in the header contain
information specific to the PDU type
defined for each advertising channel
PDU separately. If the ChSel, TxAdd or
RxAdd fields are not defined as used
in a given PDU then they shall be
considered Reserved for Future Use. 
 
 Vol 6, Part B, Ch 2.3.1.1 ADV_IND (undirected advertising) writes nothing about the RxAdd field, implying that the bit is Reserved For Future Use (RFU). 
 Jumping back to the "General Interpretation Rules" in the Bluetooth specification, the chapter Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU) states that: 
 
 Where a field in a packet, PDU, or
other data structure is described as
"Reserved for future use"
(irrespective of whether in upper or
lower case), the device creating the
structure shall set it to zero unless
otherwise specified. Any device
receiving or interpreting the
structure shall ignore that field; in
particular, it shall not reject the
structure because of the value of the
field 
 
 Furthermore, Vol 6, Part B, Ch 2.3.1.2 ADV_DIRECT_IND (directed advertising) states that: 
 
 […] The PDU shall be used in
connectable directed advertising
events. The TxAdd in the advertising
channel PDU header indicates whether
the advertiser’s address in the AdvA
field is public (TxAdd = 0) or random
(TxAdd = 1). The RxAdd in the
advertising channel PDU header
indicates whether the target’s address
in the TargetA field is public (RxAdd
= 0) or random (RxAdd = 1). 
 
 The “target address” mentioned here is the address of the phone (peer device) that we successfully connected to our peripheral. In our case, the target address is of type ‘Random’ and hence, the RxAdd bit is set to 1. 
 So to summarize this: 
 
 In directed advertising, the RxAdd bit field is used to indicate whether the address of the peer device, which the advertising packet is intended for, is random or public. 
 In undirected advertising, the bit field is not used. It is actually completely irrelevant since no peer address is included in the advertising packet and hence, it is considered “Reserved for Future Use". 
 
 
 Cause 
 Since our phones are able to see the device in one instance, but not the other, I figured that there had to be a difference between the advertising packets. I used a sniffer and found that indeed there is. Before the peripheral does directed advertising the RxAdd bit is 0 according to spec. After I connected, disconnected, did direct advertising, and finally started undirected advertising again, the bit was 1. So what happens is that: 
 
 The Softdevice initializes with the RxAdd bit set to 0 according to spec. 
 The Softdevice starts undirected advertising. 
 After connecting and disconnecting again, the Softdevice starts directed advertising. 
 Since the previously connected peer had a random address, the RxAdd bit is set to 1 during the directed advertising. 
 When the Softdevice finally starts undirected advertising again, it forgets to revert the bit back to 0 , violating the spec requirement in Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU) . 
 
 The bug in the Softdevice seems to be present in all three SoftDevices mentioned in this case, but it probably affects other SoftDevice versions too. It is a simple bug, but every change we make to the SoftDevice, however small or significant, has to go through vigorous testing and the stack might need to be requalified. Hence, this is not something we can fix and publish overnight and I cannot make any promises about how long it will take. 
 But why does this seemingly only happen with Samsung Galaxy S7 and S8 Phones? 
 It seems like these phones also violates the spec requirements in Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU) , by not ignoring the RFU field in undirected advertising packets. The phones probably receive the packets, but chose to filter them out due to the unexpected value in the RxAdd field. Other phones, that correctly ignores the field, can discover and connect just fine, even though there is a spec violation in our Softdevice. 
 The common denominator in the case seems to be Samsung Galaxy S7/S8 phones, and Android 7. However, there is no guarantee that the issue is not present in other phones, chipsets, and/or operating systems. It could be interesting to try other Galaxy models or Galaxy S7 and S8 with other Android versions. I do not know, and I am not in a position to find out, whether this is a Samsung Galaxy software issue, a chipset issue, or a combination of both. 
 
 Workaround 
 So far, we only see two workarounds: 
 
 Easy, but unfortunate: Disable and re-enable the Softdevice after directed advertising. 
 Complicated, and also unfortunate: If re-enabling the Softdevice is impossible, start directed advertising towards a public dummy address every time after doing directed advertising to a random address. This will set the bit back to 0. 
 
 
 EDITS: 
 Tested Samsung Galaxy S5 with Android 6.0.1 - Works fine.

Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Top Replies

Background

Cause

Workaround

EDITS:

Background

Cause

Workaround

EDITS: