- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Tags:
- ble scan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirm that by changing from wiced_bt_ble_scan to wiced_bt_ble_observe I can now see my beacons! Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found this thread:
https://community.broadcom.com/thread/1211?q=ind%20adv
Is IND ADV scanning supported and tested ?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same issue with SDK 3.7.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have same issue, this is a problem of BLE API/firmware?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Jacob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jakewtorres wrote:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
CAPTURE_2: nrf beacon, non-connectable device, WICED couldn't got a scan result
CAPTURE_3: nrf beacon, non-connectable device, WICED got a scan result
CAPTURE_4: nrf beacon, non-connectable device, WICED got a scan result
Regards,
Gustavo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sam.lin gcorrente axel.lin br1 pratik
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);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jakewtorres wrote:
Documentation exists in 3.7.0 for this API.
Got it, I found it in wiced_bt_ble.h.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirm that by changing from wiced_bt_ble_scan to wiced_bt_ble_observe I can now see my beacons! Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for confirming br1.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jact wrote:
Thank you for confirming br1.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jact wrote:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have created a new thread for the whitelist issue here: Re: How to scan non-connectable BLE devices ? (con't - whitelist)