How to disable ANCS_C

[Konstantin]

Hi all, I have a problem in architecture of my application based on SD132v3 SDK12. It should interact with an iOS device as a peripheral and receive some data to display. Bonding is required for my task. Main goal is to allow multiple iOS devices to display their data on my device so I decided to use next simple way: certain previously bonded iOS device in range having some data to display tries to connect my device, writes to dedicated characteristic and then disconnects. So different users (iOS devices) can use my device because of real connected state is too short. But another task of my device is to display incoming calls of iOS device, so I want to use the ANCS_C module. In that case I have a problem that once the ANCS_C have successfully discovered presence of desired characteristics the connection will never be reset. It is OK in most cases (if user wants to see call notification he will be warned about unshared occupancy) but sometime I have to establish new connection (I have mechanical button “accept new bond”). So my questions are:

1. Is there some better way to maintain both functionalities?

2. Can I establish two connections: one for long time ANCS and another one for short sessions with multiple devices?

3. Worst way. How to disable for a while current ANCS connection to accept new bonding peer?

[FormerMember]

1) By maintaining both functionalities, I assume you mean "being able to maintain the ANCS connection while connecting to a new device to add new bonding information". What you could test if works is the following: While maintaining the ANCS connection, you can connect to the other device as a central, and do the bonding process. At a later point in time, the two devices can re-connect with switched roles. (If choosing to test this, the following has to be set in peer manager when bonding for the first time: the 'enc' flag in kdist_own and kdist_peer should be set to 1.)

2) Unfortunately, it's not possible to have two concurrent peripheral connections. If you want two concurrent connections, at least one of them has to be a central. Another option could be to test if it works to have the nRF52 ANCS module as a central instead of a peripheral.

3) Disable ANCS connection means to disconnect. That can be done using sd_ble_gap_disconnect(..).

Update 07.10.2016: It is not really a bug in iOS that it tries to re-connect, it is just that the iOS device will try to re-connect to a lost/disconnected connection with a bonded device (which is normal behavior). You can check if it changes anything if the nRF52 disables notifications before disconnecting from the iOS device. (I don't know if this last suggestion will change anything, but it's worth a try.)

If you want to avoid that iOS automatically re-connects, your nRF52 can use another address when it re-starts to advertise. By doing so, the iOS device will not be able to recognize the nRF52. The nRF52 will then operate with two identities, two addressees. If you then have one device bonded with the nRF52 for one address, it will not be possible to use the same bonding information with that device if the nRF52 change the address. If you have multiple devices where some are bonded with one address and some are bonded with another address and you want them to be able to connect to your device, you will have to alternate which address you advertise with.

The reason that the bonding will information with one device not work with when changing the address, is that the address type (default) is of the type " random static" and is not supposed to change.

[Konstantin]

Hi, Kristin. Thanks for your reply. I'm very interested in option 2. Can you please explain or point to information about starting ANCS as a central?

[FormerMember]

As you probably know, there is an ANCS peripheral example in the SDK. What you would need to do is to "port" it to a central example. The "only" thing you will have to change is everything related to the connection handling. Everything else, the ANCS functionality will remain the same; the nRF52 should still be a client device with the same functionality as when it was a peripheral.

On the iOS side, you will need to make the iOS device advertise. To do so, you can use the lightblue app.

[Konstantin]

I created central and peripheral connection and it seems to be working. Is it possible to avoid advertising of iOS device? I use following code to establish connection without parsing advertising packets:

case PM_EVT_BONDED_PEER_CONNECTED:
{
	err_code = pm_peer_rank_highest(p_evt->peer_id);
	if (err_code != NRF_ERROR_BUSY)
	{
		APP_ERROR_CHECK(err_code);
		app_sched_event_put(0, 0, central_con_start);
	}
} break;
	
void central_con_start(void *pp_event_data, uint16_t event_size)
{
	ble_gap_addr_t server_addr;
    // get the address of the current iOS peer
	uint32_t err_code = im_ble_addr_get(m_conn_peripheral, &server_addr);
	if (err_code != NRF_ERROR_NULL)
	{
		APP_ERROR_CHECK(err_code);
		err_code = sd_ble_gap_connect(&server_addr, &m_scan_params, &m_connection_param);
	}
}

But even this code seems to require advertising.

[FormerMember]

Unfortunately, it's not possible to establish a connection without the iOS device advertising, when the iOS device is a peripheral device.