BlueZ 做为 linux 标准的协议栈,提供非常多的 profile ,各种的支持,ble , 蓝牙网络,文件传输,a2dp 音频传输. A2DP——Advanced Audio Distribution Profile  A2DP Sink 输入设备,如蓝牙耳机.A2DP Source 输出设备,如手机. 音频压缩格式支持:其中SBC是必须支持的,可选的格式有MPEG-1, MPEG-2, MPEG-4, AAC and ATRC, 另外也支持厂商扩展的格式,比如高质量的音频编码格式apt

各种蓝牙协议的全称: OPP:对象存储规范(Object Push Profile),最为常见的,文件的传输都是使用此协议. HFP:(Hands-free Profile),让蓝牙设备能够控制电话,如接听.挂断.拒接.语音拨号等,拒接.语音拨号要视蓝牙耳机及电话是否支持. HDP: HDP (Health Device Profile) 蓝牙医疗设备模式   能够创建支持蓝牙的医疗设备.使用蓝牙通信的应用程序.比如心率监视器.血液,温度计和秤. A2DP: Advanced Audio Dis

一.从信息的传输说起  上图是一个典型的蓝牙耳机应用场景.手机上的音频信息经过编码以后通过蓝牙协议被蓝牙耳机接收,经过解码以后,蓝牙耳机成功获取手机上的音频信息,然后再转化为振动被人耳识别.这是一个典型的数字通信系统,下面是数字通信系统的一般模型.  信源即需要传输的信息. 信源编码即对信源的编码,目的是为了减少冗余,起到数据压缩的作用,常见的信源编码有Huffman编码.H.264编码等. 信道编码的目的是对抗信道中的噪音和衰减,原理是加入冗余,常见的方法包括CRC校验.卷积码等. 信道即

转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connection)是一个相当消耗资源(power和带宽)的过程.特别是当没有数据传输的时候,所消耗的资源完全被浪费了.因而,对很多蓝牙设备来说(特别是功耗敏感的设备),希望在无数可传的时候,能够断开连接.但是,由于跳频(hopping)以及物理通道(Physical Channel)划分的缘故,经典蓝牙连接

Protocol buffer是Google出品的一种轻便高效的结构化数据存储格式,可对结构化数据进行序列化,并具有语言无关.平台无关等特点,在通信协议和数据存储等领域已经得到广泛的应用.目前其已经提供 C/C++.Java.Python 等语言的 API. 一.Protocol buffer和XML 在数据通信传输时,一般需要将结构化的数据序列化成流进行传送,接收方再反序列化为原始格式数据进行处理.在Web通信领域,XML应用算是最通用的了.在时间性能上,虽然XML的序列化开销还可以,但是反序

源:蓝牙协议 基于TI cc2540 模块的理解 Bluetooth 4.0开发 Platform:TI IC:cc2540 Environment:windows 7 tools:IAR 8.20.2 demo Code:BLE_CC254x_1.4.0 from TI 物理层:是1Mbps自适应跳频GFSK射频,工作于免许可证的2.4GHz ISM(工业.科学与医疗)频段. 链路层:用于控制设备的辐射状态,设备将处于五种状态之一:等待.广告.扫描.初始化.连接.广播设备不需要建立连接 就可以

1. 前言 注1:此SM是Security Manager的缩写,非彼SM,大家不要理解歪了! 书接上文,我们在“蓝牙协议分析(10)_BLE安全机制之LE Encryption”中介绍了BLE安全机制中的终极武器----数据加密.不过使用这把武器有个前提,那就是双方要共同拥有一个加密key(LTK,Long Term Key).这个key至关重要,怎么生成.怎么由通信的双方共享,关系到加密的成败.因此蓝牙协议定义了一系列的复杂机制,用于处理和加密key有关的操作,这就是SM(Security

1. 前言 前面文章介绍了两种BLE的安全机制:白名单[4]和LL privacy[3].说实话,在这危机四伏的年代,这两种“捂着脸讲话(其它人不知道是谁在讲话,因而不能插话.不能假传圣旨,但讲话的内容却听得一清二楚)”的方法,实在是小儿科.对于物联网的应用场景来说,要做到安全,就必须对传输的数据进行加密,这就是LE Encryption要完成的事情(当然,只针对面向连接的数据),具体请参考本文的介绍. 2. 基本概念 从字面理解,Encryption是一个名词,意思是“加密术”,因此LE En

1. 前言 在上一篇文章[1]中,我们介绍了BLE的白名单机制,这是一种通过地址进行简单的访问控制的安全机制.同时我们也提到了,这种安全机制只防君子,不防小人,试想这样一种场景: A设备表示只信任B.C.D设备,因此就把它们的地址加入到了自己的白名单中,表示只愿意和它们沟通.与此同时,E设备对它们的沟通非常感兴趣,但A对自己不信任啊,肿么办? E眼珠子一转,想出一个坏主意:把自己的地址伪装成成B.C.D中任意一个(这个还是很容易办到的,随便扫描一下就得它们的地址了)就行了,嘿嘿嘿! 那么问题来了

1. 前言 在万物联网的时代,安全问题将会受到非常严峻的挑战(相应地,也会获得最大的关注度),因为我们身边的每一个IOT设备,都是一个处于封印状态的天眼,随时都有被开启的危险.想想下面的场景吧: 凌晨2点,x米手环的闹钟意外启动,将你从睡梦中惊醒,然后床头的灯光忽明忽暗…… 你的心率.血压.睡眠质量等信息,默默地被竞争对手收集着,并通过大数据分析你的情绪.健康等,随时准备给你致命一击…… 我知道你家里有几盏灯.几台电器.几个人,知道你几点睡觉几时醒来,知道你一周做过几顿饭,甚至知道你有一个xx棒

1. 前言 大家都知道,相比传统蓝牙,蓝牙低功耗(BLE)最大的突破就是加大了对广播通信(Advertising)的支持和利用.关于广播通信,通过“玩转BLE(1)_Eddystone beacon”和“玩转BLE(2)_使用bluepy扫描BLE的广播数据”两篇文章的介绍,我们已经有了一个整体的认识.本文将依此为基础,从技术的角度,分析和理解BLE协议中有关广播通信的定义和实现. 注1:之前的蓝牙协议分析文章(如“蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍”),偏向于从横向.从大而全的

1. 前言 蓝牙是个奇葩的家伙:它总是以后来者的身份出现,很喜欢打仗,而且还不落下风(有点像某讯的风格).90年代末期和Wi-Fi的无线标准之争如此,当前和802.15.4系(ZigBee.RF4CE.Thread等)的IoT之争,也如此. 90年代末期,蓝牙刚出道的时候,就曾叫嚣着把Wi-Fi(802.11)从地球上抹去.反过来,1999年Wi-Fi 802.11b标准发布后,也宣称会把蓝牙干掉.最终,二者划江而治,瓜分了天下,Wi-Fi占据了家庭和办公室中的电脑网络,而蓝牙成为了广受欢迎的电

1. 前言 通过“蓝牙协议分析(2)_协议架构”的介绍,大家对蓝牙协议栈应该有了简单的了解,但是,肯定还有“似懂非懂.欲说还休”的感觉.有这种感觉太正常了,毕竟蓝牙协议是一个历史悠久又比较庞大的协议,没那么容易理解. 因此,本文将换个视角,从协议栈设计者的角度,思考如下问题: 为什么会有蓝牙协议栈(Why)? 怎样实现蓝牙协议栈(How)? 蓝牙协议栈的最终样子是什么(What)? 另外,我们知道,当前的蓝牙协议包含BR/EDR.AMP.LE三种技术,为了降低复杂度,本文将focus在现在比较热

1.概述:   蓝牙协议规范遵循开放系统互连参考模型(OSI/RM),从低到高地定义了蓝牙协议堆栈的各个层次. SIG(Session Initiation Protocol)所定义的蓝牙技术规范的目的是使符合该规范的各种应用之间能够实现互操作. 互操作的远端设备需要使用相同的协议栈,不同的应用需要不同的协议栈. 但是,所有的应用都要使用蓝牙技术规范中的数据链路层和物理层. 2.完整的蓝牙协议栈 完整的蓝牙协议栈如图1所示,不是任何应用都必须使用全部协议,而是可以只使用其中的一列或多列. 图1显

本篇博客根据韦东山的视频,整理所得. 本篇博客讲解BTStack的框架,首先来看一下硬件的结构: 蓝牙模块接在电脑上,或是接在开发板上.不论接在哪,我们都需要编写程序来控制这个蓝牙模块. . 我们需要发送数据给蓝牙模块 需要发送命令给蓝牙模块,比如让它发出无线信号去扫描.识别.连接.读写附近的蓝牙设备 2. 需要从蓝牙模块获得数据 3. 需要处理获得的数据 上述3步骤可以简化为一个循环: 1．读取数据:可以读取用户输入的指示,也可以读取蓝牙模块的数据 2．处理数据:根据用户的指示发送数据给蓝牙模

简介: HSP(手机规格)– 提供手机(移动电话)与耳机之间通信所需的基本功能. HFP(免提规格)– 在 HSP 的基础上增加了某些扩展功能,原来只用于从固定车载免提装置来控制移动电话. A2DP(高级音频传送规格)– 允许传输立体声音频信号. (相比用于 HSP 和 HFP 的单声道加密,质量要好得 多) AVRCP(音频/视频遥控规格)–用于从控制器(如立体声耳机)向目标设备(如装有 Media Player 的电脑)发 送命令(如前跳.暂停和播放). SPP 蓝牙串口是基于SPP协议(S

Bluetooth 配置文件表达了一般行为,Bluetooth 设备可以通过这些行为与其它设备进行通信.Bluetooth 技术定义了广泛的配置文件,描述了许多不同类型的使用案例.为了使用 Bluetooth 无线技术,设备必须能够翻译特定 Bluetooth 配置文件.配置文件定义了可能的应用.对象交换 (OBEX) 协议OBEX 传输协议定义了数据对象和两个设备用来交换这些对象的通信协议.OBEX 支持应用程序在 Bluetooth 协议堆栈及 IrDA 堆栈上工作.对于 Bluetooth

1. 前言 也许关注BLE的同学都注意到了,BLE设备有多种类型的设备地址,如Public Device Address.Random Device Address.Static Device Address.Private Device Address等等.如果不了解内情,大家肯定会被它们绕晕.不过存在即合理,这样看似奇怪的设计,实际上反映了BLE的设计思路以及所针对的应用场景.让我们通过本文一窥究竟. 2. BLE设备的地址类型 一个BLE设备,可以使用两种类型的地址(一个BLE设备可同时具

上篇博客中已经对BTStack框架进行了较为详细的说明,本篇博客将进一步总结一下(由韦大仙笔记所得). 可以从5个方面来理解BTStack的框架: 1.硬件操作:hci_transport_t BTStack支持多种接口的蓝牙模块,比如USB口.3线串口.5线串口. 对于这些接口,会抽象出对应的hci_transport_t结构体. 该结构体成员如下: 里面有init.open.send_packet等重要成员. 对于3线串口.5线串口,它们在init.open设备时,不需要写两套代码.因为它们

首先来看一下,对于硬件操作,它是如何来进行处理的.在上篇文章中曾说过,在main函数里面它会调用硬件相关的代码,调用操作系统相关的代码.在BTStack中,可以搜索一下main.c,将会发现有很多main.c,都是为于port目录下面. Main.c (port\esp32\components\btstack) Main.c (port\ez430-rf2560\src) Main.c (port\libusb) Main.c (port\libusb-intel) Main.c (port\