完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
HI论坛专家,
我使用CYW20706扫描BLE信标,我注意到堆栈提供的RSSI值在93和38之间变化不规则。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=-32。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=-36。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=-33。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=-36。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=90。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=90。 信标〔0〕,ID=1369100000,BATT=0,功率=5,区=88,RSSI=-32。 我用wiced_bt_ble_scan() API,并且在我的wiced_bt_ble_scan_result_cback_t回调投手,我在提供直接的wiced_bt_ble_scan_results_t RSSI现场打印。 这种行为是期望的吗? 谢谢! 以上来自于百度翻译 以下为原文 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! |
|
相关推荐
6个回答
|
|
你好LJ:
你现在的测试环境是什么?对于问题的澄清,最好的测试环境是: 1。用导电天线进行测试,这将对信号有非常精确的结果。 2。如果在空气中测试环境,请用一个反射面积较小的开放区域进行测试。 以上来自于百度翻译 以下为原文 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. |
|
|
|
你好LJ:
实际上,我可以在20706演示中复制这个RSSI问题。并进行了大量的测试,如将高性能ADV设置为从属侧的不定模式。 但只能减少错误值的比率。但找到规则: 1。在用户案例中,错误值总是一个不合理的值,我们可以忽略它。 2。实际的RSSI值如-50,-56,-60,在正常范围内波动。 因此,如果您需要收集RSSI值,请忽略正值,谢谢。 以上来自于百度翻译 以下为原文 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. |
|
|
|
DH9527 发表于 2018-9-18 15:43 嗨,哲, 我们使用RSSI值来估计位置(20706作为一个BELL信标扫描仪),因此放弃信标类型的目的是失败的。 问题: 1)有可能找出最大可能的有效RSSI吗?我想我已经见过25岁了。我要问的是,当扫描仪离源非常近的时候,我只看到正的值(也许无线电在这一点上变得饱和了?)我可以简单地把25以上的东西当作25。 2)你能检查BLE堆栈的源代码,看看是否有任何标志扩展错误(如果我改变第七位的90到1,它变成-38)?如果这是问题,我们可以简单地将它固定在我的应用程序代码中。 3)我们能期待下一个补丁中的bug修复吗?下一个补丁是什么时候? 谢谢! 以上来自于百度翻译 以下为原文 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! |
|
|
|
你好LJ: 很抱歉回复晚了,实际上,我们正在调查这个问题。但确实需要更多的时间来解决问题。 当RSSI将是一个积极的价值,这意味着距离很近,这正是你所描述的。 所以我认为你可以判断距离根据价值捕获的。 以上来自于百度翻译 以下为原文 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.. |
|
|
|
DH9527 发表于 2018-9-18 16:01 嘿,哲, 我们确信这个问题只是一个缺失的符号。我们经常看到序列像- 37,- 37,- 38, 90,- 38,-37, 89,-39…如果我们只加入符号位,它就会变成-37,-37,-38,*-**,-38,-37,*-39 *,-39……,看起来非常合理。 现在我们将在我们的固件中添加比特,我们期待着官方的修复。 谢谢。 以上来自于百度翻译 以下为原文 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. |
|
|
|
胡扯123 发表于 2018-9-18 16:19 此外,作为猜测,我看到了一个定义为0x7f无效的RSSI值。也许在某种程度上,当它想要把它设置成0x7f时,它堆叠着0x7f?只是猜测而已。 以上来自于百度翻译 以下为原文 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. |
|
|
|
只有小组成员才能发言,加入小组>>
752个成员聚集在这个小组
加入小组2086 浏览 1 评论
1837 浏览 1 评论
3652 浏览 1 评论
请问可以直接使用来自FX2LP固件的端点向主机FIFO写入数据吗?
1777 浏览 6 评论
1525 浏览 1 评论
CY8C4025LQI在程序中调用函数,通过示波器观察SCL引脚波形,无法将pin0.4(SCL)下拉是什么原因导致?
532浏览 2评论
CYUSB3065焊接到USB3.0 TYPE-B口的焊接触点就无法使用是什么原因导致的?
387浏览 2评论
CX3连接Camera修改分辨率之后,播放器无法播出camera的画面怎么解决?
421浏览 2评论
368浏览 2评论
使用stm32+cyw43438 wifi驱动whd,WHD驱动固件加载失败的原因?
881浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-4 01:03 , Processed in 1.070946 second(s), Total 86, Slave 69 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号