Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3301952
  • 博文数量: 406
  • 博客积分: 10227
  • 博客等级: 上将
  • 技术积分: 9807
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-17 21:48
个人简介

非淡泊无以明志,非宁静无以致远

文章存档

2020年(2)

2019年(5)

2018年(4)

2017年(3)

2016年(24)

2015年(8)

2014年(7)

2013年(3)

2012年(1)

2011年(23)

2010年(179)

2009年(147)

分类: Android平台

2016-05-06 10:43:38

1. 蓝牙设备的发现和同步简介:

蓝牙设备在建立连接以前,通过在固定的一个频段内选择跳频频率或由被查询的设备地址决定,迅速交换握手信息时间和地址,快速取得设备的时间和频率同步。建立连接后,设备双方根据信道跳变序列改变频率,使跳频频率呈现随机特性。

蓝牙系统定义了种工作状态下的跳频序列寻呼、寻呼响应、查询、查询响应 和信道 跳变序列, 不同状态下的跳频序列产生策略不同。

蓝牙定义了32个频点为一个频段, 划分为79个子频段, 工作的频段及跳频顺序取决于所输入的蓝牙主控设备时钟CLK 和主控设备地址的最低28比特有效位, 即BD_ADDR[0…27]或者28比特通用查询接入码(General Inquiry Access Code,GIAC).

1)查询/查询扫描状态:

蓝牙设备通过查询来寻找在其周围邻近的设备,查询设备每隔312.5微秒选择一个新的频率来发送查询,被查询设备每隔1.28s选择一次新的监听频率。查询和被查询设备使用通用查询接入码(GIAC,General Inquiry Acess Code)LAP(Low Address Part),作为查询地址,GIAP LAP为0x9E8B33. 蓝牙标准规定不允许任何蓝牙设备使用和GIAP  LAP一样的地址。产生的32个查询跳变序列(Inquiring  hopping  sequence) 均匀分布在79个频率信道上。

2)寻呼/寻呼扫描状态:

蓝牙设备通过寻呼来呼叫其它的设备加入其所在的微微网,寻呼设备每隔312.5微秒选择一个新的频率来发送寻呼,在寻呼扫描时,被寻呼设备每隔1.28s选择一个新的监听频率。寻呼和被寻呼设备使用被寻呼设备地址(BT_ADDR)的低28个比特,产生的寻呼跳变序列(paging –hopping  sequence)是一个定义明确的周期序列,它的各个频点均匀分布在2.4G的79个频率信道上.

3)连接状态:

在当前状态下, 蓝牙通信设备双方每隔625微秒改变一个频率,使用主设备地址的最低28位有效位, 产生的信道跳变序列(Channel hopping sequence)周期非常长,而且79跳变序列在任何的一小段时间内都是接近均匀分布的。

2. 蓝牙状态转换图:


上图是蓝牙状态转换图,从图中可以看出STANDBY状体是蓝牙设备的默认状态。此模式下设备处于低功耗状态。

Page这个子状态就是我们通常称为的连接(寻呼),进行连接/激活对应的slave的操作我们就称为page。它是指:发起连接的设备(主设备)知道要连接设备的地址。所以可以直接传呼。(想想传呼机,要知道号码才行)。

Page scan这个子状态是和page对应的,它就是等待被page的slave所处的状态,换句话说,若想被page到,我们就要处于page scan的状态。

inquiry这就是我们通常所说的扫描状态,这个状态的设备就是去扫描周围的设备。它是不知道周围有什么设备,要去查询(调查),类似于广播(吆喝)。处于Inquiry Scan的设备可以回应这个查询。再经过必要的协商之后,它们就可以进行连接了。

此处需要说明的是:Inquiry之后,不需要进入Page就可以连接上设备。

inquiry scan这就是我们通常看到的可被发现的设备。体现在上层就是我们在android系统中点击设备可被周围什么发现,那设备就处于这样的状态。

slave response这个就是在page的过程中,slave收到了master的page msg,它会回应对应的page response msg,同时自己就进入到了slave response的状态。

master responsemaster收到slave response的msg后,他就会进入到master response的状态,同时他会发送一个FHS的packet。

inquiry response就是在inquiry scan的设备在收到inquiry的msg后,就会发送inquiry response的msg,在这之后它就会进入到了inquiry response的状态了。

以上的各种状态可以总结到下面的寻呼过程中:即寻呼过程按照如下步骤进行:

1) 一个设备(源)寻呼另外一个设备(目的),此时处于寻呼状态。(Page state)

2) 目的设备接收到该寻呼,此时处于寻呼扫描状态。(Page Scan state)

3) 目的设备发送对源设备的回复,此时处于子设备响应状态。(Slave Response state)

4) 源设备发送FHS包到目的设备,此时处于主设备响应状态。(Master Response state。)

5) 目的设备发送第二个回复给源设备,此时处于子设备响应状态(Slave Response state。)

6) 目的和源设备切换并采用源信道的参数,此时处于主设备响应状态和子设备响应状态。
    3. 各种状态间的转换:

standby->inquiry当一个设备需要去扫描周围是否有别的设备的时候,就会从standby转变到inquiry的状态。到了这个状态之后,他就会重复地发送inquiry的msg,inquiry msg并没有标明任何和source相关的信息,但是它可能包含哪一类的设备应当响应这个msg。处于inquiry scan的设备,就可以响应inquiry的msg了,但是spec中说并不是所有处于inquiry scan的设备都必须响应inquiry的msg。所以,还是有一定的自主权的。

在inquiry状态的设备会收到被搜索到的设备发回的response,需要注意的是inquiry状态的设备并不需要对这个response做出任何形式的回应。因为一段时间内进行inquiry的频点范围是有限的,若想搜索到所有频点的设备,需要保证inquiry的最短时间是10.24s。这一点是尤为重要的,这也是为什么我们通常看到一些设备如Android他的搜索时间都是设为10.24s,就是这个原因。

inquiry->connection: 在搜索到一个设备之后,就可以根据搜索到的信息进行连接该设备,从而进入到connection的状态。

inquiry->standby: 若是不进行连接或者没有搜索到任何设备,在一定时间之后,仍然会回复到standby的状体。

connection->inquiry: 和standy->inquiry比较类似,唯一的差别在于standby到inquiry可以集中全部的能力去进行inquiry,而connection到inquiry则因为有别的事情需要做,需要做一些善后的工作,比如把ACL link置到sniff状态,若是有SCO或者ESCO,则会比inquiry的优先级更高,先保证SCO或者ESCO的传输,在空隙时间才能进行inquiry。

standby->inquiry scan: 若是一个设备想被发现,则会进入到inquiry scan的状态。在此状态若是收到inquiry的msg就可以进行回应了。

inquiry scan->inquiry response在收到inquiry的msg后,就可以回应对应的inquiry的msg,从而进入到inquiry response的状态。回应的inquiry response有两种情况,一种就是很单纯地只回应对应的FHS的packet,另外一种就是有EIR(Extended Inquiry Result) data。是否有EIR data是FHS中的一个标志位来决定的。

inquiry response->inquiry scan: 这有两种情况,一种是我们下面要去和master建立连接从而进入到connection状态,必须要经过inquiry scan状态后才行,而不是直接就进入到connection状态。另外一种就是回到原来的standby状态,同样的,我们仍然要经过这个inquiry scan的状态。

inquiry scan->connection: 这个和inquiry到connection状态是类似,就不多说了。

connection->inquiry scan: 这个状态的变化和standy->inquiry scan是类似的,也不多说了。

standy->page scan: 若是一个设备想被page到则需要进入到page scan状态。

page scan->slave response: 在收到page的msg后,page scan的设备就会发送对应的response msg,然后进入到slave response的状态。

slave response->connection: 在第一次回应response之后,master和slave的交互并没有完全结束。他们仍然还有别的msg的交互,在master收到slave的response之后,他会发送对应的FHS packet过来,这个时候slave response状态的设备需要再次回复一个response。在master收到这第二个response的时候,他会发送一个poll的packet下来,从这个时间点开始,slave正式进入到connection的状态(step5)。具体可以参见下面图



slave response->page scan: 这个就是上面这个过程出问题了,就会回到pagescan的状态。

page scan->connection: 需要注意这不是一个正常的流程,它发生在connection->pagescan后page失败,他就会返回到connection状态,而不是从standy->page scan->connection。和page scan到standy类似。

page scan->standby: page失败,返回之前的standby状态。

connection->page scan: 和standy到page scan类似。

standy/connection->page: 若想page到一个设备,就需要进入到page的状态。

page->standy/connection: 同样的page失败回复对应的初始状态。

page->master response: 在收到slave的response之后,就回应对应的FHSpacket,从而进入到master response的状态。

master response->connection: 和slaveresponse到connection是同步类似的,不详细解释。

master response->page: 同样的是在上面出问题了,就回到page的状态了。

connection->standby: 个就是断开连接了,建立连接要走很多中间步骤,断开连接就没有这么麻烦了,直接搞定。当然理论上还是需要通过reset或者detach命令进行的。


阅读(13359) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~