ble

1、简介 以下蓝牙协议特指低功耗蓝牙协议。 蓝牙协议是由SIG制定并维护的通信协议，蓝牙协议栈是蓝牙协议的具体实现。 各厂商都根据蓝牙协议实现了自己的一套函数库——蓝牙协议栈，所以不同厂商的蓝牙协议栈之间存在差别，但都遵循 SIG 制定的蓝牙协议。 蓝牙技术的实质是建立通用无线接口及其控制软件的标准，使移动通信与计算机网络之间能实现无缝连接。蓝牙通讯最初设计初衷是方便移动电话（手机）与配件之间进行低成本、低功耗无线通信连接。通俗地说，蓝牙最初就是为了替代串口，实现无线串口的功能。 蓝牙4.1就是一个大杂烩：BR/EDR沿用旧的蓝牙规范，LE抄袭802.15.4，AMP直接使用802.11。以上操作的目的是为了提高蓝牙的兼容性和易用性，但是需要在功耗和传输速率之间取得平衡，整体来说，这个设计并不十分优雅，只是存在即合理。 标准号：IEEE 802.15.1 核心：低功耗技术，即Low Energy RF 规格 工作频段：2.4GHz~2.4835GHz，ISM（Industrial，Scientific and Medical）频段； 工作频道：40个频道，每个频道2MHz的间隔，3个广播信道（37-2402MHz，38-2426MHz，39-2480MHz），37个数据信道，广播报文还是数据报文由信道决定； 调制方式：GFSK，调制指数为0.5 中心频率容限：±150kHz 功耗

低功耗蓝牙两类报文 ： 广播报文 和 数据报文。 本文讨论广播报文数据段，不包括完整报文其他部分，比如前导，接入地址等 蓝牙设备通过广播表明自己的存在，等待被连接， 就好象一个人站在接口大喊“我要脱单，我要脱单，快来牵手...”。 BLE 考虑功耗， 使用了3个广播信道，顺序广播。 两个蓝牙设备想要建立连接， 第一步是 从机(server) 向外广播， 主机（client） 搜索到后发起请求。 从机广播中包含设备的相关信息，比如设备名称，设备具有的服务uuid 等。 广播包类型 广播包 （Advertising Data) 响应包 （Scan Response） 主机主动扫描的情况下， 发送扫描请求给从机， 从机返回扫描响应数据。 广播数据包格式 7f223bf9-4d85-4e25-917d-222fb063b540.png 每个包都是 31 字节，数据包中分为有效数据（significant）和无效数据（non-significant）两部分。 有效数据部分 包含若干个广播数据单元，称为 AD Structure 。如图所示，AD Structure 的组成是： 长度 Len ，表示这个 AD Structure 的长度（除去 len本身 1） 类型 AD Type 标记这段广播数据代表什么， 比如设备名， uuid 等。 数据 AD data 无效数据部分 广播包的长度必须是

H5+与BLE填坑之路+uni-app 不好之处请批评指正 缘由 多平台上 BLE 处理之路 简简单单 码码呼呼 挖了什么坑就得想好怎么埋 最后的话语 不好之处请批评指正 首先，这不是我第一次填坑之路，但出于对各平台特性的不了解,造成的坑坑洼洼算是比较惨淡的一次！将近20天，虽然期间也有处理别的事情。最后还是把使用心得以及结果给大家分享下。如有不对之处，欢迎广大网友批评指正，谢谢！ 缘由 老板一句话，刀山火海任我闯。Android、IOS、小程序如此大任加身，奈何奈何！终于，皇天不负有心人，意外发现了uni-app这么个小东西，完全是救命稻草的节奏啊。一键编译，无障碍跨越多平台、终端，好吧！说干就干（毕竟基础在哪，上手还不是分分钟）。然而是我太天真，BUG组队而来。 多平台上 BLE 处理之路 简简单单 Android端： 畅通无阻 + 安卓真好 一股无脑操作，纵你千变万化，也是手到擒来，哈哈哈！高兴了好一阵。 微信小程序端： 方便快捷 + 就是慢了点点 不知道为什么，小程序在连接过程中，乃至整个数据传输过程显示有点慢（较直接APP上而言），也许是因为他是基于程序之上的程序吧。 IOS端： 有点小坑 响应最快 自己不熟悉 因为IOS端与Android端的不同，也因为自己以前从未接触过IOS的开发，导致在这出现了各种问题，什么搜不到设备、连接失败、服务获取失败等等。刚开始也是难受得紧

假设有两个服务，每个服务注册相应事件 注册的事件为ble_dev_cfg_on_ble_evt、ble_lora_cfg_on_ble_evt 当在任何一个服务中发生GATT特征读或写的时候，注册的这两个服务事件都会发生而不是只发生在相应特征项所属的事件 这点在特征项读写权限访问的时候需要注意，因为会在两个服务事件中发生，所以要避免重复回复的问题，否则会导致权限功能异常 void ble_lora_cfg_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context) //发生GATT特性项读写的时候会进入此事件 { ble_lora_cfg_t * p_lora_cfg = (ble_lora_cfg_t *)p_context; switch (p_ble_evt->header.evt_id) { case BLE_GATTS_EVT_WRITE: on_write(p_lora_cfg, p_ble_evt); break; case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST: on_read_write_auth(p_lora_cfg, p_ble_evt); break; default: // No implementation needed. break; } } void ble

1、常规连接过程 在看BLE Connection 0x3E error code之前，我们先来看一下基本的BLE connection initiating过程。 如下图所示： 设备A为BLE连接发起方，B为Advertiser。从上图，大概可以分解出BLE连接的几个步骤： A携带连接设备B的信息，发起连接，开始侦听待B的广播包； 待连接设备B，负责发起广播包； 如果A能在设定设置内，顺利侦听到B的广播包，则会发送一个连接请求包，并且立刻转入连接状态，并且上报给Host连接成功； 随后就是框起来的部分了，A随后会发送一个同步包，需要B回复一个同步包，然后连接才会真正建立，如果这个过程有不发送或不回复现象，都会导致连接失败，这就是0x3E。 2、异常断线0x3E 所以，简言之，0x3E就是连接无法建立或者同步超时，表示LL启动了连接或启动了定期广告的同步，但连接未能建立或链路层无法在6个周期性广告事件中同步包。 表现：在蓝牙主机发起连接过程中，发现会出现“秒断”的现象，即主机连接上从机，然后立马又断开了，断开原因是0x3e。 如下图所示，这就是一个连接失败的例子，原因是B没有回复A的 Data Physical Channel PDUs 3、怎样避免0X3E？ 同步包丢失，一般发生在环境比较复杂时，比如周围存在很多蓝牙设备，导致信道十分拥挤的情况下。 所以