我正在寻求帮助，以了解在使用CoreLocation监控iBeacons时我一直在观察的一些iBeacon可靠性问题。
我有一组具有相同UUID的信标，但主要和次要号码不同。我的程序设置为监视所有程序（不是范围）。我的传输功率在信标的绝对最小值（据称导致5英尺的信标区域半径）。有时它很有效，但我观察到一些不一致的行为，包括：
我对iBeacons人们可能知道的任何最佳实践感兴趣。我观察到的问题似乎源于不可靠的传输范围和波动的信标信号强度。有没有简单的方法来改善这个问题？
我的目标是让几个信标靠近。我应该考虑范围来帮助降低一些可靠性吗？如果是这样，我的理解是你不能在后台设置可靠性。
此外，如果您的应用已经在信标区域内启动，我正在尝试确认您是否会收到并输入活动？
答案 0 :(得分：2)
一般来说，调低信标的发射功率会产生非常不可靠的检测甚至是近距离。这是因为弱信号意味着低信噪比，这导致间歇性故障检测信标作为背景噪声并且几何形状的变化随时间变化。这是导致您描述的进入/退出事件的原因。
另一种方法是最大化信标发射机功率并依靠信标测距来根据估计的距离或原始信号强度（RSSI）滤除远处的信标。 这通常会证明更可靠，因为更强的传输具有更高的信噪比，并且不易受到无线电噪声和其他环境变化的影响。
使用此备选方案的主要挑战是，测距信标受iOS背景限制为每个区域进入/退出10秒，或根据请求延长180秒。如果您请求特殊的位置后台权限，则可以进行无限的后台测距，但这需要特殊的AppStore批准并使用更多的电池。
这适用于您的用例吗？这取决于您要完成的具体内容，以及用户居住在信标附近的频率。您也可以通过以导致进入/退出事件的方式放置信标来对系统进行游戏。
最后，虽然您没有在应用启动时获得区域输入通知，但您可以随时动态请求区域进/出状态，这应该可以满足您的需求。
答案 1 :(得分：1)
作为一个有趣的花絮：上次我们测量它，RSSI阈值高于该阈值时，考虑信标＆＃34;在范围内＆＃34;通过监测是-88 dBm，包括在内。 （即，如果RSSI超过此值，您将获得＆＃34;输入＆＃34;如果它低于此值，则退出＆＃34;退出＆＃34;请记住30秒退出延迟）
对于故障排除练习，您可以开始测量信标并记录RSSI值，并根据您相对于信标的位置检查它们与此阈值的比较。