当前位置:   article > 正文

BLE中篇_ble acl

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的间隔有严格要求

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/192323
推荐阅读
相关标签
  

闽ICP备14008679号