How to determine Bluetooth connection and bond status?

[FinnBiggs]

Hello Nordic Engineers!

Thank you in advance for your time and advice.

===== Overview =====

I'm developing (sort of) a Bluetooth mouse using the nRF Desktop Application as a jumping-off point. I've run into an undesirable program state and I'm not sure how to go about handling / preventing it.

It's possible to enter a state where the central (e.g. your computer) has forgotten the device (dev kit), yet the device is using directed advertising towards that computer. That directed advertising makes the device invisible to anyone (else) searching for it, including the central that just forgot it (biggest issue).

The only way out of this state that we've found is to manually run a peer erase, which is acceptable, but not overtly obvious (especially to an end user).

Ultimately, I'd like to have a "Bluetooth No Connection Indicator" that is distinct from "Bluetooth Advertising" -- with this, I can inform the user via LED that the device is looking for a specific connection that it hasn't found yet. That indicator will prompt the user to either run a Peer Erase Operation, connect to the dedicated device (in the case where the bonded central is just "off"), or switch to an unoccupied peer identity with our peer swap button (in the case that the user wants to add a second supported central).

===== Environment =====

Here are my environment details:

nRF52840DK (development environment)

which will transition to Xiao BLE Sense for (production environment)

Using Nordic's SDK v2.5.0 (installed via nRF Connect Desktop App)

(Though I'm willing to switch to 2.6.Latest if there is a fix there)

Running in VS Code, Win 11 Host Machine, MINGW Bash environment

===== Questions =====

Preamble to question:

Connecting to our device from a central causes the device store some bond data. When the central disconnects from that device, the information persists, which is desirable. However, once the device resets (e.g. Device Power Management / User switches "Off"), that information still persists, but is no longer available to the user (my) application (that I can find). The device doesn't automatically reconnect (which makes sense since the central dropped it), but also doesn't show as available on either the (former) central or other scanning devices.

In summary: the problem state occurs when the central disconnects, then the peripheral resets, which causes the device to become invisible until a peer erase. I'd like to indicate that the device is in this state, despite device resets.

Question:

How can I access that information from my application modules?

I would be happy for a way to query:

1. The current bt_conn object, so I can check it's connection status and use its security (level) information to judge if that connection is "occupied" by a bond

2. The ble_adv data, so I can determine if the advertising is directed

3. The generic "ble settings / bond settings" persistent information -- to determine which identities are "occupied"

Where I'm stuck:

When my device boots, I get quite a lot of events about the startup of the device. Notably, though, I do not see an event whose structure contains info on (1), (2), or (3) above that might let me infer the current saved-information state.

Those only occur once I actually run a connect operation, which isn't possible if the device is already directed advertising to a computer that ignores it.

Thanks again for any advice you can give!

============

Wishing you all a happy weekend,

    - Finn

[Einar Thorsrud]

Hi Finn,

Do you have a log and sniffer trace of the BLE traffic? I ask beacause directed advertising is normally only used for a short time after a disconnect, so I am wondering if the device is advertising at all? Or if it is advertising with filter accept list? Also, do you have a log from the nRF?

Also, if the peer (PC) has deleted the bonding infromation, the bonding information needs to be deleted on the nRF side as well, or it needs to be configured to accept re-pairing.

Regardless, if the device either use directed advertising or filter accept list (whitelist) to only connect to a peer which has deleted it's bond, that will cause problems. So you neec to have a way to delete bonds and/or put the deviec in general discoverable mode where  anyone can connect. This can be done in different way, but typicaly ways this is done on mice is by a special button, or for isntance that it is generally discoverable the first (say) 30 seconds arter a reset (typically by power-cycling the device).

If the nRF has bonding information but the PC does not, and the sam PC attempts to connect and bond again, it will cause an error unless you allow replacing bonds (see this post).

Br,

Einar

[FinnBiggs]

Hi Einar,

I'll include those traces here, though I am still hoping for an answer to my core question: how do I query Bluetooth Connection information from the nRF application side?

(Baseline -- pristine build, erase chip, run a peer erase operation manually on both possible identities, reset device)

Here's the behavior (and timestamp in the sniffer trace) of the device as I run through the following steps.

1. Device is advertising (and detectable to searching peers)
   
   1. T(s) = [ 0.10 - 25.00]
2. Device connects and pairs with central (Win 11 PC)
   1. T(s) = [ 25.01 - 25.33 ]
3. Service Discovery and misc communications
   1. T(s) = [ 25.4 - 26.99 ]
4. Encrypted connection data successfully moves mouse cursor
   1. T(s) = [ 27.01 - 51.54 ] (apologies for the long run, took me a while to check the log on app side)
5. Disconnection occurs somewhere in this window
   1. T(s) = [ 51.57 - 55. 54 ]
6. Advertising begins again, but device is invisible
   1. T(s) = [ 59.55 -- END ]

nRFDesktopDirectedAdvTrace.pcapng

Meanwhile, on the logging side of things, here is the (slightly trimmed, annotated) trace.

# Log

SEGGER J-Link V7.96h - Real time terminal output
SEGGER J-Link (unknown) V1.0, SN=801043252
Process: JLink.exe

*** Booting nRF Connect SDK v2.5.0 ***

// Note: I'm abridging this log to only include what is (or is likely to be) relevant.
// I'm ignoring things like battery events, file system setup, and I'm taking out the name of the device
// I'll also add in some line breaks / annotations for clarity

/***** "Section 1 -- Booting up" *****/

[00006691] <inf> led_state: setting idle led
[00009827] <inf> app_event_manager: e:module_state_event module:main state:READY
[00009829] <inf> file_system: file_system state ready
        pin configured //  (imu interrupt pin)
[00009857] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
                                    c5 93 ba a9 14 4d 8d 05  30 4e 9b 92 d7 71 1e e8 |.....M.. 0N...q..
                                    aa 02 50 3c                                      |..P<             

[00009872] <inf> power_manager: Activate power manager
[00009875] <inf> app_event_manager: e:module_state_event module:file_system state:READY
[00009902] <inf> hids: Service initialized
        IMU set up successfully // i2c device configured by module
[00009953] <inf> ble_bond: new name: myDeviceName
[00010142] <inf> hid_state: Init HID state!
[00010143] <inf> led_state: LED ID from map: 0

[00010145] <inf> app_event_manager: e:module_state_event module:buttons state:READY
[00010148] <inf> app_event_manager: e:module_state_event module:click_detector state:READY
[00010151] <inf> app_event_manager: e:module_state_event module:leds state:READY

[00010252] <inf> ble_state: Bluetooth initialized

[00010254] <inf> app_event_manager: e:module_state_event module:board state:READY
[00010256] <inf> app_event_manager: e:module_state_event module:hids state:READY
[00010259] <inf> app_event_manager: e:module_state_event module:lsm6dsl state:READY
[00010264] <inf> app_event_manager: e:module_state_event module:ble_state state:READY
[00010296] <inf> app_event_manager: e:module_state_event module:motion_imu state:READY
[00010299] <inf> app_event_manager: e:module_state_event module:bas state:READY

[00010713] <inf> settings_loader: Settings loaded
[00010747] <inf> app_event_manager: e:module_state_event module:settings_loader state:READY
[00010750] <inf> ble_bond: new name: myDeviceName

/***** "Section 2 -- Advertising" *****/

[00010937] <inf> ble_bond: Device has 4 identities
[00010938] <inf> ble_bond: Selected BLE peers
[00010970] <inf> app_event_manager: e:ble_peer_operation_event SELECTED bt_app_id=1 bt_stack_id=3
[00010971] <inf> led_state: Peer Selected
[00010972] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00010974] <inf> app_event_manager: e:module_state_event module:ble_bond state:READY
[00010976] <inf> ble_adv: Use fast advertising
[00011037] <inf> ble_adv: Advertising started
[00011041] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00011043] <inf> app_event_manager: e:module_state_event module:ble_adv state:READY
[00011046] <inf> app_event_manager: e:ble_peer_search_event active

/***** "Section 3 - Connection" *****/

[00011046] <inf> led_state: Peer Selected
[00011047] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00011049] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00015432] <inf> app_event_manager: e:usb_state_event state:ACTIVE
[00015433] <inf> led_state: setting idle led
[00015436] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c088
[00215235] <wrn> bt_gatt: Failed to set security for bonded peer (-22)
[00215240] <inf> ble_state: Connected to 00:D4:9E:A5:FB:B2 (public)
[00215242] <inf> ble_state: Identity 3 has 0 bonds
[00215251] <inf> app_event_manager: e:ble_peer_event id=0x200040b0 CONNECTED
        // Note: you'll see the following printout a few times -- this data is the content of whichever ble_peer_event most-recently occurred.
        type         1 
        role         0x01 
        id           0x03 
        state        2 
        security     (level) 1, (size) 0, (flags) 0 
[00215257] <inf> hid_state: Subscriber 0x200040b0 connected
[00215258] <inf> led_state: Peer Selected
[00215259] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00215261] <inf> ble_adv: Advertising stopped
[00215264] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x200040b0 min=2a max=2a lat=0 timeout=960 (updated)
[00215289] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00215291] <inf> app_event_manager: e:ble_peer_search_event inactive
[00215291] <inf> led_state: Peer Selected
[00215292] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00215298] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to SUSPENDED
[00215300] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00253351] <inf> ble_state: Security with 00:D4:9E:A5:FB:B2 (public) level 2
[00253357] <inf> app_event_manager: e:hid_notification_event report_id 0x1 enabled

// After connection, security goes L1 -> L2

[00253358] <inf> app_event_manager: e:ble_peer_event id=0x200040b0 SECURED
[00253360] <inf> hids: Notifications for report 0x1 are enabled
        type         1 
        role         0x01 
        id           0x03 
        state        2 
        security     (level) 2, (size) 16, (flags) 1 
[00253366] <inf> led_state: Peer Selected
[00253367] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00253369] <inf> app_event_manager: e:hid_report_subscription_event report 0x1 notification enabled by 0x200040b0
[00253373] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00268688] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x200040b0 min=6 max=6 lat=99 timeout=400 (updated)
[00316048] <inf> app_event_manager: e:led_ready_event led_id:0 effect:0x8c098
[00316048] <inf> led_state: setting idle led
[00316052] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c0f0
[00320947] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x200040b0 min=6 max=6 lat=0 timeout=400 (updated)
[00340611] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x200040b0 min=6 max=6 lat=99 timeout=400 (updated)

/***** "Section 4 - Disconnection" *****/

[00434493] <err> hids: Cannot send report (-13)
[00434504] <inf> ble_state: Disconnected from 00:D4:9E:A5:FB:B2 (public) (reason 19)
[00434507] <err> hid_state: Error while sending report
[00434507] <inf> hid_state: Clear report data (0x20005f40)
[00434509] <inf> app_event_manager: e:hid_notification_event report_id 0x1 disabled
[00434510] <inf> hids: Notifications for report 0x1 are disabled
[00434512] <inf> app_event_manager: e:ble_peer_event id=0x200040b0 DISCONNECTED
        type         1 
        role         0x01 
        id           0x03 
        state        0 
        security     (level) 2, (size) 16, (flags) 1 
[00434518] <inf> hid_state: Clear report data (0x20005f40)
[00434519] <inf> hid_state: Subscriber 0x200040b0 disconnected
[00434520] <inf> led_state: Peer Selected
[00434520] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00434523] <wrn> hid_state: No linked report sink
[00434525] <inf> app_event_manager: e:hid_report_subscription_event report 0x1 notification disabled by 0x200040b0
[00434525] <wrn> hid_state: No subscriber 0x200040b0
[00434526] <wrn> hid_state: No subscriber 0x200040b0
[00434527] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00434529] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to MAX

/***** "Section 5 - Invisible Advertising" *****/
[00434531] <inf> ble_adv: Use fast advertising
[00434593] <inf> ble_adv: Advertising started
[00434594] <inf> app_event_manager: e:ble_peer_search_event active
[00434595] <inf> led_state: Peer Selected
[00434596] <inf> led_state: Submitting: LED_ID (0),  EFFECT ADDR (0x8c098)
[00434600] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c098
[00497299] <inf> app_event_manager: e:led_ready_event led_id:0 effect:0x8c098
[00497299] <inf> led_state: setting idle led
[00497302] <inf> app_event_manager: e:led_event led_id:0 effect:0x8c088

Thank you for getting back to me, I appreciate your advice.

Warm Regards,

    - Finn

[Einar Thorsrud]

Hi Finn,

FinnBiggs said:

how do I query Bluetooth Connection information from the nRF application side?

I am sorry, I forgot to adress that. Reading over again I am not sure which information you are requestion. Can you elaborate on exactly what you want to know in which case? That said, you will get callbacks for connection related events like connections and disconnects. And if you want a list of the devices you are bonded with, you can get that as well (you can do that with bt_foreach_bond(), and there are some examples of this being used for isntance in the nRF Desktop application).

[FinnBiggs]

Hi Einar,

I'm looking for a way to determine my device's Bluetooth state and bond bond behavior before a connection occurs. Specifically, I want to be able to check if my device is in the undesirable state I described before.

I could make that determination with any one of the following pieces of information:

1. The (current) bt_conn object
   1. I would need a method that gives my application a handle for the bt_conn object without waiting for it to come along in a connection/disconnection event. Otherwise, I can't guarantee correct behavior on my device's boot.
   2. I would examine this object for it's bt_conn_info, which contains both its id, le address, and current connection state.
2. The BLE advertising data, so I can determine that the appearance / discoverability is wrong
   1. "How can I get a handle for the BT Advertising data?"
3. A way to check the settings that are stored in non-volatile memory, so I can determine if my device "expects" a certain connecting device
   
   1. (or if it believes it should set up as non-discoverable, so I can change that)

I am requesting information on how to get data for 1, 2, or 3 above -- whichever is possible, or easy, or best-supported.

Best,

    - Finn

[Einar Thorsrud]

Hi Finn,

FinnBiggs said:

I would need a method that gives my application a handle for the bt_conn object without waiting for it to come along in a connection/disconnection event. Otherwise, I can't guarantee correct behavior on my device's boot.

I am sorry, but I still don't understand. On boot (reset) there is no connection before the peripheral (mouse in this case) starts advertising and a central connects. So there i no connection object at this point. When the conneciton is established, you get all the information in the connected callback.

FinnBiggs said:

The BLE advertising data, so I can determine that the appearance / discoverability is wrong

1. "How can I get a handle for the BT Advertising data?"

Also here, as the peripheral you configure the advertiser, so I am not sure wht you are looking for here? If you based your application on nRF Desktop this may be a bit more hidden as it use the CAF framework but you can see how the advertising data is handled there (in nrf/subsys/caf/modules/ble_adv.c if you kept that from nRF Desktop).

CAF also use extensive logging, so if you are not sure what is happening, perhaps you can start with enabling more logging for what you are interested in, probably with CONFIG_CAF_BLE_ADV_LOG_LEVEL_DBG=y in this case to better understand what is going on.

FinnBiggs said:

1. A way to check the settings that are stored in non-volatile memory, so I can determine if my device "expects" a certain connecting device
   
   1. (or if it believes it should set up as non-discoverable, so I can change that)

The relevant settins in this case is probably the bonds, and that you can check with bt_foreach_bond(). That will only give you the address of each bonded device though, the rest is handled by the stack. But this address can be used in other API calls (like when populating a filter accept list).

I have one question, though: You write about directed advetising, but from the sniffer trace that does not seem to be the case? (there is one directed advertising packet in the trace file, but that comes from what I assume is another device - packet #229). So why do you think directed advertising is used and is a problem?

[FinnBiggs]

Hi Einar,

Thanks for sticking with me. I think I have a bit better insight as to what's going on now than I did before. I'm incorrect about directed advertising, so please disregard that component.

What I actually MEANT by directed advertising was a different behavior that I wrongly assumed was directed. (This is because the bond id and the peer id matched -- more on this later.)

I think I disagree that there is no connection object before a pairing event. Even immediately on reset, the method bt_conn_foreach returns a connection object (but in a disconnected state).

First, I'll share minimal changes to nRF Desktop that will let you reproduce.

First:

set CONFIG_BT_MAX_PAIRED = 3 and CONFIG_BT_ID_MAX = 4.

Second (required after First change):

Make the following changes to (your board)/led_state_def.h

Change this:

static const struct led_effect led_peer_state_effect[LED_PEER_COUNT][LED_PEER_STATE_COUNT] = {
	{
		[LED_PEER_STATE_DISCONNECTED]   = LED_EFFECT_LED_OFF(),
		[LED_PEER_STATE_CONNECTED]      = LED_EFFECT_LED_ON(LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_PEER_SEARCH]    = LED_EFFECT_LED_BREATH(1000, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_CONFIRM_SELECT] = LED_EFFECT_LED_BLINK(50, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_CONFIRM_ERASE]  = LED_EFFECT_LED_BLINK(25, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_ERASE_ADV]	= LED_EFFECT_LED_BREATH(100, LED_COLOR(100, 100, 100)),
	},
};

To this:

static const struct led_effect led_peer_state_effect[LED_PEER_COUNT][LED_PEER_STATE_COUNT] = {
	[0 ... LED_PEER_COUNT-1] = {
		[LED_PEER_STATE_DISCONNECTED]   = LED_EFFECT_LED_OFF(),
		[LED_PEER_STATE_CONNECTED]      = LED_EFFECT_LED_ON(LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_PEER_SEARCH]    = LED_EFFECT_LED_BREATH(1000, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_CONFIRM_SELECT] = LED_EFFECT_LED_BLINK(50, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_CONFIRM_ERASE]  = LED_EFFECT_LED_BLINK(25, LED_COLOR(100, 100, 100)),
		[LED_PEER_STATE_ERASE_ADV]	= LED_EFFECT_LED_BREATH(100, LED_COLOR(100, 100, 100)),
	},
};

----------

Next, (but not required)

I also add some introspection code that triggers on a button event to log data about the current bonds and connections. That function and its helpers are below (and I subscribe to caf/button_event in ble_bond.c). As a summary, this code calls bt_foreach_bond with identities ranging from 0-4 and bt_conn_foreach.

/*** Excerpt from ble_bond.c ***/

static void conn_check_func(const struct bt_conn *conn, void *user_data) {
	static struct bt_conn_info conn_info;
	int err = bt_conn_get_info(conn, &conn_info);
	LOG_INF(
		"CONN INFO: Type (%d), Role (0x%02x), ID (0x%02x), State (%d), Security { Level (%d), Size (%d), Flags (%d) }",
		conn_info.type, conn_info.role, conn_info.id, conn_info.state, 
		conn_info.security.level, conn_info.security.enc_key_size, conn_info.security.flags
	);
}

static void bond_check_func(const struct bt_bond_info *bond, void *user_data) {
	int my_addr = 0;
	for (int i = 0; i < BT_ADDR_SIZE; i++) {
		my_addr += (bond->addr.a.val[i] << 8*i);
	}


	LOG_INF("Bond: Address (0x%012x), Type (0x%02x)", my_addr, bond->addr.type);
}

static bool handle_button_event(const struct button_event *event) {
	if(event->key_id == 0x01 && event->pressed == true)
	{
		bt_foreach_bond(BT_ID_DEFAULT, bond_check_func, NULL);
		LOG_INF("1");
		bt_foreach_bond(1, bond_check_func, NULL);
		LOG_INF("2");
		bt_foreach_bond(2, bond_check_func, NULL);
		LOG_INF("3");
		bt_foreach_bond(3, bond_check_func, NULL);
		LOG_INF("4");
		bt_foreach_bond(4, bond_check_func, NULL);

		bt_conn_foreach(BT_CONN_TYPE_LE, conn_check_func, NULL);
	}
	return false;
}

(Which, thank you for the pointer to the foreach methods -- I was stuck until I started using both)

I've now observed is that my "error state" occurs when the bluetooth connection id also contains a bond on that same identity.

Here is a trace of ble_bond and ble_connection information in both the discoverable and non-discoverable state.

/*** Working -- no bond ***/
[00099557] <inf> ble_bond: 0 (default)
[00099558] <inf> ble_bond: 1
[00099558] <inf> ble_bond: 2
[00099559] <inf> ble_bond: 3
[00099559] <inf> ble_bond: 4 (out of bounds)
[00099560] <inf> ble_bond: CONN INFO: Type (1), Role (0x00), ID (0x00), State (1), Security { Level (1), Size (0), Flags (0) }


/*** Working -- active connection ***/
[04858377] <inf> ble_bond: 0 (default)
[04858378] <inf> ble_bond: Bond: Address (0x00009ea5fbb2), Type (0x00)
[04858378] <inf> ble_bond: 1
[04858379] <inf> ble_bond: 2
[04858379] <inf> ble_bond: 3
[04858379] <inf> ble_bond: 4 (out of bounds)
[04858381] <inf> ble_bond: CONN INFO: Type (1), Role (0x01), ID (0x00), State (2), Security { Level (2), Size (16), Flags (1) }


/*** Working -- bond present ***/
// Connection ID is not equal bond's id
[00366213] <inf> ble_bond: 0 (default)
[00366214] <inf> ble_bond: Bond: Address (0x00009ea5fbb2), Type (0x00)
[00366214] <inf> ble_bond: 1
[00366215] <inf> ble_bond: 2
[00366215] <inf> ble_bond: 3
[00366216] <inf> ble_bond: 4 (out of bounds)
[00366216] <inf> ble_bond: CONN INFO: Type (1), Role (0x00), ID (0x03), State (1), Security { Level (1), Size (0), Flags (0) }


/*** NOT Working -- bond present (my error state) ***/
// Connection ID matches bond's id
[08168933] <inf> ble_bond: 0 (default)
[08168934] <inf> ble_bond: Bond: Address (0x00009ea5fbb2), Type (0x00)
[08168934] <inf> ble_bond: 1
[08168935] <inf> ble_bond: 2
[08168935] <inf> ble_bond: 3
[08168936] <inf> ble_bond: 4 (out of bounds)
[08168936] <inf> ble_bond: CONN INFO: Type (1), Role (0x00), ID (0x00), State (1), Security { Level (1), Size (0), Flags (0) }

Briefly, I'll jump back to (my confusion regarding) directed advertising. I thought that since there was a bond saved and associated with the current connection identity, the device must be using directed advertising.

Instead, what happens when the saved bond matches the current ID, is that the advertising packets provided by CAF have the following flags in their advertising.

WORKING: [Packet 11]

Flags
    Length: 2
    Type: Flags (0x01)
    000. .... = Reserved: 0x0
    ...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
    .... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
    .... .1.. = BR/EDR Not Supported: true (0x1)
    .... ..1. = LE General Discoverable Mode: true (0x1)
    .... ...0 = LE Limited Discoverable Mode: false (0x0)

NOT WORKING: [Packet 4448]

Flags
    Length: 2
    Type: Flags (0x01)
    000. .... = Reserved: 0x0
    ...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
    .... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
    .... .1.. = BR/EDR Not Supported: true (0x1)
    .... ..0. = LE General Discoverable Mode: false (0x0)
    .... ...0 = LE Limited Discoverable Mode: false (0x0)

For some reason, when the computer disconnects, the advertising flags are set to non-discoverable.

I now have the tools to indicate to my user that their device is need of a reset, but I still need a way to correct these flags.

Do you have advice for how I might make my device discoverable in this state? 

(also, would there be unforeseen consequences to this?)

Thank you again for your reply.

Best,

    - Finn