BLE中篇_ble acl

哇。。。。好多UUID呀，好多。。。

     "1800": "Generic Access Profile",
    "1801": "Generic Attribute Profile",
    "1802": "Immediate Alert",
    "1803": "Link Loss",
    "1804": "Tx Power",
    "1805": "Current Time Service",
    "1806": "Reference Time Update Service",
    "1807": "Next DST Change Service",
    "1808": "Glucose",
    "1809": "Health Thermometer",
    "180a": "Device Information",
    "180d": "Heart Rate",
    "180e": "Phone Alert Status Service",
    "180f": "Battery Service",
    "1810": "Blood Pressure",
    "1811": "Alert Notification Service",
    "1812": "Human Interface Device",
    "1813": "Scan Parameters",
    "1814": "Running Speed and Cadence",
    "1815": "Automation IO",
    "1816": "Cycling Speed and Cadence",
。。。

为了搞健康还搞了 专门健康的UUID

Assigned Numbers | Bluetooth® Technology Website

Health Device Profile

总之自己分配的话可以参考Assigned Numbers

BLE用ATT大家同不同意，同意了是吧，那就是了，本来就是。。

目前BLE ACL链路L2CAP上就是ATT，就是这种天天用

在这个附录我们看到了ATT实际实例，对的，BLE 的核心就是 attribute  handle

好比现在有一组标签，我们要实现把 人体的体温  特征添加上去，我们的经常工作就是添加服务，添加特征

1

2

3

4

5

我们不知道1 2 3 4 5 代表是什么含义，怎么使用呢，在BLE上面？？？

我们这5个标签叫作一个服务，比如叫作人体信息 ，然后我们把这个人体信息服务分配一个uuid ，0xFFF0（不是通用的），这个自己写代码的时候，

经常都是先自定义一个服务的UUID，蓝牙联盟兄弟为了简单在00000000-0000-1000-8000-
00805F9B34FB UUID作了简化，直接改其中16BIT就可以了如上面的 第二段

建了人体信息服务之后，标签“简约”就变成这样了（红色的4位就是啦，其实我们协议的实现都用了uuid喔，比如L2CAP,SDP.....）

1    0000FFF0-0000-1000-8000-00805F9B34FB 

2

3

4

5

这个5个标签有了一个标签组了，这个标签组就是“人体信息”  由于这uuid是俺们自己定义的，这个标准的真的差不多用完了

很多兄弟都随机定义128bit了，因为FFF0很快会被别人分配掉。。。。。到时你的产品还用FFF0，到时就显示的不是人体信

息，显示成为人家标准的服务。。。很尴尬

然后就是添加特征了

我们一般添加16位就可以了，特征他妈能有多少，一个服务最多不就那几个特征，关键是服务的uuid才比较多种

比如我随便建个FFF1的特征，我定义为体温

1    0000FFF0-0000-1000-8000-00805F9B34FB 

2    FFF1

3     

4

5

OK ，已经建立好了人体信息服务的UUID 和 特征体温的UUID

再填充一下

1    0000FFF0-0000-1000-8000-00805F9B34FB

2    attribut handle

       Characteristic Properties     

3     Characteristic Value Handle   

        FFF1.....(long)

4    descriptor handle

所有一个特征有三个handle

attribut handle    Characteristic Value Handle    descriptor handle

可以叠加在一个服务上，descriptor handle是比较隐秘的，这个就是对端下命令的handle，直接操作Characteristic Properties

如果，没有建立Characteristic Properties，没有这个handle

特征属性的初始化可以在code上面去设置

OK ，打完收工，你的工作就已经完成了，接下来哥哥带你看看整个通信流程

从connection update indication刚刚好连接之后

第一步：读服务

Opcode    Read By Group Type Request

这一步就是读 attribute   0～ 65536 之间， 存在的服务  ，Group就是服务组的意思

读出来之后发现有各个服务的UUID  比如  1～5 的服务是Generic Access   6～8是Generic Attribute  

还有自己定义的服务 9～14 的0xFFF0

                                                                   

Exchange MTU 就不说了，交换一下每笔数据能发的最大值

第二步：读特征

Opcode    Read By Type Request

 

每个服务都会去读，

比如读到我自定义的uuid

很清楚可以看到 10 ~ 12 是特征FFF1      13 ~ 14 是特征 FFF2

第三步：写特征（打开Notifications  关掉Indications ）

这个地方开始峰回路转了，点睛之笔

你看看他是怎么写的！！！

直接对  12 这个标号进行写  ！！！就是这么直接

再类比上面读到的   10 ~ 12 是特征FFF1 

9    0000FFF0-0000-1000-8000-00805F9B34FB 

10    FFF1

11    Characteristic Value Handle   

12     Characteristic Properties Handle 

13

是不是就有点感觉了。。。。。

第四步：

不断监听到发来的体温数据，至此，可以说流程已经走完

如果遇到体温数据收到是有一部分是乱码，那么请检查一下MTU，在这个范围内去发每一笔比如 23字节或者255字节

我记得蓝牙4.2之前是23字节的

如果遇到connection timeout 请检查一下硬件天线 或者连接间隔，记得ios的间隔有严格要求