ble

BLE scan 在bluedroid的实现中，有两个接口：一个是discovery，一个是ble observe，这两者有什么区别呢？ 这里追了一下代码发现，inquiry 是上层调用search 相关的接口的实现函数，ble observe 是调用GATT scan的接口的实现函数，这篇文章分析一下，在调用GATT 接口实现scan的流程。 GATT的服务代码逻辑在哪里实现的呢？其核心代码的实现是bluedroid里面，但是，上层的应用是不可能直接调用协议栈的代码的，其实在bluedroid上面还会进行封装一个GATT的服务，其实现在package/app/Bluetooth下面的GattService.java，这里面实现了关于GATT相关的各种接口，应用层的代码通过binder 调用绑定到这些接口，并完成一系列的调用。 看一下GattService.java的实现： /** * Handlers for incoming service calls */ private static class BluetoothGattBinder extends IBluetoothGatt.Stub implements IProfileServiceBinder { private GattService mService; public BluetoothGattBinder

今天是最后一个工作日，又是一年的结束 上次年终总结的目标： 1。 英语。 2。 Azure Cloud 3。BLE 4。图像识别(护照OCR) 1，2，都没有去完成，基本上完全放弃了。因为中途来了一个项目，实在是时间紧的不得了。 3，4 基本算完成。 陆陆续续花了好多天的时间去了解了BLE的原理，但是今天回忆一下，好像都忘记了 :( opencv 看完了里面的tutorial，感觉对这个有比较多的了解。 对于护照的OCR，找到了一个例子，基本上完完全全满足需求，所以就不做了 :D 中途做了一个小例子: 答题卡上有很多的选项，要查看考生选择（涂黑）了哪个，首先需要知道每个选项的区域，然后再来判断区域是否被涂黑了。 通过opencv的一些处理，现在可以基本上准确的把所有的选项都标出来，如下图，所有的ABCD项都用红框标出来了 今年最大的改变还是换了一份工作，另外完成了一个项目 自己不太能预计到还会换工作，以前感觉会在公司待到退休（劝退）。不过，当机会来的时候，还是兴奋的。也可能是对当时公司里的工作，已经满满的无奈！ 另外一个是完成了一个项目，意义重大！ 明年目标： 英语 Flutter ----END---- 来源： CSDN 作者： Ani 链接： https://blog.csdn.net/Ani/article/details/104068863

​本文涉及如下问题： 如何建立连接 如何提高传输速率 异常时如何快速断开连接 如何跳频 BLE data的PDU如何展开分析 初始化连接是在广播通道上建立的，参考 BLE：广播channel上的PDU分析，本文将重点介绍BLE连接 1. 连接建立 当设备收接收到可以连接的广播(ADV_IND或者ADV_DIRECT_IND)后，则可以发起建立连接请求，连接请求数据包是通过发送CONNECT_REQ的PDU来实现的，CONNECT_REQ的PDU如下所示 2 连接参数 建立连接后，两个设备会在相等的连接间隔之间交换数据，每一次的数据交换称之为连接事件（connectionevent），数据的发送和接收都是通过连接事件完成的，在连接事件之外，BLE设备处于休眠状态，因此进一步降低了功耗。 广播的设备以一定的广播间隔周期性的广播数据，类似的，设备建立连接后，两个设备会以相等的时间间隔交换数据，这个间隔成为连接间隔（Connectioninterval）。 LL Data中参数解释： 1. AA：AccessAddress，链路层的接入地址，参考3.2中介绍； 2. CRCInit：初始化CRC的值； 3. 和发送数据窗口相关的参数：WinSize和WinOffset 4. 连接参数： Interval： Connection interval = sleep + connection

因为flash空间限制，可以酌情缩减一些东西。 减少音频文件支持： 删除或者压缩提示音文件，在tone_resource文件夹，修改download.bat 关闭ble功能 # define BLE_BREDR_MODE (BT_BREDR_EN /*|BT_BLE_EN*/ ) //资源问题，开了ble，不能开启一拖二 关闭打印 # define __DEBUG 关闭蓝牙后台 # define BT_BACKGROUND_EN 1 来源： CSDN 作者： yunThinker 链接： https://blog.csdn.net/dear5240/article/details/103990738

Friend直接流程建立都是通过上层传输曾的控制PDU进行交互。控制消息大部分都为不分段消息，所以这一章我们以下层传输层的为分段消息作为PDU格式的总体示意图。 1. Friendship相关Control PDU 1.1. Friend Poll 由LPN发起，请求Friend发送LPN睡眠期间为LPN存储的消息。 Opcode=0x01，对应的Parameters如下所示： Field Size(bits) Notes Padding 7 0b0000000，固定值 FSN 1 Friend Sequence Number TTL域设置为0。 消息使用 friendship security credentials加密。 1.2. Friend Update Friend通知LPN安全参数已经改变，或者当前消息队列为空。 Opcode=0x02，对应的Parameters如下所示： Field Size(octets) Notes Flags 1 第0个bit表示当前的Key Refresh阶段 第1个bit表示当前的IV Update状态 第2-7位RFU IV Index 4 Friend节点当前的IV Index MD 1 MD=0：表明Friend Queue为空 MD=1：表明Friend Queue非空 Field Notes Key Refresh Flag 0

低功耗休眠模式： 1 转自： https://blog.csdn.net/sinat_23338865/article/details/83790023 睡眠代码：app_default_sleep_mode ＝ ARCH_EXT_SLEEP_ON;arch_set_sleep_mode(app_default_sleep_mode);user_s ​​睡眠代码： app_default_sleep_mode = ARCH_EXT_SLEEP_ON; arch_set_sleep_mode(app_default_sleep_mode); user_scheduler_reinit(); 1、DA14580在睡眠之前需要将app_default_sleep_mode定义为相应的睡眠模式； 2、调用arch_set_sleep_mode()使设备进入睡眠模式； 唤醒代码： if (GetBits16(SYS_STAT_REG, PER_IS_DOWN)) { periph_init(); } app_default_sleep_mode = ARCH_SLEEP_OFF; arch_set_sleep_mode(app_default_sleep_mode); arch_ble_force_wakeup(); app_easy_wakeup(); a、唤醒外设 b、关闭睡眠模式 c

下层传输层主要负责数据的分段与重组。下层传输层接收上层传输层的Access消息和Control消息。 1. 分段消息（Segmented Msg） 1.1. 分段接入层消息（Segmented Access Message） 分段接入层消息（ 5-16字节 ）的每个分段的结构如下： Field Size(bits) Notes SEG 1 SEG=1，表示当前消息是分段消息 AKF 1 AKF=1，表示使用Appkey加密；AKF=0，表示使用DevKey加密，AID=0b000000 AID 6 AppKey ID，当AKF= 1时有效 SZMIC 1 TtansMIC的大小。SZMIC=0，表示TransMIC为4字节；SZMIC=1，表示TransMIC为8字节 SeqZero 13 SeqAuth 的最低13位有效位 SegO 5 表示当前分段位第几个分段 SegN 5 表示此条消息总共有多少分段 Segment m 8-96 此分段的消息内容，只有最后一个分段的size才小于96 SeqN为5bit，说明最大支持32个分段，每个分段满载的payload为12字节，所以Upper Transport Layer下发的消息包括TransMIC最大为32*12=384字节。 对于同一条消息的不同分段，只有SegN和Segment m不同。 SeqAuth是第一个分段的IV

SDK15.3 不同于 HOLYIOT 项目的做法，这次使用的是 nordic 官方的扫描过滤器 首先扫描初始化（如若有多个过滤条件则需修改参数 NRF_BLE_SCAN_UUID_CNT、NRF_BLE_SCAN_NAME_CNT、NRF_BLE_SCAN_SHORT_NAME_CNT、NRF_BLE_SCAN_ADDRESS_CNT、NRF_BLE_SCAN_APPEARANCE_CNT）： static char const m_target_periph_name[] = "Nordic_UART"; /**< Name of the device to try to connect to. This name is searched for in the scanning report data. */ /**@brief NUS UUID. */ static ble_uuid_t const m_nus_uuid = { .uuid = BLE_UUID_NUS_SERVICE, .type = NUS_SERVICE_UUID_TYPE }; static uint8_t m_target_periph_addr[6] = {0x60, 0xFD, 0x35, 0xB0, 0x4A, 0xD4}; static uint8_t m_target_periph

蓝牙和WiFi已经占据所有主设备这端的标准，蓝牙生态的体量比其他的同类协议大了好几个数量级。而且各厂商之间的互联互通、兼容性各方面都比较成熟。 从Bluetooth SIG今年发布的 Bluetooth Market Update 报告来看，蓝牙的成员社区还在扩容，2018年社区已有加入的企业将近35000家，近5年增长70%。2019年预计蓝牙设备出货量达到40亿，2018-2023预期复合年增长率在8%左右。在已经出货的设备中，1/3为BLE单模设备；预计到2023年BLE设备年出货量会达到16亿，包含BLE技术的设备将占到所有蓝牙设备的90%。 在更具体的市场类别中，发展趋势相对偏中游的智能家居设备领域，到2023年100%的智能音箱会包含蓝牙；未来5年蓝牙智能家电的总体出货量复合年增长率会达到59%，其中所有蓝牙相关的住宅照明设备年出货量到2023年会达到2018年的4.5倍。值得一提的是智能家居并非蓝牙市场中增幅最大的市场。 上海巨微独创的BLE射频前端的芯片是在巨微自主研发的BLE基带和协议栈基础上，精简开发的一系列性价比极高的射频芯片。该系列芯片可以与市面上绝大多数MCU芯片配合，完成BLE数据传输功能。是广泛的MCU公司的无线好帮手。上海巨微的BLE-Beacon专用芯片是业内独有的专用功能芯片，具有最小的封装、最少的外围电路、最简易和灵活的系统应用。

蓝牙和WiFi已经占据所有主设备这端的标准，蓝牙生态的体量比其他的同类协议大了好几个数量级。而且各厂商之间的互联互通、兼容性各方面都比较成熟。 从Bluetooth SIG今年发布的 Bluetooth Market Update 报告来看，蓝牙的成员社区还在扩容，2018年社区已有加入的企业将近35000家，近5年增长70%。2019年预计蓝牙设备出货量达到40亿，2018-2023预期复合年增长率在8%左右。在已经出货的设备中，1/3为BLE单模设备；预计到2023年BLE设备年出货量会达到16亿，包含BLE技术的设备将占到所有蓝牙设备的90%。 在更具体的市场类别中，发展趋势相对偏中游的智能家居设备领域，到2023年100%的智能音箱会包含蓝牙；未来5年蓝牙智能家电的总体出货量复合年增长率会达到59%，其中所有蓝牙相关的住宅照明设备年出货量到2023年会达到2018年的4.5倍。值得一提的是智能家居并非蓝牙市场中增幅最大的市场。 上海巨微独创的BLE射频前端的芯片是在巨微自主研发的BLE基带和协议栈基础上，精简开发的一系列性价比极高的射频芯片。该系列芯片可以与市面上绝大多数MCU芯片配合，完成BLE数据传输功能。是广泛的MCU公司的无线好帮手。上海巨微的BLE-Beacon专用芯片是业内独有的专用功能芯片，具有最小的封装、最少的外围电路、最简易和灵活的系统应用。