Unexpected BLE_EVT_BLUE_GAP_DEVICE_FOUND event when Peripheral is Connectable

[charles23]

Posted on April 10, 2015 at 23:08

I have been looking at the advertising data delivered to the Central by the BLE_EVT_BLUE_GAP_DEVICE_FOUND event when the Peripheral is in a variety of modes.

(1) When I reset the BlueNRG and issue a BLUEHCI_GAP_SET_GENERAL_DISCOVERABLE or a BLUEHCI_GAP_SET_LIMITED_DISCOVERABLE command to the Peripheral, the Central receives two BLE_EVT_BLUE_GAP_DEVICE_FOUND events. The first is Event_type=ADV_IND and includes AD Type Flags data with either 0x06 (FLAG_BIT_LE_GENERAL_DISCOVERABLE_MODE) or 0x05 (FLAG_BIT_LE_LIMITED_DISCOVERABLE_MODE). The second is Event_Type=ADV_SCAN_IND type and the scan data that I have defined. This is what I expect. (2) When I reset the BlueNRG and issue a BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command I get one  BLE_EVT_BLUE_GAP_DEVICE_FOUND event with Event_Type=ADV_SCAN_IND type and the scan data that I have defined. This is OK. (3) However, if I issue either the BLUEHCI_GAP_SET_GENERAL_DISCOVERABLE or BLUEHCI_GAP_SET_LIMITED_DISCOVERABLE command, then the BLUEHCI_GAP_SET_NON_DISCOVERABLE command, then the BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command (without resetting the BlueNRG between commands) then I get the same two BLE_EVT_BLUE_GAP_DEVICE_FOUND events as in (1) above. This includes the AD Type Flags data from the previous SET_DISCOVERABLE command. This is a bug, surely? I should not get any AD Type Flags data, or if I do then both the FLAG_BIT_LE_GENERAL_DISCOVERABLE_MODE and FLAG_BIT_LE_LIMITED_DISCOVERABLE_MODE bits should be cleared, since the Peripheral is not is a discoverable mode surely? The bug is with the Peripheral, not the Central, as I get the same erroneous data if I reset the Central. Both devices are using V6.4. Work around: I discovered that I can fix the problem by sending a BLUEHCI_GAP_DELETE_AD_TYPE command to the Peripheral, with the parameter set to AD_TYPE_FLAGS, before sending the BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command. Then the Peripheral behaves as (2) above. #bluenrg #bug #advertising

[marchese.graziella]

Posted on April 13, 2015 at 12:21

Dear Customer,

this is a limitation of the fw stack version 6.4  - ID 858: Discoverability flags not reset by ACI_GAP_SET_NON_DISCOVERABLE

Please see the Release Notes for BlueNRG, BlueNRG-MS stacks - BlueNRG Stack v6.4.

As you said the workaround is to clear the advertising data before calling the GAP_SET_UNDIRECTED_CONNECTABLE.

Regards,

Graziella

I have been looking at the advertising data delivered to the Central by the BLE_EVT_BLUE_GAP_DEVICE_FOUND event when the Peripheral is in a variety of modes.

(1) When I reset the BlueNRG and issue a BLUEHCI_GAP_SET_GENERAL_DISCOVERABLE or a BLUEHCI_GAP_SET_LIMITED_DISCOVERABLE command to the Peripheral, the Central receives two BLE_EVT_BLUE_GAP_DEVICE_FOUND events. The first is Event_type=ADV_IND and includes AD Type Flags data with either 0x06 (FLAG_BIT_LE_GENERAL_DISCOVERABLE_MODE) or 0x05 (FLAG_BIT_LE_LIMITED_DISCOVERABLE_MODE). The second is Event_Type=ADV_SCAN_IND type and the scan data that I have defined. This is what I expect. (2) When I reset the BlueNRG and issue a BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command I get one  BLE_EVT_BLUE_GAP_DEVICE_FOUND event with Event_Type=ADV_SCAN_IND type and the scan data that I have defined. This is OK. (3) However, if I issue either the BLUEHCI_GAP_SET_GENERAL_DISCOVERABLE or BLUEHCI_GAP_SET_LIMITED_DISCOVERABLE command, then the BLUEHCI_GAP_SET_NON_DISCOVERABLE command, then the BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command (without resetting the BlueNRG between commands) then I get the same two BLE_EVT_BLUE_GAP_DEVICE_FOUND events as in (1) above. This includes the AD Type Flags data from the previous SET_DISCOVERABLE command. This is a bug, surely? I should not get any AD Type Flags data, or if I do then both the FLAG_BIT_LE_GENERAL_DISCOVERABLE_MODE and FLAG_BIT_LE_LIMITED_DISCOVERABLE_MODE bits should be cleared, since the Peripheral is not is a discoverable mode surely? The bug is with the Peripheral, not the Central, as I get the same erroneous data if I reset the Central. Both devices are using V6.4. Work around: I discovered that I can fix the problem by sending a BLUEHCI_GAP_DELETE_AD_TYPE command to the Peripheral, with the parameter set to AD_TYPE_FLAGS, before sending the BLUEHCI_GAP_SET_UNDIRECTED_CONNECTABLE command. Then the Peripheral behaves as (2) above.