有人可以帮助我尝试解决复杂问题吗?我还不完全熟悉iPhone硬件和操作系统和设备之间的细微差别(我被告知这种影响比Android更少) .
哦,如果我应该在别的地方发布这样的问题,请在喊我之前说
背景
过去几周我一直在学习swift和iPhone硬件 . 我是Android开发人员,我们的BLE应用程序在Android 4上运行良好 . 然而,我们的iOS应用程序在一小部分手机上运行不佳(不幸的是我们很多客户的公司测试人员使用的手机) . 除了SOME 5S之外,它在我们尝试过的每部手机上工作正常(相关组件) .
我购买了5S来测试这个,经过几天的尝试,经过多次尝试,无法再创造它,一切都对我有用 . 与此相反,我们的一些测试人员报告说,它根本没有为他们工作过 . 我们的第一个测试人员借给我他的设备,我肯定会重新创造一些会导致我们遇到问题的东西,但是我无法在我的5S上重新创建它 . 他还有另一个5S,并且无法在那部手机上重新创建它,这在同一时间既好又坏 . 实际上,老实说,它似乎只是涂在黑色上的那些(我知道......)
我们的应用程序听公共汽车上的信标 . 我们支持Android 4和iOS 9 .
“破碎”状态:
-
使用我们的UUID开始测量区域
-
发现没有信标,或者只发现来自非常有限集的信标继续返回所有仅使用BLE的应用的有限或空范围结果(注意到BT扫描仪似乎得到设备,可能是因为它发生了's not a BLE scan that')
-
重置设备,再试一次
-
检测到所有/大多数信标
-
最终会回到破碎状态,这可能在测距循环期间发生,也可能在您启动一个状态时发生 .
首先,我们认为我们的应用程序没有点击,因为我们将每辆公共汽车的4个信标混合在一起,并且没有公共汽车出现 . [我们只需偶尔点击其中一个来说你没有做室内定位或任何事情 . 其他手机和操作系统一切都很好(iOS和[实际上效果更好] Android)]
我后来在我的诊断应用程序中注意到,实际上有些信标被检测到,但不是“正确的”,因为一个无关的错误(我们的代码)仍然,问题仍然是找不到其他信标,设备似乎既可以显示所有信标,也可以显示一些相当小但一致的信标子集 .
最初,我们认为这是我们承包商的代码 . 然后我们认为这是Apple . 现在我们认为我们的代码与容易出现故障的硬件(即两者)相互作用很差 .
我能够使用样板测距代码重现 . 我不相信这是一个实际问题,直到我弄脏了 - 我已经和BLE一起工作了大约3年 . 我们与Apple签订了TSI,他们接受了它并退还了我们的TSI信用 . 几个星期后我们没有听到任何消息,尽管我们收集了他们想要的数据 .
我觉得很奇怪
看起来好像适配器以某种方式将自己锁定到特定区域,但是没有意义:
-
a)大部分区别是相当一致的偏见 - 因为我看到当所有信标距离我大约5米时,非常相似的专业出现(我的测试应用程序中也没有区域代码,除了我们的UUID的初始区域)例如,当我开始输入时,我出现了10000-10010,11001-1104,12001-12020,现在我似乎只能看到12020,10000,100001和11003.我总是看到12020和10001个专业出现当它处于“损坏”状态时 - 大约150个信标都是相同的型号,相同的UUID,相同的广播间隔等,相同的固件(虽然有一些例外,但它偏向的信标是旧的和更新的固件和实际上它们中的一些也是不同的模型,但这只意味着它不是导致它的信标 . - 这些是例外,它是我们的旧信号被检测到,一些较新的信标最初只有相同的标识符
-
b)这会影响其他应用程序 - 当然一个应用程序不应该能够严重破坏系统蓝牙适配器(特别是在如此彻底部署的设备中) .
-
c)有时它实际上需要两次重新启动才能解决问题,但是如果BT适配器崩溃,它肯定不会花三次 - 它应该是第一次重启吗?除非他们有一些用户友好'你obvs不需要硬重启你愚蠢的用户朋友:)'苹果的东西..意味着它没有正确重启第一次 . 这个问题似乎是由于适配器没有正确删除其区域引起的,因为这意味着我不必重新启动设备以再次检测到信标,并重新启动蓝牙现在对它进行排序 . 此外,实际上进入后台再次关闭检测,但不完全,似乎有限
-
d)没有容易辨别的“点”它会破坏 - 你可能拥有所有的信标,然后你就像一个或三个,总是来自同一组专业(就像它说其余的都不是ibeacons而是这一个) ) - 暗示它在某个地方摔倒,不知怎的,是的,一旦我们进入后台(即锁定屏幕,而不是改变应用程序),然后再回到前面 . 这是可靠的可重复的
-
e)这适用于iPhone 5,其他iPhone 5S以及之后的所有内容 . 我认为Apple的东西是跨设备的一致性
如何 Build 有关设备差异的更多信息?
我可以重新创建的设备是在iOS的最新版本以及我不能的版本 . 可以归咎于我们可以影响的因素很少 - 我们可以提出的唯一解释是这个硬件与其他5S(每次都有效)不同 - 并且具有不同的芯片组或它的独特之处在于它打破了我们的代码,适用于其他设备 .
Apple告诉我们没有已知的解决方法 - 但我得到的印象是他们实际上并不确定是什么问题 .
我可以在这里提供更具体的信息,我只是觉得我应该在周末之前在这里呕吐,以防万一有人看到它并且听起来很熟悉(那个人会成为英雄)
工作装置和非工作装置都具有型号:A1457和ME434B / A(着色和序列号是我未经训练的眼睛唯一可辨别的区别)
更新:4周后 -
我们现在决定让人们重新测试 . 我们认为我们拥有的设备可能是一次性的 . 我们被告知有人在为Apple收集数据时重新创建了它,但经过仔细检查,这是一个不同的问题 .
在与Kontakt谈论为什么他们的Beacon / ToughBeacons将在他们的Beacon Pros之前被选中之后,我遇到了(正确)混乱 - 他们期望Beacon Pros能够/更多/兼容 . 我们的一个理论是它们已被设备作为外围设备接收,因为它们使用非BLE BT广播Kontakt安全配置文件(尽管根据Kontakt它应该被视为不同的设备,这是有道理的,但仍然,非职业选手不会这样做并被选中) - 意味着他们被选为外围设备,然后在BLE检测期间可能被忽略 . 很难说,有很多因素,我们认为这个设备是循环或损坏的 .
在与Radius讨论解决问题的操作之后 - 他们并不真正知道他们在做什么,因为没有什么特别之处 . 他们的一个开发人员通过他认为相关的一部分代码与我交谈,但与我在自己的诊断应用程序中尝试的内容相比,这并不是什么新鲜事 . 我确实发现我们的应用程序没有很好地清理范围,但我在联系Radius或Kontakt之前解决了这个问题 - 这影响了我们认为重新创建与问题设备相同问题的设备,但是我的一些代码诊断应用程序修复它 .
所以这基本上被搁置,直到Apple决定他们可以修复它 .
这是一个图表,显示“好”(红色)5S和“坏”(蓝色)之间的差异,因为它们移动到背景中 . 蓝色只是在前景中拾取不是信标专业人员的信标,然后在背景中像红色一样:
更新 - 几个月后
哦,我见过的东西..!
我们现在已经过了这个,我们并没有放弃iOS,所以我想我会分享一些东西,一个间接的技巧和更多的观察 . 我最终会更新并回答它并让它变得有意义
间接技巧 - 在iPhone 5S上,我们只能拿起retrobeacons的“坏状态”由Radius Networks过滤器配置更改修复 . 实际发生的是更新它是在与我所处的区域无关的区域重新启动监控 . 我发现在0000-0000区域内监控...(等 - 全0)--000000000000同时也适用于我们的UUID实际上大大改善了我们得到的范围 . 在使用Radius应用程序时,最明显的就是为我修复它 . Apple确实会告诉你监视,直到你找到一个灯塔,然后是范围,但是我们没有像那样工作,他们从未暗示过这一点 . 因此,如果您发现iPhone没有获得范围结果,请尝试并行监控,让我知道您所看到的内容 .
更多观察 -
之前,我们注意到从背景到前景对测距有影响,我们也看到坐在点亮的静止锁定屏幕上,但没有在任何地方滑动 - 只需点击屏幕使其保持活动状态 - 将导致陷入困境 . 如果您只是打印出测距结果并试试这个,你会明白我的意思 .
我们也注意到了飞机模式启用确实也有帮助,但这显然没用,但对我们认为存在问题的5S产生了巨大影响 .
实际上,我们的问题一直是(尽管我们不知道)iOS只是内部处理BLE的方式不同 . 似乎有更多的平均值和更多的范围结果处理 - 有一些恼人的效果,特别是当信心似乎很低时“坏”命中 .
SE不是5S机身的iPhone 6 . 它实际上更像是带有6个处理器的5S . 我们的一位客户对我们这么说,我们只是把它看作是面值,所以当他们从5S上升到SE时,再次假设这是我们代码中的一个错误,而不是一些硬件问题 .
糟糕的点击率
几个月前,我们开始进行一些正式的实证测试,并更加关注结果 . 我们没有得到像我想要的频谱分析仪,但遗憾的是我们并不需要它 . 我认为最重要的部分之一就是重新访问iPhone上的“糟糕点击”概念,并试图了解它们的含义 . 在我们注意到两件事之前不久:
-
iPhone的RSSI一直较低,如果android有-70,它可能有-80(使用我们的默认信标),
-
iPhone不能很好地处理较低的RSSI .
从我们制作的图表中,我们可以看到在<= - 90dBm标记附近开始出现不良命中 . 在此之后,我们看到点击率为0dBm或根本没有点击,而Android会说-100,-110等 . 这个阈值要么是硬件或软件,要么是内部策略 . 我们在Swift 3/4和iOS 9到11.0.3以及多个手机之间看到了类似的结果 . 最引人注目的趋势是,更昂贵的iPhone往往比它们下面的型号有更好的性能 .
这是有道理的,但这一切都表明,BLE战略受到一些内部政策的约束,该政策强制执行“坏”命中的报告 . 这对我们来说实际上是完全正常的,但是当我们需要时,我们不能没有点击,特别是当我们同时在Android上报告-80dBm时 . 正是这样的证据最终使我们得出结论,如果我们以某种方式将iPhone上的RSSI提高了大约10dBm,那么我们将会变得更好 .
我们最近刚刚升级了我们部署的信标,从那时起我们就看到了积极的结果 . 我们正在使用Kontakt信标,我们将其从Tx上升到-12dBm到4dBm,这为我们看到的RSSI(测试中)增加了10到20 dBm . 电池会受到打击,但我们真的不在乎 . 我们担心泄漏,但它现在并没有真正打扰我们,当我们到达那里时,我们将跨越那座桥梁 .
我们还将广播间隔从350增加到100.我们在测试中注意到这也有助于减轻“坏”命中 - 我们假设这是因为设备有更多来自扫描的数据来做出关于RSSI的假设 .
下图显示了升级和未升级信标之间的良好比较 .
在右边,我们看到了多个测试的概要(当我们升级时,我们做了一些测试,看它是否正常工作)颜色是设备,蓝色是iPhone 7,红色/绿色是华为P9和一些索尼手机 .
在左边的图表中,设备由节点的形状表示,iPhone是圆圈 . 着色与个别信标有关 . 用户将一次大约4个信标,除了任何短暂的视图
我们在左图上显示了两个独立的扫描周期实例,第一个是未升级的信标(在此图中,设备是形状,iPhone是圆形) . 请注意,这个绿松石组中顶部有很多“坏”命中,并且它们全部来自设备附近的信标(橙色命中来自Android设备,因此三角形和Xs)
第二个是升级后的信标,我们非常清楚地提高了RSSI值 . 我们也几乎消除了“糟糕”的点击 - 右边唯一的点击来自不在设备周围的信标,只是短暂地进入视野 - 这是公平的,它们也会比附近更远 . 最后有一个小口袋,但这与测试结束时的用户移动有关 .
您会注意到在两个图表中我们都没有看到任何iPhone命中率低于-100dBm,并且似乎有些不愿意准确地报告<= - 90dBm,而Android无论如何都很开心 . 这在右图中尤其明显,您可以从右图的其余部分看到这不是边缘情况 .
所以,尽管我讨厌这个,我们基本上通过喊叫解决了这个问题 . 在某些时候,我将把这个问题重构为一个关于Android和iOS BLE的比较,并“回答”最终导致我解决这个问题的事情 .
结束
让我强调一点,在我们离开那个“糟糕的状态”问题,并意识到我们过于密切关注5S之后,大约85-90%的测试完全没有问题,并且对设备性能印象深刻 .
然而,Android是100%,整个调查基本上都是为了解释这个差异,因为客户对苹果产品的信心似乎将Apple排除在“为什么这不起作用?”的等式中,这可能会让你陷入困境,特别是如果贵公司没有这类项目的经验 .
蓝牙非常具有气质,任何涉及蓝牙的应用程序都应该首先构建为没有信标的工作,然后应该使用信标来使用户感觉他们通过他们的设备连接到周围的东西 .
你应该做的其他事情是不断尝试不同类型的信标,我们坚持我们的制造商,因为我们提前购买了这么多 . 不是最好的主意,但他们的信标是一流的,质量很好,他们的工具也是如此,它们的配置方式也很重要(retrobeacons vs beacon pros) .
此外 - 每个应用程序开发人员都知道这一点,但我不适用于应用程序公司,所以我不能只访问所有设备 - 永远不要让一个设备代表整个家庭 - 我们在5S上遇到了问题并做了假设结果,我们浪费了大约3个月的间接方式,并使用其他传感器使我们的应用程序看起来像是在5S / SE上工作 . 我们现在已经删除了大约99%的代码,我们感到非常高兴 . 特别是因为5S / SE目前不到市场总量的15%左右 .
从最响亮的信标和最好的接收设备开始,然后向下工作,而不是试图选择一个起点并继续前进 .
这对我来说是一次很棒的体验,但是如果我在为公司工作的第一个BLE项目时发生过这种情况,那么我完全已经接受了JavaEE的工作并且再也没有回到BLE!这仍然是一堆乱七八糟的词语,但希望有人能从中得到一些有用的东西,正如我所说的3x,我会重构!