Always reconnect after peers deleted

[Borden]

Hi community,

I'm working on a BLE gamepad with custom board based on 51802 and s130, code modified from ble_app_hids_keyboard. The gamepad works like a charm on my Android phone, but I found there's a strange problem with reconnecting.

If I hold a specific button down while power up, the gamepad deletes all peers, just like the keyboard example does, but I don't know why, it still reconnect to my phone automatically, no matter whether peers were deleted. The only way to unbond to the phone is to delete bond from the phone side. I've tried several phones and several boards, all same results. Is that suppose to happen?

My pm init code is:

#define SEC_PARAM_BOND					1
#define SEC_PARAM_MITM					0
#define SEC_PARAM_LESC					0
#define SEC_PARAM_KEYPRESS				0
#define SEC_PARAM_IO_CAPABILITIES		BLE_GAP_IO_CAPS_NONE
#define SEC_PARAM_OOB					0
#define SEC_PARAM_MIN_KEY_SIZE			7
#define SEC_PARAM_MAX_KEY_SIZE			16

memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));
>
// Security parameters to be used for all security procedures.
sec_param.bond			= SEC_PARAM_BOND;
sec_param.mitm			= SEC_PARAM_MITM;
sec_param.lesc			= SEC_PARAM_LESC;
sec_param.keypress		= SEC_PARAM_KEYPRESS;
sec_param.io_caps		= SEC_PARAM_IO_CAPABILITIES;
sec_param.oob			= SEC_PARAM_OOB;
sec_param.min_key_size	= SEC_PARAM_MIN_KEY_SIZE;
sec_param.max_key_size	= SEC_PARAM_MAX_KEY_SIZE;
sec_param.kdist_own.enc	= 1;
sec_param.kdist_own.id	= 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id	= 1;
err_code = pm_sec_params_set(&sec_param);
APP_ERROR_CHECK(err_code);

the adv init code is:

void advertising_init(void)
{
	uint32_t				err_code;
	uint8_t					adv_flags;
	ble_advdata_t			advdata;
	ble_adv_modes_config_t	options;
	// Build and set advertising data
	memset(&advdata, 0, sizeof(advdata));

	adv_flags						= BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
	advdata.name_type				= BLE_ADVDATA_FULL_NAME;
	advdata.include_appearance		= true;
	advdata.flags					= adv_flags;
	advdata.uuids_complete.uuid_cnt	= sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
	advdata.uuids_complete.p_uuids	= m_adv_uuids;

	memset(&options, 0, sizeof(options));
	options.ble_adv_whitelist_enabled		= false;
	options.ble_adv_directed_enabled		= true;
	options.ble_adv_directed_slow_enabled	= false;
	options.ble_adv_directed_slow_interval	= 0;
	options.ble_adv_directed_slow_timeout	= 0;
	options.ble_adv_fast_enabled			= true;
	options.ble_adv_fast_interval			= APP_ADV_FAST_INTERVAL;
	options.ble_adv_fast_timeout			= APP_ADV_FAST_TIMEOUT;
	options.ble_adv_slow_enabled			= false;
	options.ble_adv_slow_interval			= APP_ADV_SLOW_INTERVAL;
	options.ble_adv_slow_timeout			= APP_ADV_SLOW_TIMEOUT;

	err_code = ble_advertising_init(&advdata,
								NULL,
								&options,
								on_adv_evt,
								ble_advertising_error_handler);
	APP_ERROR_CHECK(err_code);
}

Thanks in advance.

[Borden]

Hi Alex, nice to see you again:)

Still, I don't think WL is really the essential in my situation. I feel what's really matter is, to find a way to tell accidentally disconnection from disconnection on purpose. Once I can do that, then the WL is just involved in how to deal with these to situations.

[Alex]

I see now. Look at this question.

[Petter Myhre]

Now I understand your problem a bit better I think.

Are you using Bluetooth Settings directly? Or do you have an app?

When you say "if I disconnect from A", how are disconnecting? Are you disconnecting from the gamepad or from the smart phone? If you disconnect (not delete bond) from the smart phones Bluetooth Settings my experience is that it doesn't autoconnect. Let me know if you are experience something else. If not, could it be a solution?

Yes, the 6 byte device address. If you use two different, you can use it to decide which device you want to automatically connect to you. You can also alternate between them (after bonded) if you want both autoconnect.

[Borden]

Thanks Alex, that question is very helpful, let me know that someone had been in a similar situation as I am.

To be a flawless device, I think only blacklist is not enough, even if it can be implemented(which I don't know). Blacklist can solve the problem which disconnecting is initiated from peripheral, but often disconnecting is originated from central, in this case, we don't know if it's on purpose, or due to radio jam, so we can't simply refuse to reconnect request anyway, without knowing the cause.

[Alex]

You can implement your special command over one of your characteristics. Once central sends that command to peripheral then peripheral will disconnect from that central and start ignoring reconnection for certain period of time. After timeout peripheral will return to normal mode