How to scan non-connectable BLE devices ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I use such call

wiced_bt_ble_scan( BTM_BLE_SCAN_TYPE_HIGH_DUTY, WICED_FALSE, ble_scan_results_cb );

to scan beacons and print info in callback:

static void ble_scan_results_cb( wiced_bt_ble_scan_results_t* p_scan_result, uint8_t* p_adv_data ) {

    int result;

    WPRINT_APP_INFO(("[App] Scan Result\n"));

    if ( p_scan_result != NULL ) {

        WPRINT_APP_INFO(("[App] address:%x %x %x %x %x %x rssi:%d bdaddrtype:%d event_type:%x\n",

                         p_scan_result->remote_bd_addr[0], p_scan_result->remote_bd_addr[1], p_scan_result->remote_bd_addr[2],

                         p_scan_result->remote_bd_addr[3], p_scan_result->remote_bd_addr[4], p_scan_result->remote_bd_addr[5],

                         p_scan_result->rssi, p_scan_result->ble_addr_type, p_scan_result->ble_evt_type));

    } else {

        WPRINT_APP_INFO(("[App] No results\n"));

        WPRINT_APP_INFO(("[App] scanning again\n"));

    }

}

But I can only get connect-able BLE device advertisment (ble_evt_type 0 and 4) instead of non-connectable BLE devices advertisment (tags, beacons..)

Any idea of possible missing parameter ?

Tested on SDK 3.5.1. 43438 based BT chip.

0 Likes
1 Solution
Anonymous
Not applicable

I confirm that by changing from wiced_bt_ble_scan to wiced_bt_ble_observe I can now see my beacons! Thanks!

View solution in original post

24 Replies
Anonymous
Not applicable

I found this thread:

https://community.broadcom.com/thread/1211?q=ind%20adv

Is IND ADV scanning supported and tested ?

Thanks

0 Likes

I am seeing similar behaviour with Murata Type 1DX BCM4343W module and WICED SDK 3.5.2.

Every time I see only single and same device in scan result.

Am I missing anything.

0 Likes
Anonymous
Not applicable

I have a similar situation (SDK 3.5.2), but I believe it's not the ble_event_type but the AD Flags of the advertisement packet. I can receive ADV_NONCONN_IND (ble_event_type 3) but only if the AD Flags have bit 0 (LE Limited Discoverable Mode) or bit 1 (LE General Discoverable Mode) set. Unfortunately the beacons I want to scan set AD Flags to 0x04 which makes them not visible by WICED. Is there any way to configure or change this?

Anonymous
Not applicable

Same issue with SDK 3.7.0

0 Likes
Anonymous
Not applicable

I have same issue, this is a problem of BLE API/firmware?

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

I am unable to repro this issue using 4343W_AVN on SDK 3.5.2.

What devices are you trying to receive the beacons from?

br1​,

Did you confirm that these bits 0 and 1 of AD Flag are both set to 0 using a sniffer? If this is the case, your device is transmitting in non-discoverable mode and is being purposefully filtered out.

This is per the BLE spec:

pastedImage_0.png

Jacob

Anonymous
Not applicable

Yes, I confirmed the Flag AD type bit 0 (LE Limited Discoverable Mode) and bit 1 (LE General Discoverable Mode) are zero using another system which does not filter them, and also by generating different beacons with different flag settings.

I am trying to discover a BLE Tag EMBC01 | EM Microelectronic which sets these bits to 0. So while it may be correct according to the BLE spec to filter them the problem is that there are commercially available BLE tags out there which set these bits to 0. Other BLE stacks such as bluez (linux), Nordic nRF and btstack do not filter them. Maybe an option to filter or not would be good?

0 Likes

gcorrentepratiksam.lin

     Can you all use sniffers to read what the AD Flags of your beacons are set to? I have no problem receiving non-connectable adv as long as either bit 1 or 0 of AD flag is set to 1. But if neither is set I don't receive them.

br1

     I'm looking further into this. Although the spec wants these advertisements hidden at the UI level, I agree that the firmware should be able to find them. I'm going to try to get engineering involved in this to see if we can provide a fix. If the other users on this thread can confirm that their issue is the same as yours it will help to push the issue forward.

Jacob

jakewtorres wrote:

gcorrente pratik sam.lin

     Can you all use sniffers to read what the AD Flags of your beacons are set to? I have no problem receiving non-connectable adv as long as either bit 1 or 0 of AD flag is set to 1. But if neither is set I don't receive them.

It's totally fine for a beacon/tag type device to set both flags as 0.

WICED SDK cannot find such beacon/tag.

Note, AFAICT all other BT stacks have no problem to find such beacon/tag.

0 Likes

jakewtorres (also) wrote:

[...] I agree that the firmware should be able to find them. I'm going to try to get engineering involved in this to see if we can provide a fix. If the other users on this thread can confirm that their issue is the same as yours it will help to push the issue forward.

I agree, axel.lin​.

0 Likes
Anonymous
Not applicable

Hello,

I think the only problem is that WICED filter the scans by Flag AD type bit 0 (LE Limited Discoverable Mode) and bit 1 (LE General Discoverable Mode), I only got the scan if one of them is 1.

You can check it in the capture

CAPTURE_1: tile device, connectable device, WICED got a scan result

sniff_ble_tile__WICED_OK.jpg

CAPTURE_2: nrf beacon, non-connectable device, WICED couldn't got a scan result

sniff_ble_1_BEACON__WICED_OFF.jpg

CAPTURE_3: nrf beacon, non-connectable device, WICED got a scan result

sniff_ble_2_BEACON__WICED_OK.jpg

CAPTURE_4: nrf beacon, non-connectable device, WICED got a scan result

sniff_ble_3_BEACON__WICED_ON.jpg

Regards,

Gustavo

0 Likes
lock attach
Attachments are accessible only for community members.

sam.lingcorrenteaxel.linbr1pratik

Thank you for confirming gcorrente​. It is very likely that this is the problem everyone on this thread is having.

I was informed that in the latest SDK 3.7.0 there is a fix to the issue. It is a separate API called 'wiced_bt_ble_observe.' Use this in place of wiced_bt_ble_scan to hear non-discoverable adv.

I have attached a sample app which runs in the SDK 3.7.0 and is able to hear all adv whether they tx in non-discoverable, limited discoverable, or general discoverable. Tested on 4343W_AVN SDK 3.7.0.

Jacob

Edit:

This API is also available in earlier SDKs but was never defined in the header files.

To use, extern define in you app:

     extern uint8_t wiced_bt_ble_observe (BOOLEAN start, UINT8 duration, wiced_bt_ble_scan_result_cback_t *p_scan_result_cback);

To use, extern define in you app:

     extern uint8_t wiced_bt_ble_observe (BOOLEAN start, UINT8 duration, wiced_bt_ble_scan_result_cback_t *p_scan_result_cback);

You should add this to a proper header file with documentation since it's a public API now.

axel.lin

Documentation exists in 3.7.0 for this API.

Jacob

0 Likes

jakewtorres wrote:

axel.lin

Documentation exists in 3.7.0 for this API.

Got it, I found it in wiced_bt_ble.h.

Thanks.

0 Likes
Anonymous
Not applicable

I confirm that by changing from wiced_bt_ble_scan to wiced_bt_ble_observe I can now see my beacons! Thanks!

Jacob, how can i use the code you posted? I try to open it on modus toolbox but the ide can't open it. I'm trying to do some similar (find ble devices not connecteds) with the cybt-213043-mesh kit. It's possible? You know how?

0 Likes
Anonymous
Not applicable

Hello,

wiced_bt_ble_observe it works for scanning all type of beacons.

Problems: this function is good for sniffing.

I think that what we need the for scanning is wiced_bt_ble_scan scanning all devices,

with the scan_interval, scan_windows, withlist parameters and with new parameter like beacon lifeTime

(is to don't repeate the same beacon  in consecutive scans).

BR,

Gustavo

0 Likes

Thank you for confirming br1​.

gcorrente​,

I completely agree that you should have the ability to set interval, window, active/passive, etc.

I'm still discussing this with engineering to figure out why so much control was removed in the wiced_bt_ble_observe function and if there is a way we can work around it to expose the functionality. I will keep you updated.

Jacob

0 Likes

jact wrote:

Thank you for confirming br1.

gcorrente,

I completely agree that you should have the ability to set interval, window, active/passive, etc.

I'm still discussing this with engineering to figure out why so much control was removed in the wiced_bt_ble_observe function and if there is a way we can work around it to expose the functionality. I will keep you updated.

Jacob

jact

There is no improvement regarding gcorrente  's comment for wiced_bt_ble_observe() API these years.

The API remains the same in the latest sdk.

0 Likes
lock attach
Attachments are accessible only for community members.

gcorrente

I just produced a patch to allow you to configure your scan params--accessed the transport layer to jump over the pre-defined configurations in the observe function.

Put the attached .h into your app folder, #include it, and use the API 'wiced_bt_ble_observe_patch.' Documentation is limited to what I jotted down near the function definition. Please let me know if you have questions.

This allows you to hear all non-discoverable, limited disc, and general discoverable, and to configure the scan parameters: interval, window, duration, whitelist, active/passive, duplicate filt, etc.

Please let me know if this works for you.

Jacob

jact wrote:

gcorrente

I just produced a patch to allow you to configure your scan params--accessed the transport layer to jump over the pre-defined configurations in the observe function.

Put the attached .h into your app folder, #include it, and use the API 'wiced_bt_ble_observe_patch.' Documentation is limited to what I jotted down near the function definition. Please let me know if you have questions.

This allows you to hear all non-discoverable, limited disc, and general discoverable, and to configure the scan parameters: interval, window, duration, whitelist, active/passive, duplicate filt, etc.

Please let me know if this works for you.

Jacob

When only wiced_bt_ble_observe() is called, what is the default settings for the addr_type? (the addr_type in btsnd_hcic_ble_set_scan_params())

i.e if btsnd_hcic_ble_set_scan_params() is not called, which addr_type setting is scanned by wiced_bt_ble_observe()?

I thought it should scan *all* types by default rather than specific type. (i.e. including public addr and ramdom addr)

But the btsnd_hcic_ble_set_scan_params() API seems needs to set only one addr_type.

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

To clarify for anyone reading the thread, this whitelist issue brought up by gcorrente​​ manifests itself anytime the whitelist is used in any scan. It's not related to the provided patch.

gcorrente​,

Let's move the whitelist issue to another thread since it seems to be separate from the original question. I'll be testing the whitelist on my end soon.

Jacob

I have created a new thread for the whitelist issue here: Re: How to scan non-connectable BLE devices ? (con't - whitelist)

0 Likes