- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi forum experts,
I'm using CYW20706 to scan for BLE beacons, and I'm noticing the RSSI value provided by the stack changes erratically between +93 and -38.
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=-32
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=-36
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=-33
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=-36
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=90
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=90
Beacon[0], id=1369100000, batt=0, power=5, zone=88, rssi=-32
I use the wiced_bt_ble_scan() API, and in my wiced_bt_ble_scan_result_cback_t callback hander, I'm printing the 'rssi' field in the provided wiced_bt_ble_scan_results_t directly.
Is this behavior expected?
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi LJ:
sorry for reply late, Actually , we are looking into this issue . but really need more time to have a fix.
and When the rssi is going to be a positive value , it means the distance is very close, that is just as you described .
So I think you can judge the distance according the value captured..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi LJ:
what is your test environment now? for the issue clarification, the best test environment is:
1. test with a conductive antenna, this will has a very accurate results about the signal
2. if test the environment on the air, please test it with a open area which has less reflections.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lj:
Actually, I can duplicate this RSSI issue in 20706 demo. and did a lot of tests like setting the high duty adv into indefinite mode in slave side.
but only can reduce the ratio for the wrong value. but find the regular :
1. The wrong value is always a positive value which is not reasonable in user cases, we can ignore it .
2. the actual rssi value like -50 ,-56, -60, fluctuate in a normal range .
so if you need to collect the rssi value , please ignore the positive value , thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi zhez,
We use the RSSI value to estimate location(20706 act as a BLE beacon scanner), so dropping the beacon kind of defeats the purpose.
Questions:
1) Is it possible to find out the max possible valid RSSI? I think I've seen -25. Reason I'm asking is I'm only seeing positive values when the scanner is very very close to the source, (maybe the radio is getting saturated somehow at this point?), and I can simply treat anything above -25 as -25.
2) Could you check the BLE stack source code and see if there is any sign extension bug (If I change 7th bit of 90 to 1, it becomes -38)? If this is the issue we can simply fix it in my app code for now
3) Can we expect a bug fix in the next patch? When is next patch roughly?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi LJ:
sorry for reply late, Actually , we are looking into this issue . but really need more time to have a fix.
and When the rssi is going to be a positive value , it means the distance is very close, that is just as you described .
So I think you can judge the distance according the value captured..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey zhez,
We are pretty convinced that the issue is just a missing sign bit. We often see sequence like -37, -37, -38, 90, -38, -37, 89, -39.... And if we just add the sign bit back in, it becomes -37, -37, -38, *-38*, -38, -37, *-39*, -39...., which looks very reasonable.
For now we are going to add the bit in our firmware and we look forward to an official fix.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also just as a guess, I saw a define for 0x7F as invalid RSSI values. Maybe somehow the stack & it with 0x7F when it wanted to set it to 0x7F? Just a guess.