一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种对多个智能穿戴设备进行数据采集的方法和设备与流程

2021-11-20 00:46:00 来源:中国专利 TAG:


1.本技术涉及智能穿戴设备技术领域,特别涉及一种对多个智能穿戴设备进行数据采集的方法和设备。


背景技术:

2.智能穿戴设备(手表、手环等)同一时间只能与一部智能终端(例如:手机、平板电脑等)配对使用,即:智能穿戴设备与手机配对后,只有在手机或穿戴设备上手动选择解除配对、连接新设备,或者与手机的蓝牙连接丢失时,新的手机才能通过蓝牙查找到该智能穿戴设备并发起配对,且必须由用户在智能穿戴设备侧手动确认,才能与新手机配对成功。
3.当要求多个中心设备就近采集几十上百个智能穿戴设备的数据时,需要在众多智能穿戴设备上一一手动确认配对,才能与邻近的中心设备建立连接并采集数据。如果中心设备需要在用户无感知的状态完成数据采集,现有技术无法满足该需求。
4.另外,蓝牙协议支持一个主设备连接多个从设备,但数目有限。目前的各类android设备能同时连接的蓝牙从设备个数,包括经典蓝牙和ble蓝牙设备,总数一般不大于7个。
5.当使用场景是多台中心设备就近从几十上百个智能穿戴设备采集信息时,中心设备需要采集多人的智能穿戴设备数据,而人数达到十几人甚至几十人时,一个中心设备无法连接这么多人的设备。
6.然而,现有消费类终端没有连接超过十几个设备的诉求,协议和芯片软硬件设计都没有达到这样的能力,现有技术无法满足多台中心设备就近从几十上百个智能穿戴设备采集信息的应用场景的需求。


技术实现要素:

7.本技术提供了一种对多个智能穿戴设备进行数据采集的方法和设备,以解决多台中心设备就近从多个智能穿戴设备采集信息的问题。
8.本技术公开了一种对多个智能穿戴设备进行数据采集的方法,包括:
9.对特定的中心设备的蓝牙设备类型进行扩展,将所述中心设备的次类型修改为自定义的预设类型;
10.智能穿戴设备收到蓝牙配对请求后,识别发出配对请求的设备的设备类型;
11.如果发出配对请求的设备是所述自定义的预设类型,则与所述发出配对请求的设备进行自动配对;
12.否则,按照标准流程,提示所述智能穿戴设备的用户进行手动确认配对。
13.较佳的,该方法还包括:
14.收集用户身份和智能穿戴设备的蓝牙mac地址的信息,并对用户身份与智能穿戴设备进行绑定。
15.较佳的,由各个中心设备进行所述收集和绑定,并将用户身份与智能穿戴设备的
绑定信息上传到云平台,所述云平台再将用户身份与智能穿戴设备的绑定信息广播到各个中心设备。
16.较佳的,在智能穿戴设备下发前进行用户身份与智能穿戴设备的绑定,并将绑定信息录入到云平台,然后将智能穿戴设备下发给对应的用户,并由云平台将用户身份与智能穿戴设备的绑定信息广播到各个中心设备。
17.较佳的,该方法还包括:
18.各个中心设备在设定时间采用轮询的方式向待采集数据的智能穿戴设备发起蓝牙连接请求;
19.如果连接成功则采集数据,如果连接超时,则继续轮询连接下一个待采集数据的智能穿戴设备。
20.较佳的,该方法还包括:
21.所述中心设备将采集的数据上报到云平台。
22.较佳的,该方法还包括:
23.所述云平台记录智能穿戴设备当天是否已经被采集过数据;
24.中心设备与智能穿戴设备建立连接后,先向云平台查询所述智能穿戴设备是否已被其他中心设备采集过数据,如果采集过,则当天不再对所述智能穿戴设备采集数据;如果没有采集过,则对所述智能穿戴设备进行数据采集。
25.本技术还公开了一种智能穿戴设备,包括:处理器和通信模块;其中:
26.所述通信模块用于接收蓝牙配对请求;
27.所述处理器用于识别发出所述蓝牙配对请求的设备的设备类型;
28.如果发出配对请求的设备是所述自定义的预设类型,则控制所述通信模块与所述发出配对请求的设备进行自动配对;否则,按照标准流程,提示所述智能穿戴设备的用户进行手动确认配对。
29.由上述技术方案可见,本技术提供的技术方案通过对中心设备的蓝牙设备类型进行扩展,将中心设备的次类型修改为自定义的预设类型;并改进智能穿戴设备的gap流程,在智能穿戴设备收到蓝牙配对请求后,对发出配对请求的设备的设备类型进行识别;如果发出配对请求的设备是自定义的预设类型,则表明该设备是可信任的设备,与该设备进行自动配对;否则,按照标准流程,提示智能穿戴设备的用户进行手动确认配对。从而解决了现有技术在配对时必须由众多智能穿戴设备一一手动确认配对,才能与中心设备建立连接的问题,满足了中心设备需要在用户无感知的状态完成数据采集的需求。
30.在上述方案的基础上,为解决蓝牙连接数限制的问题,本技术进一步提出:各个中心设备在设定时间采用轮询的方式向待采集数据的智能穿戴设备发起蓝牙连接请求;如果连接成功则采集数据,如果连接超时,则继续轮询连接下一个待采集数据的智能穿戴设备。如此,使得一个中心设备可以自动分时连接多台智能穿戴设备,从而解决了蓝牙连接数限制的问题。
31.此外,本技术通过收集用户身份和智能穿戴设备的蓝牙mac地址的信息,并对用户身份与智能穿戴设备进行绑定,并将绑定信息上传到云平台,然后由云平台将用户身份与智能穿戴设备进行绑定信息下发到个中心设备,能够在各中心设备之间共享智能穿戴设备的硬件信息,从而便于各中心设备与各智能穿戴设备之间进行交叉配对,以便实现各个中
心设备可就近对各智能穿戴设备进行数据采集。
附图说明
32.图1为本技术对多个智能穿戴设备进行数据采集的方法流程示意图;
33.图2为本技术较佳实施例的数据采集应用场景示意图;
34.图3为本技术较佳实施例典型数据采集流程示意图。
具体实施方式
35.为使本技术的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本技术作进一步详细说明。
36.要解决现有技术所存在的问题需要解决以下技术问题:
37.1、如何允许中心设备自动连接,又能保证其他不相关的蓝牙设备无法配对。
38.2、经典蓝牙协议对异步无连接链路(acl:asynchronous connectionless link)的定义是3bit,即最多支持7路并发。如何使中心设备通过蓝牙技术采集到几十上百个智能穿戴设备的数据。
39.3、ble的时分处理在设备过多时会造成时隙管理出错,丢包断连等,如何解决该技术问题。
40.本技术的主要思想是:一方面,对蓝牙协议进行扩展,扩展中心设备的蓝牙设备类型,例如:中心设备的主类型(major_class)是0x01,即pc类别,将中心设备的次类型(minor_class)修改为自定义的预设类型,比如0x5a;另一方面,修改现有通用访问规范(gap:generic access profile)流程,智能穿戴设备接收到蓝牙配对请求后,识别设备类型,如果是自定义的预设类型,则自动配对;如果是其他设备,则按照标准流程,需要用户手动确认才能完成配对。
41.另外,为保护用户数据的安全性,在软件层面设计接入合法性鉴权机制,只有在智能穿戴设备与中心设备双向鉴权通过时,中心设备才可以对智能穿戴设备进行数据采集。
42.基于上述主要思想,本技术提出一种对多个智能穿戴设备进行数据采集的方法,如图1所示,包括以下步骤:
43.步骤101:对特定的中心设备的蓝牙设备类型进行扩展,将特定的中心设备的次类型修改为自定义的预设类型。
44.步骤102:智能穿戴设备收到蓝牙配对请求后,识别发出配对请求的设备的设备类型;
45.步骤103:对设备类型进行判断,如果发出配对请求的设备是自定义的预设类型,则执行步骤104,与所述发出配对请求的设备进行自动配对;否则,执行步骤105,按照标准流程,提示所智能穿戴设备的用户进行手动确认配对。
46.在上述方法的基础上,可以进一步包括:预先收集用户身份和智能穿戴设备的蓝牙mac地址的信息,并对用户身份与智能穿戴设备进行绑定。
47.一种较佳的进行信息收集与绑定的方法为:由各个中心设备进行所述收集和绑定,并将用户身份与智能穿戴设备的绑定信息上传到云平台,再由云平台将用户身份与智能穿戴设备的绑定信息广播到各个中心设备。
48.另一种进行信息收集与绑定的方法为:在智能穿戴设备下发前进行用户身份与智能穿戴设备的绑定,并将绑定信息录入到云平台,然后将智能穿戴设备下发给对应的用户,并由云平台将用户身份与智能穿戴设备的绑定信息广播到各个中心设备。
49.较佳的,各个中心设备可以在设定时间采用轮询的方式向待采集数据的智能穿戴设备发起蓝牙连接请求;如果连接成功则采集数据,如果连接超时,则继续轮询连接下一个待采集数据的智能穿戴设备。如此,使得一个中心设备可以自动分时连接多台智能穿戴设备,从而解决了蓝牙连接数限制的问题。
50.中心设备采集到数据后上报到云平台,由云平台记录智能穿戴设备当天是否已经被采集过数据;中心设备与智能穿戴设备建立连接后,先向云平台查询所述智能穿戴设备是否已被其他中心设备采集过数据,如果采集过,则当天不再对所述智能穿戴设备采集数据;如果没有采集过,则对所述智能穿戴设备进行数据采集。从而可以避免重复进行数据采集。
51.对应于上述方法,本技术还公开了一种智能穿戴设备,该智能穿戴设备至少包括:处理器和通信模块;其中:
52.所述通信模块用于接收蓝牙配对请求;
53.所述处理器用于识别发出所述蓝牙配对请求的设备的设备类型;
54.如果发出配对请求的设备是所述自定义的预设类型,则控制所述通信模块与所述发出配对请求的设备进行自动配对;否则,按照标准流程,提示所述智能穿戴设备的用户进行手动确认配对。
55.下面通过一个较佳实施例对本技术技术方案进行举例说明。
56.本实施例以军队为例,如图2所示,数据采集的基本场景是班长的平板电脑(pad)作为中心设备对接本班10位士兵的智能手表/手环。平板电脑采集数据后通过通信网络加密回传,上传到健康云平台,从而使健康云平台获取到所有士兵的健康数据。从实际应用场景考虑,在临时组队执行任务或士兵调整所在班等情况下,希望不需要过多的操作,最好是免操作,士兵的数据就可以被就近的班长的pad采集。即:要求pad与智能手表/手环能够交叉配对,可实现多对多自动连接。
57.下面从以下几个方面对本实施例进行介绍:
58.一、士兵身份和智能手表/手环信息管理
59.本实施例预先完成士兵身份信息和智能手表/手环的蓝牙mac地址的收集,并下发到所有班长的pad。
60.本实施例提供以下两种较佳的信息收集方式:
61.方案一:由班长在pad上完成本班士兵的智能手环配对,并在数据采集app上将智能手环与士兵身份绑定。数据采集app通过云侧转发,将士兵身份和智能手环的绑定信息广播到其他班长的pad。
62.方案二:由指定机关在智能手环下发前完成全连士兵身份与智能手环的绑定,然后将智能手环下发给指定士兵。士兵身份和智能手环的信息通过云侧录入并下发到所有班长的pad上的数据采集app。
63.二、pad和智能手表/手环配对
64.扩展蓝牙协议,通过修改蓝牙接入协议gap,使智能手表/手环实现:
65.当识别出定制pad发起的连接请求时,无需手动确认、自动静默连接该定制pad;
66.当识别出民用手机/pad发起的连接请求时,沿用民用手表/手环的gap流程,需要用户手动确认连接。
67.各班长的pad夜间自动发起蓝牙连接请求进行数据采集,轮询全连手环,逐个发起连接请求。连接成功则采集数据,连接超时则继续尝试连接下一个手环。从而使得各班长的pad能够采集到所有需要采集的士兵的数据,解决现有技术蓝牙协议连接数限制的问题。
68.三、采集数据处理
69.由于每个班长的pad都会发起全连士兵手环的采集,存在一个手环被多次采集的可能,需对采集数据进行处理,本实施例提供以下两种较佳方案进行处理:
70.方案一:各pad上不进行数据去重处理,而是将采集到的数据都上报到云侧,由健康分析平台完成手环数据的去重处理。
71.方案二:云侧记录智能手表/手环当天是否已经被采集过数据。某pad与某一手表/手环建立连接后,先到云侧查询该手环是否已被其他pad采集过数据,如采集过则当天无需再次采集。
72.本实施例通过对士兵身份和手环信息进行绑定集中管理,并改造蓝牙协议,使得所有班长的pad可以与所有士兵的智能手表/手环配对,并在指定时间段自动完成数据采集。
73.本实施例一个典型的数据采集流程如图3所示,包括以下步骤:
74.第1步:云平台下发数据库到数据采集app,使数据采集app获取到全连士兵与手环的绑定关系数据库。
75.第2步:运行于pad的数据采集app向pad发送连接指定手表/手环的指令。
76.第3步:pad向指定的手表/手环发起扩展蓝牙连接请求。
77.第4步:手表/手环判断连接请求是否来自定制pad,如果是来自定制pad,则向pad返回连接成功消息。
78.第5步:pad与手表/手环连接成功后,向数据采集app通知手环连接成功。
79.第6步:数据采集app向云平台询问今日是否采集过指定手表/手环的数据。
80.第7步:云平台向数据采集app返回采集状态应答。
81.第8步:数据采集app根据云平台的采集状态应答确定是否采集某手表/手环的数据,如果决定采集,则进行第9步。
82.第9步:数据采集app向pad发出发起采集的指令。
83.第10步:pad通过蓝牙连接与手表/手环进行数据同步。
84.第11步:pad向数据采集app返回数据采集应答。
85.第12步:数据采集app向云平台进行数据回传。
86.第13步:云平台进行数据清洗,分析呈现等后续数据应用处理。
87.以上所述仅为本技术的较佳实施例而已,并不用以限制本技术,凡在本技术的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本技术保护的范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献