TI中文支持网
TI专业的中文技术问题搜集分享网站

如何发现ANCS服务,发现ANCS服务的过程是怎样的?怎么知道成功发现了ANCS服务?

最近,一直在研究ANCS,参考的例程是:http://processors.wiki.ti.com/index.php/Cc2640_ANCS_Sample#Demo_guide

我研究的是:如何在2640实现发现ANCS的服务。

但是对发现ANCS服务的过程,感觉理解的不够透彻。

我的问题是:

如何发现ANCS服务,发现ANCS服务的过程是怎样的?怎么知道成功发现了ANCS服务?

以下是我对发现ANCS服务的一些理解:

      外围设备作为GATT client,需要发现ios设备的ANCS服务(service)和特征值(characteristics),这一步就是由ancs_discovery.c 文件中的Ancs_discover函数实现。Ancs_discover利用特定状态值来发现ANCS服务(特定状态值见附录一),来函数会发现ANCS的服务和3个特征值(三个特征值具体见附录二),并且保存句柄。

     Ancs_discover函数的框架如下:

static uint8_t Ancs_discover(uint8_t state, gattMsgEvent_t *pMsg)
{uint8_t newState = state;static uint8_t isNotifCCCD = FALSE;switch (state){case DISC_ANCS_START: :case DISC_ANCS_SVC: :case DISC_ANCS_CHAR: :switch (uuid){case ANCS_NOTIF_SRC_CHAR_UUID:Ancs_handleCache[HDL_ANCS_NTF_NOTIF_START] = handle;Ancs_endHdlIdx = HDL_ANCS_NTF_NOTIF_END;LCD_WRITE_STRING("Found: Ntfi char", LCD_PAGE1);break;case ANCS_CTRL_PT_CHAR_UUID:LCD_WRITE_STRING("Found: Ctrl pt char", LCD_PAGE2);break;case ANCS_DATA_SRC_CHAR_UUID:Ancs_handleCache[HDL_ANCS_DATA_SRC_START] = handle;Ancs_endHdlIdx = HDL_ANCS_DATA_SRC_END;LCD_WRITE_STRING("Found: data src char", LCD_PAGE3);break;default:break;} :case DISC_ANCS_CCCD: :
} 

 

======================================================================

附录一:

// ANCS discovery states
enum
{DISC_IDLE = 0x00,// Idle stateDISC_ANCS_START = 0x10,// ANCS serviceDISC_ANCS_SVC,// Discover serviceDISC_ANCS_CHAR,// Discover all characteristicsDISC_ANCS_CCCD,// Discover ANCS CCCDDISC_FAILED = 0xFF// Discovery failed
};

附录二:

ANCS Service Characteristics:

● Notification Source: UUID: 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)  基本通知源,通知一些计数的信息● Control Point:UUID: 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)控制器,用于向ios设备写入控制信息,例如读取详情● Data Source:UUID: 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)  数据源,用于提供详细数据,在控制信息写入后通过此characteristic返回
kqian0327:

你好,

回答你的问题之前,我们先搞清楚ANCS源头,本质上是CC2640作为客户端发现IOS系统上的服务,然后订阅服务,读取参数的过程!

苹果通知中心(Apple Notification Center Service, ANCS)的目的是提供给蓝牙外设一种简单、方便的获取ios设备通知信息的方式。

 

依赖

ANCS的使用没有依赖,它是GATT的一个子集,任何一个实现了GATT client的设备可以方便的从ios设备获取通知信息。

 

传输注意事项

如果没有特殊说明,通过ANCS传输的数值均使用小端模式。

如果没有特殊说明,通过ANCS传输的字符串均使用UTF-8编码。

 

概念定义

l  ANCS:苹果通知中心服务

l  NP(Notification Provider):通知的产生者,一般是ios设备

l  NC(Notification Consumer):通知的消费者,一般是蓝牙设备

l  iOS notification:ios设备里出现的通知

l  GATT notification:GATT characteristic发送的通知

 

Service定义

ANCS使用了一个私有UUID作为其Service的UUID:

7905F431-B5CE-4E99-A40F-4B1E122D00D0

 

NP上只有一个ANCS实例,基于ios的机制,ANCS没有办法保证一直运行。

所以NC需要搜索并且监听(subscribe)Service Changed characteristic,以保证能够坚挺到所有通知。

(怎么做。。。。Service Changed characteristic是啥)

 

Characteristic类型

所涉及的characteristic

 1、Notification Source:

   UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD(notifiable)

   基本通知源,通知一些计数的信息;

  

 2、Control Point:

   UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9(writeablewithresponse)

   控制器,用于向ios设备写入控制信息,例如读取详情;

 

 3、Data Source:

   UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB(notifiable)

   数据源,用于提供详细数据,在控制信息写入后通过此characteristic返回;

 

还有许多其他characteristic,不过只有Notification Source是强制的,其他的都是可选的。

 

Notification Source

通知信息更新时,从NP发给NC的消息。

有以下一些情况:

l  新的ios通知到来;

l  ios通知有改动;

l  ios通知移除;

  

 

l  EventID:消息类型,添加(0)、修改(1)、删除(2);

l  EventFlags:消息优先级,静默(1)、重要(2);

l  CategoryID:消息类型;

l  CategoryCount:消息计数;

l  NotificationUID:通知ID,可以通过此ID获取详情;

 

Notification的生命周期如下:

  

 

Get Notification Attributes

当NC希望从NP读取Notification的详细信息时,它需要向Control Point characteristic发送一些命令,格式如下:

 

l  CommandID:设为0;

l  NotificationUID:对应Notification Source中相同名字的字段;

l  AttributeIDs:NC希望读取的变量ID列表,有些变量可能需要跟一个16bit的数说明想要的最大长度;

 

NP接收到此命令后,会通过Data Source characteristic将结果返回(通过GATT Notification),所以你需要监听这个参数。此命令发出后对应的返回信息如下:

  

l  CommandID:为0;

l  NotificationUID:对应之前请求的UID;

l  AttributeList:查询结果列表,每一项的格式都是:ID/16bit  Length/Value,每个attribute都是一个字符串,其长度由Length指定,但是此字符串不是以NULL结尾。若找不到对应的Attribute,则Length为0;

 

* 如果返回的消息长度大于GATT最大传输长度(MTU),则其会被分割成多个分段。蓝牙设备必须将这些分段组装起来。当所有请求属性的内容都接收完成后,此过程才算完成;

 

Get App Attributes

此命令允许NC读取NP上安装app的特定属性,它需要向Control Point characteristic发送一些命令,格式如下:

  

l  CommandID:设成1;

l  AppIdentifier:App ID,这个字符串必须使用NULL结尾(“\0”吧);

l  AttributeIDs:希望获得属性的列表;

 

此命令的响应消息格式如下:

 

l  CommandID:为1;

l  AppIdentifier:App ID,与之前的请求ID对应;

l  AttributeList:属性值列表,每一个格式都是:ID/16-bit Length/Value,每个attribute都是一个字符串,其长度由Length指定,但是此字符串不是以NULL结尾。若找不到对应的Attribute,则Length为0;

 

* 关于分段以及传输结束的判断标准,与Get Notification Attributes一致;

 

Session(会话)

ANCS session 在NC订阅Notification Source之后开始,在取消订阅或者连接断开之后结束。由于ANCS不是一个完全同步的服务,它不会在会话中记录状态。所以,所有的NotificationUID以及AppIdentifier仅在某个特定的会话周期内有效。(换句话说,那些ID只是在会话后开始的计数,下次再连接重新计数)

当某个会话结束时,NC需要清空所有ID以及数据内容。当新的会话开始时,NP会尽量把现有的通知都发给NC。NC可以使用这些信息知道当前尚未处理的通知有哪些。

 

Attribute Fetching and Caching

我们建议,只在用户做出操作时才获取attribute。例如,一开始只是展示一个通知列表,然后在用户点击某一个后才查询详细的信息。

 

另外,我们建议在一次会话中建立一张App attribute的缓存表,这样可以避免重复获取一些常量attribute。

 

Error Codes

写入Control Point characteristic时,可能会有错误发生,错误码定义如下(在哪里返回错误码。。。同一次请求中么):

0xA0 : 未知命令,commandID非法;

0xA1 : 无效命令,命令的格式错误;

0xA2 : 无效参数,某一个参数(例如NotificationID无效)

 

如果有错误发生,就不会有Data Source返回。

 

时序图

下面展示了NP与NC之间的常见交互时序:

 

 

下面的图展示了获取详细信息的时序:

 

 

 

CategoryID

  

 

EventID

  

 

EventFlags

 

 

CommandID

  

 

NotificationAttributeID

 

 

 

 

AppAttributeID

 

 

实际实验之DataSource读取

主要是介绍一下读取的各个AttrID返回的都是啥:

电话:

AttrID

返回值

0(App ID)

com.apple.mobilephone

1(Title)

1 (326) 021-3971(电话号码,不过划分方式好怪。。。)

如果此号码存了名字,则是电话本中的名字

2(SubTitle)

如果此号码存了名字,则是mobile

3(Message)

Incoming Call

 

短信:

AttrID

返回值

0(App ID)

com.apple.MoileSMS

1(Title)

10698109555991

01051726663

+86 132-6021-3971

如果此号码存了名字,则是电话本中的名字

2(SubTitle)

3(Message)

短信的内容

 

微信:

AttrID

返回值

0(App ID)

com.tencent.xin

1(Title)

微信

2(SubTitle)

3(Message)

发信人:内容

 

其他应用的ID:

QQ:c o m . t e n c e n t . m q q

365:c o m . 3 6 5 r i l i . C o c o

Any.Do:c o m . a n y d o . A n y D O

系统提示:c o m . a p p l e . r e m i n d e r s

赞(0)
未经允许不得转载:TI中文支持网 » 如何发现ANCS服务,发现ANCS服务的过程是怎样的?怎么知道成功发现了ANCS服务?
分享到: 更多 (0)