[Android MCP App] Showing "connect button" at a beacon?

Question

/**************** Test Condition **********************/

Phone: Nexus 5 (Android 6.0.1)
nRF Beacon Kit
MCP App Version 4.0.3

/**********************************************************/
 
 
 
 Hi, I use a nRF Beacon kit. I didn't change the firmware of the beacon. 
 As far as I know, beacon is a non-connectable peripheral. 
 As a result, that "connect button" seems questionable to me. 
 It doesn't connect even if I press it. :D 
 Anyways, my questions are 
 
 There's really no way that beacon (peripheral) can be connected with a central (ex. iPhone) 
 
 without changing the services and characteristics? 
 (I think this question has really came frequently :D) 
 Then, personally, I think that "connect button" for beacons 
 should be removed like the old MCP app. 
 
 Then, is there an example that a peripheral acts both a scanner and advertising peripheral? 
 
 I hope for a scenario like the following: 
 Central device (ex. iPhone) comes near the beacon which is advertising data. -> 
 (Suppose this beacon does not use other services such as HID or NUS, only advertising beacon.) 
 The iPhone then sends a scan response request to that beacon. -> 
 (I'm not sure if central devices sends that packet when it gets advertising data from a beacon.) 
 The beacon gets the scan response request packet and blinks the LED. 
 Of course, if there are multiple beacons near the central device, it will be tricky. 
 However, let's assume there's one beacon and one central. 
 Is this scenario possible?
Plus, making the beacon to both scan and advertise (doing both of this is also questionable though)
will fit this scenario? 
 -Best Regards 
 **/ Edited, @ Võ Thanh Hiếu / 
 
 Thanks, you are meaning here? 
 I'm using SDK 7.2 and Softdevice S110. 
 The beacon example doesn't have this on_ble_event. 
 Anyways, I will try it out. Thanks~ 
 **/ Edited 2, @ Võ Thanh Hiếu, Test Result / 
 Hi, Võ Thanh Hiếu. Thanks for your tip and other references, I got some results, maybe? :D 
 Ref. 1 Stefan Birnir Sverrisson's answer 
 Ref. 2 Petter Myhre's answer 
 
 

 The problem is this "peer address" change doesn't it? 
 Sorry if I dragged this question quite long. This will be my last one. 
 -Best Regards

Hieu · Accepted Answer

As far as I know, whether a peripheral can be connected to or not depends on the advertisement type. Therefore if you want to modify it so that it could be connected to, you would want to modify the advertisement type, not any services, characteristics or descriptors, i.e. its GATT profile. 
 
 
 Two points: 
 
 
 2.1. I have not tried this in person, but under the GAP events listed here , your application can receive a BLE_GAP_EVT_SCAN_REQ_REPORT . My bet is that this is the event triggered when an advertiser received a scan request. You can override the on_ble_evt code to handle this event according to your liking (blink LED). 
 UPDATE 2016 Jan 18: 
 You will need to enable the GAP option BLE_GAP_OPT_SCAN_REQ_REPORT before you can receive BLE_GAP_EVT_SCAN_REQ_REPORT . It probably could be done anytime but for your application it would make sense to enable this option before starting advertising. I was able to enable the option with this code. 
 // Creating an option struct that enable the scan_req_report event to be sent by the SoftDevice
 ble_opt_t opt;
 opt.gap_opt.scan_req_report.enable = true;
 
 err_code = sd_ble_opt_set(BLE_GAP_OPT_SCAN_REQ_REPORT, &opt);
 if (err_code != NRF_SUCCESS) {
 switch (err_code) {
 case NRF_ERROR_INVALID_ADDR: {
 printf("sd_ble_opt_set() == NRF_ERROR_INVALID_ADDR
");
 break;
 }
 case BLE_ERROR_INVALID_CONN_HANDLE: {
 printf("sd_ble_opt_set() == BLE_ERROR_INVALID_CONN_HANDLE
");
 break;
 }
 case NRF_ERROR_INVALID_PARAM: {
 printf("sd_ble_opt_set() == NRF_ERROR_INVALID_PARAM
");
 break;
 }
 case NRF_ERROR_INVALID_STATE: {
 printf("sd_ble_opt_set() == NRF_ERROR_INVALID_STATE
");
 break;
 }
 case NRF_ERROR_BUSY: {
 printf("sd_ble_opt_set() == NRF_ERROR_BUSY
");
 break;
 }
 default: {
 printf("sd_ble_opt_set() == %" PRIu32 "
", err_code); // need #include <inttypes.h> to use PRIu32
 break;
 }
 
 }
 } else {
 printf("sd_ble_opt_set() == NRF_SUCCESS
");
 }
 
 The err_code handling code is obviously set up just for debugging. Remove/edit it as you need. 
 I cannot find anywhere in the documentation about this. The only way I could find any hint to this by doing a project wide search for BLE_GAP_EVT_SCAN_REQ_REPORT . It would lead to the definition of ble_gap_opt_scan_req_report_t , which suggested to me that there is an option that has to be enabled before I could receive the event. 
 UPDATE 2016 Jan 29 to address @Mango922's updated question : 
 -. First two things I forgot to address: 
 a. Do be aware that according to this SDK documentation , it is expected that you do not receive an event for every single scan requests the device receive. 
 b. Regarding your note of not knowing if a central device will send a scan request. The answer is it depends. There are two scanning mode a scanner device can scan in: Active and Passive. 
 If a scanner use Active scanning, it will send a scan request when it receives an advertisement. 
 If a scanner use Passive scanning, it will not send a scan request when it receives an advertisement. 
 You could see this also noted in Stefan Birnir Sverrisson's answer that you linked. 
 -. Now to address your question about the peer_addr 
 As I understand it, the peer_addr would be the address of whatever device responsible for the scan request that your advertiser device received. If there are multiple devices scanning in the room, you should expect receiving different event with different peer_addr value, each for a different device. 
 The peer_addr might also change when the central device change its address. The BLE specification does allow several ways that any one device can have its address change. An example is for security purpose. However I have not studied much of this so I cannot explain to you under what situation this is to be expected. I haven't even seen a case where a central change its address either. My guess is that it completely depends on the central device design. 
 2.2. I am unsure what you mean by "scanner." I don't think the peripheral you are describing is one working as a "scanner." A scanner is one looking for advertisements. The peripheral you are describing is not scanning anything. It is just advertising and receiving scan request.