行业动态
iPhone7/plus新增的BLEextension功能有何提升?
2021-02-07

该公司的项目是进行ECG监控并实时收集ECG数据。

该项目基于CoreBluetooth进行封装,并且不使用第三方库。

我以前从未做过蓝牙通信,因此我从头开始学习。幸运的是,IOS开发相对简单,接口包也相对简单实用,但是在此期间,由于设备和高标准的需求,确实遇到了很多挑战,我已经做出了一路突破。

例如当时设备的配对影响了重新连接

ios蓝牙开发_蓝牙ios开发_蓝牙ios开发

最后,我检查了一堆信息,最后这是设备采用的安全机制。因此,我检查了蓝牙底层协议栈,并更好地理解和掌握了蓝牙。虽然它对IOS的发展不是很有帮助,但是对于技术的基础课,进一步的研究和学习,我相信它将对将来有很大的帮助。在学习过程中,我还发现许多从事蓝牙开发的IOS工程师都不了解或不了解蓝牙技术堆栈。因此,据了解,尽管该公司本质上从事蓝牙硬件通信,但是蓝牙的技术储备并没有因为通信速度未达到制造商的最高标准而受宠若惊

这也是一个棘手的问题。我不能从代码级别入手,也不能在IOS上修改ATT_MTU_Size(可以在获取的底部完成,但是我还没有找到如何与从事此工作的许多人进行交流的方法。区域或查询很多信息。要实现),在最终无奈的情况下,电子邮件将我的问题发送回了工厂,然后他说啊啊啊,您的速度已经很正常了……但是波特率最高115200的问题仍然无法解决传输速度不稳定的问题。关于iPhone 7 / plus的新BLE扩展功能的改进蓝牙ios开发,我还没有看到速度的显着变化。简而言之,这件事似乎已经消失了。强大的实时性。保证背景

因为它是用于ECG监测,所以及时性必须是最重要的。当我开始项目时,我不知道要花多长时间。项目完成后,我突然说出了需求,这有点草率。汗流a背,最长的自我测试时间是48h(原始公司只有一个Android项目,据说它最初是外包的,因为它需要做IOS,它是在Android自学之后编写的,当时是蓝牙3.0,因为MFI等被拒绝了。我计划只做BLE4.0,并专门招募了一个IOS),认为它已经达到了最低标准,我松了一口气,项目中数据处理的原始部分出现了内存泄漏。 OTA改善空间

要做蓝牙蓝牙ios开发,我不得不提到OTA,即无线升级功能。一开始就不需要这样做。但是,由于我从事蓝牙开发,因此我在不断学习蓝牙的早期就已经了解了姿势的这一方面。需求下降之后,由于首先需要使硬件适应Android 3.0,所以我只能按照规定的逻辑对代码进行编码。最后,在适应4.0设备之后,我将进行联合调整和优化,因此我已经做好充分的准备,这块被认为是最流畅的,我们的产品升级文件相对较小,一个txt文件约为155KB,我我想在这里提一下,互联网上有很多信息说,如果文件长度超过20Byte,则IOS发送文件将会丢失。 50Byte,70Byte和150Byte已调试。除了50、70Bye的严重丢包率之外,150Byte是最稳定的,这在Internet上没有说过。由于单个数据包的大小为150Byte,因此它将包含在硬件中。指定的协议标头和尾部为8Bytes,因此数据部分为142Bytes,因此原始文件的每个142Byte被分离,协议8Bye被添加以形成150Byte的包。一个完整的升级文件可能会在2min内分成大约1093个程序包,它是在内部完成的,并且根据我的连续测试数十次,将会有数个数据包丢失。这主要与设备OTA流程频繁执行,设备发热等原因有关。基本上,丢包率可以保证为0

蓝牙ios开发_ios蓝牙开发_蓝牙ios开发

随着功能的不断添加,优化和调整,几天前发现了一个重大错误。连接设备后,它将在大约5分钟内断开连接,并且控制台将报告错误消息:

Error Domain = CBErrorDomain 
               Code = 6 "The connection has timed out unexpectedly." 
    UserInfo =  {
                    NSLocalizedDescription =The connection has timed out unexpectedly.
                }


393701618