- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
When implement
void ble_scan_results_cb( wiced_bt_ble_scan_results_t* p_scan_result, uint8_t* p_adv_data )
for API wiced_bt_ble_observe( WICED_TRUE, 30, ble_scan_results_cb )
The p_adv_data carries full packet of data ( without size info, please add size info in API to make life easier)
If p_scan_result->ble_evt_type is BTM_BLE_EVT_CONNECTABLE_ADVERTISEMENT, p_adv_data carries advertisement data, that's fine.
But if p_scan_result->ble_evt_type is BTM_BLE_EVT_SCAN_RSP (for same device), p_adv_data carries advertisement with scan response data concatenated.
Is there a boundary info to separate scan response data from the whole bunch of data ?
It's really hard to do this.
- Labels:
-
Wifi+Bluetooth
- Tags:
- ble
- ble scan response
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is some log:
address:cc b9 7e 73 61 a4 rssi:-48 bdaddrtype:1 event_type:0
App Scan payload -32 (17) [0201050D0953657269616C494F20424C45]
==> BTM_BLE_EVT_CONNECTABLE_ADVERTISEMENT
address:cc b9 7e 73 61 a4 rssi:-46 bdaddrtype:1 event_type:4
[App] Scan payload -46 (39) [0201050D0953657269616C494F20424C4503030A181107F74F3A0B960541B1594D66D6010092BA]
==> BTM_BLE_EVT_SCAN_RSP
This is from same device, in BTM_BLE_EVT_CONNECTABLE_ADVERTISEMENT case
the payload is [0201050D0953657269616C494F20424C45] (17 bytes), thie is ADV data
in BTM_BLE_EVT_SCAN_RSP case
the payload becomes [0201050D0953657269616C494F20424C4503030A181107F74F3A0B960541B1594D66D6010092BA] (34 bytes),
this is ADV data concatenated with Scan Response data.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi axel.lin
wiced_bt_ble_observe api gives you non connectable advertisements (i.e Beacons) , The first byte of advertisement data is length , this is as per the BT specification [volume 3 , part C : Advertisement and Scan response format ]
The structure wiced_bt_ble_scan_results_t has a field named named ble_evt_type which inturn tells you if the data received is SCAN_RSP
Can you send me the application logs where you see ADV data and scan data being concatenated , most peripherals fill the same data as ADV and Scan RSP
Regards
Prejith
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi prejith,
That's not quite true about the length.
Here is an diagram about eh advertising data
https://docs.mbed.com/docs/ble-intros/en/master/Advanced/Images/GAP/GeneralStruct.png
advertising data is a byte array which contains multiple AD structure, the first byte of AD structure only indicates length of the AD structure instead of total advertising data.
for example:
address:cc b9 7e 73 61 a4 rssi:-48 bdaddrtype:1 event_type:0
App Scan payload -32 (17) [0201050D0953657269616C494F20424C45]
The advertising data is [0201050D0953657269616C494F20424C45] this is what p_adv_data point to.
It contains 2 AD structures:
020105
0D0953657269616C494F20424C45
The first byte 02 only indicate the first AD structure length.
To get total length of the payload (17 bytes) you need to parse traversal every AD structure and sum them up.
If the parsing or the payload is wrong, you might end up with segfault.
I think better and safer API should provide the length of the payload.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sam
Regarding ADV data you are right , peripherals fill different AD structures and its a variable length , to parse the advertising data you can use the below api
/**
*
* Function wiced_bt_ble_check_advertising_data
*
* Parse advertising data (returned from scan results callback #wiced_bt_ble_scan_result_cback_t).
* Look for specified advertisement data type.
*
* @param[in] p_adv : pointer to advertisement data
* @param[in] type : advertisement data type to look for
* @param[out] p_length : length of advertisement data (if found)
*
* @return pointer to start of requested advertisement data (if found). NULL if requested data type not found.
*
*/
uint8_t *wiced_bt_ble_check_advertising_data( uint8_t *p_adv, wiced_bt_ble_advert_type_t type, uint8_t *p_length);
Regarding scan response : You are right wiced stack concatenates all the active scan data and passes it to the application , however if you are interested to check any AD type you can use the above api's on the complete concatenated advertisement data
Regarding your question relating to length : Can you let us know why would you need the length , usually the scanner knows the kind of data it is expecting (for example , service UUID , name etc etc ) , and the above api should be able to help you get the same.
Regards
Prejith
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi prejith,
For our case we relays raw payload to remote site so we may not really care about content.
With length info we can do memory copy directly without payload traversal.
Regards,
Sam