前言

很久没有更新技术博客了。最近一年都在做低功耗蓝牙和物联网等相关的事情，想把一些经验和心得写成博客分享出来，也算对自己工作的一种总结。开一个系列讲解NXP的低功耗蓝牙SDK开发的方方面面，目前NXP官方仅有一个英文版的《BLE Application Developer Guide》介绍SDK的使用，对于国内开发者来说不太友好。希望这个系列文章能作为官方文档的补充，帮助到正在使用和将要使用NXP蓝牙的芯片的朋友们。

NXP BLE SoC概况

目前NXP面向物联网和可穿戴设备数据传输应用的BLE SoC芯片要有QN和KW两大系列（型号特点见下表），除了QN902x使用原Quintic自带的协议栈SDK外，其他几个型号都采用了NXP MCUXpresso SDK和NXP自研的Bluetooth协议栈，呈现给用户的编程接口完全一致。无论是开发超低功耗的QN9080，支持Zigbee/Thread/BLE多模的KW41，还是面向汽车应用的KW36，对固件工程师来说，掌握了一款芯片的开发，拿下其他的也就是轻而易举之事。

MCUXpresso SDK与NXP BLE协议栈

MCUXpresso SDK是NXP面向MCU市场推出的一套完整的软件开发套件，支持Kinetis, LPC, i.MX RT等通用微控制器以及QN和JN系列的无线连接微控制器。一个SDK包内包含了芯片硬件抽象层，外设驱动库，多个中间件库（根据芯片功能的不同包含不同的中间件，比如带Ethernet外设的MCU则会有lwip网络协议栈中间件），以及丰富的示例代码。

NXP BLE SDK系统架构

NXP提供了一套完整的BLE协议栈和编程框架，并已通过了Bluetooth Core Spec 5.0的认证。用户第一次开发自己的应用时，应当先大致了解整个系统的组成，知道每个部分的职责，分别有哪些文件。有了一些基础，再通过查询API文档，很快便能掌握BLE应用开发。下图为BLE SDK总体的框架图，图中使用了几种不同的颜色来区分：

OSA

OSA属于Connectivity Framework，单独介绍它是因为OSA服务于整个SDK和协议栈，并且也是系统复位后的入口。整个蓝牙协议栈和SDK的设计使用了RTOS下才有的多任务，消息和事件等服务。为了减少代码大小和栈的内存，适配一些资源紧张的SoC，在设计时才引入了OSA。

Connectivity Framework

Connectivity Framework包含了众多的子模块，服务于应用和BLE协议栈。本系列文章将会抽取其中几个比较重要的几个子模块作为单独的文章来分析。本文希望先给读者一个总体概念，通过表格列出了各个模块的职责和必要性。标注为“必要”的模块如果缺失，最后整个BLE工程构建将会失败，说明该模块已被协议栈或者其他的代码引用了。标注为“非必要”的模块目的是服务应用层，如果用户的应用不需要这个功能，则可以移除。

BLE协议栈

BLE协议栈以闭源库的形式提供，分为Host和Controller两部分。下图描述了组成Stack的主要文件和相互之间的依赖关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// 1. initiate API to request and connection and register a callback
bleResult_t rt;
rt = Gap_Connect(&gConnReqParams, Gap_ConnectionCallback);
if (rt != gBleSuccess_c) {
    printf("Gap_Connect API fail, reason = %d\r\n", rt);
}
// when PC(R15) arrives here, the connection may NOT be setup
... 
// 2. initiate API to request a disconnection action.
rt = Gap_Disconnect(peerDeviceId);
if (rt != gBleSuccess_c) {
    printf("Gap_Disconnect fail, reason = %d\r\n", rt);
}
// when PC(R15) arrives here, the connection may NOT be disconnected
... 
// 3. Event will be triggered when connection and disconnection happens
void Gap_ConnectionCallback(deviceId_t peerDeviceId, gapConnectionEvent_t* pConnectionEvent)
{
    switch (pConnectionEvent->eventType)
    {
        case gConnEvtConnected_c:
            // async event to notify that link is connected
            printf("Connected to device (%d)\r\n", peerDeviceId);
            break;
           
        case gConnEvtDisconnected_c:
             // async event to notify that link is disconnected
            printf("Disconnected to device (%d)\r\n", peerDeviceId);
            break;
            ...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// User call App_Connect, instead of Gap_Connect
bleResult_t App_Connect(gapConnectionRequestParameters_t*   pParameters,
                        gapConnectionCallback_t             connCallback)
{
    pfConnCallback = connCallback;
    return Gap_Connect(pParameters, App_ConnectionCallback);
}
// Simplified App_ConnectionCallback, the function insert a message and notify App Thread
void App_ConnectionCallback (deviceId_t peerDeviceId, gapConnectionEvent_t* pConnectionEvent)
{
    appMsgFromHost_t *pMsgIn = NULL;   
    uint8_t msgLen = GetRelAddr(appMsgFromHost_t, msgData) + sizeof(connectionMsg_t);
    
    pMsgIn = MSG_Alloc(msgLen);
    // use Applmain defined message type
    pMsgIn->msgType = gAppGapConnectionMsg_c; 
    pMsgIn->msgData.connMsg.deviceId = peerDeviceId;
    FLib_MemCpy(&pMsgIn->msgData.connMsg.connEvent, pConnectionEvent, sizeof(gapConnectionEvent_t));
    MSG_Queue(&mHostAppInputQueue, pMsgIn);
    OSA_EventSet(mAppEvent, gAppEvtMsgFromHostStack_c);  
}
// Pseduo code of App_Thread
void App_Thread (uint32_t param)
{
    while(1) {
        OSA_EventWait(mAppEvent, osaEventFlagsAll_c, FALSE, osaWaitForever_c , &event);
        if (event & gAppEvtMsgFromHostStack_c) {
            while (MSG_Pending(&mHostAppInputQueue))  {
                pMsgIn = MSG_DeQueue(&mHostAppInputQueue);
                // check msgType and dispatch callback handler
                if (pMsg->msgType == gAppGapConnectionMsg_c) {
                    pfConnCallback(pMsg->msgData.connMsg.deviceId, &pMsg->msgData.connMsg.connEvent);
                } else if (pMsg->msgType == ...) {

1
2
3
4
5
6
7
8




    
9
10
11
12
13

#include <stdio.h>
#include "debug_config.h"
#if defined (CFG_MODULE_x_DEBUG_EN) && (CFG_MODULE_x_DEBUG_EN > 0)
#define MODULE_x_DEBUG    printf
#else 
#define MODULE_x_DEBUG    1 ? (void) 0 : (void) printf
#endif
void func(void)
{
    MODULE_x_DEBUG("Hey I'm module x prompts\r\n");
}

1
2

```
printf("Hey I'm module x prompts\r\n");

1
2

```
1 ? (void) 0 : (void)printf("Hey I'm module x prompts\r\n");

I2C规范与特性

I2C是什么，我相信99%的同学能点到这篇博文对I2C也有了一定的了解，这里附上一份I2C鼻祖NXP （前Philips半导体）的一份权威手册： I2C-bus specification and user manual v.6

描述一下I2C最重要的几个特性，为了后面描述问题和解决方案作一些铺垫。

一般情况下I2C的SDA只有在SCL为低电平的时候才能改变，为高电平的时候需要保持。对应到芯片设计上则是上升沿采样，下降沿变化。

两个例外情况由主机发出的总线起始条件START（SCL为高时SDA由高变低）和停止条件STOP（SCL为高时SDA由低变高）

挂死 = 挂了 + 死机

挂死这个词应该来源于英文 hangs : To cause (a computer system) to halt so that input devices, such as the keyboard or the mouse, do not function .

SDA挂死

先来看下哪些情况下I2C从机会需要拉低SDA线。

SCL挂死

I2C从机主动拉低SCL线在规范中是一个合法的行为，称之为Clock Stretching（时钟扩展，我一般叫他时钟同步）。通常是主机请求数据（ 收或者发）后从机需要一些时间处理，且没有多余Buffer可以接收接或者提供接下来的数据的时候从机则会拉低SCL 一段时间 直到有新的数据准备好。

查看支持分辨率

第一次安装了Raspbian后启动系统会模式使用显示器“兼容模式”，这是一个VGA @ 60Hz的设置保证所有的HDMI连接到任何显示设备都能有显示。进入桌面后用户可以通过系统配置文件/boot/config.txt来修改分辨率

1

/opt/vc/bin/tvservice -m DMT

1

/opt/vc/bin/tvservice -m CEA

1
2
3
4
5
6

Group DMT has 11 modes:
          mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
          mode 6: 640x480 @ 75Hz 4:3, clock:31MHz progressive
          ...
 (prefer) mode 82: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
          mode 83: 1600x900 @ 60Hz 16:9, clock:108MHz progressive

选择合适分辨率

一般选择最优的模式，即1920x1080 @ 60Hz。
下面命令修改并确保参数是正确的，CTRL+O 回车保存，CTRL+X退出。

1

sudo nano /boot/config.txt

1
2
3
4
5

...
#hdmi_safe=1  // 禁止safe模式
hdmi_group=2  // 1=电视, 2=显示器
hdmi_mode=82  // 1920x1080@60Hz
...

1

Reboot

作死

手痒试一试选择不支持的分辨率（e.g. mode=3）…果然…黑屏了….

思考三层云服务的合理比喻

在网上看到一些把三层云服务比喻成吃披萨，开养猪场等例子，相当生动形象。 知乎: 谁能举个通俗易懂的例子告诉我IAAS，SAAS，PAAS的区别？ 但有一点似乎都被大家都忽略了，三层云服务所面对的客户是有所区别的。我觉得有必要把比喻打得更加贴切一些。写下自己的理解，从买一杯咖啡开始。

SaaS：软件即服务 = 开个咖啡店

SaaS 是 S oftware a s a S ervice 的缩写

在穿过海岸城广场去往地铁站的路上，一字排开的临街商铺前总热闹非凡。各式各样的门店来满足着消费者的生活需求：

SaaS 服务提供商跟这些商铺一样，也是云服务中与终端消费者日常接触的一层，来满足各种不同的应用需求。困了我会买一杯香浓的咖啡，不需要自己选咖啡豆、买咖啡机再翻出各种攻略来研究怎么煮一上壶。同样我有文件要存储共享我会使用云盘，而不是自己建个存储平台再搭个FTP什么的，为了可靠安全的存储我可能会选择一些大公司产品，比如iCloud Drive，所以付点钱也是值得的。

除了办公、存储、社交、视频这些面向个人消费者的 SaaS 云服务，还有很大一部分是面向企业的SaaS，如Saleforce, GoToMeeting等。如果把企业看做一个消费者，这之间没有什么实质差别。

角色扮演：

• SaaS 提供商：咖啡店及各种商铺
• SaaS 消费者：普通消费者

PaaS：平台即服务 = 运营购物中心

PaaS 是 P latform a s a S ervice 的缩写

看到生意如此火爆，我也打算开个 熊小宇の咖啡店 。第一步是找铺面，一开始宣传资金和运营经验都是不够的，需要找一个相对成熟商场。而Shopping Mall的运营中心正有我所有需要的东西：

出租繁华地段的铺面

合理的空间布局

相邻商铺间的内容互补分析

人流量与消费数据分析报告

饮品相关的品牌和供应渠道

剩下要做的就是专注于设计自己的店铺，装修和请人干活了。购物中心先租赁或者购买物业的产权，进行品牌包装，整体设计和零售管理，来打造一个一站式的平台，形形色色的商家只要联系购物中心，缴纳租金和服务费就可以开店了。

云服务中 PaaS 这一层的就像是运营购物中心， PaaS 提供给做 SaaS 服务的公司的一个基础平台，包括数据库、SDK、部署工具、控制台等等组件或框架，同时也提供行业解决方案与技术咨询&支持。

如果你的需求只是一杯咖啡，你是不会去跟购物中心打交道的。购物中心面向客户仅是需要开店的商家。同样 PaaS 面向 SaaS 开发者的服务，而 SaaS 则是面向个人或者企业消费者的服务。

角色扮演：

• PaaS 提供商：购物中心运营商
• PaaS 消费者：咖啡店及各种商铺

IaaS：基础设施即服务 = 当个地产开发商

IaaS 是 I nfrastructure a s a S ervice 的缩写

开了咖啡店又不满足了，我也希望能开一间小型的购物中心。了解过后知道一个购物中心也不都是从零开始打造的。首先会寻找一个繁华的地段、选择适合的场地建筑和基础设施，和开发商签约，再开始购物中心包装。而这么一个场地的建造则是由地产开发商完成的，包括：

整个工程工期漫长又耗资巨大，一般不是中小公司能玩转的。在基础设施建造完毕后，地产开发商再将毛坯物业出租或者出售给运营购物中心的企业，实现盈利。

IaaS 跟这地产商建房子相似，提供给消费者的服务是对所有计算基础设施的利用，包括处理CPU/GPU、存储、网络和其它基本的计算资源，以及运行环境所需的操作系统与虚拟化环境。同样重要的一点： IaaS 的客户是 PaaS 服务商。

很多时候一些大的服务提供商同时会提供 IaaS 和 PaaS 的服务，比如阿里云和亚马逊AWS。这就像万达广场，除了整体的设计建造是万达集团的同时也自己的Shopping Mall品牌来运营购物中心。

角色扮演：

• IaaS 提供商：地产开发商
• IaaS 消费者：购物中心运营商

本地部署

当然，我也可以自己从头开始打造一间咖啡店。买水泥、建房子、装水电、搞装修、买设备、进货、雇员工一切都自己来，这就是本地部署。不过算一笔账，开个咖啡店的成本本来只要二十万，时间一个月。但建房子成本需要一千万，时间两年，并且其中环节诸多，傻子才这么做啊。

BLE背景

从2010年7月Bluetooth SIG年发布蓝牙4.0 LE（Low Energy）低功耗版本蓝牙，到今天也才6个年头，而在iPhone和Android手机给力的支持下BLE得到了前所未有的快速普及。根据 市场调研报告 表明，到2020年，将会有84亿的设备通过BLE技术连接，市场符合增长率高达29%。
随着智能硬件和创客概念的迅猛发展，各种新概念的智能产品也层出不穷，BLE作为其中最为广泛应用的无线技术，成为了人和数字信息世界之间沟通的重要桥梁。这也是我们为什么要学习BLE的原因：只要你有好的idea，利用BLE技术可以迅速使你的idea和产品连接上智能手机和移动互联网的海量用户。

第二代SoC

回到产品，目前市面上常见的BLE SoC大体上可以分为两代，第一代是以TI、Nordic、CSR最早三家做BLE SOC的先驱者，经过几年的发展已经趋于成熟，价格也稳定在1美金以下，处于跑量的状态。第二代BLE SoC是在新的设计在制程更新到55nm后，功能性能功耗有着一次质的飞跃，除了之前几个老玩家以外，几家瞄准了IoT节点与Connectivity的MCU大厂也纷纷加入这场残酷战斗，增添了不少火药。

• nRF52832 （Noridc）（表示不服：我可是第三代都公布）
• DA14680 （Dialog）
• QN9080 （NXP）（准备量产）
• CC2640 （TI）
• PSoC4 BLE （Cypress）
• EFR32BG1 （Silicon Labs）

其他几颗SoC如 CSR102x (CSR)，ATSAMB11（Microchip），TC35678（Toshiba）因资料不多或者或还未有成熟应用暂时没有放进来。

• 最佳均衡奖：nRF52832 （最重要还是成熟）
• 最低功耗奖：QN9080 （新星，8MHz 跑协议栈, 3.4mA Tx @ 0dBm, 3.6mA Rx）
• 最佳射频奖：CC2640（-97dBm）
• 最大功率奖：EFR32BG1（+19.5dBm，好像蓝牙SIG只定义了10dBm…Orz）
• 最大容量奖：DA14680（1MB Flash）
• 最佳配角奖：PSoc4 BLE（路过… 非黑）

表示当存储1Q的电荷量时若电压为1V，那么电容为1F。

上述定义式仅表示在电路中量度该物理量的一种方法，我们不可以说”平行板电容器的电容C跟两板间所带的电荷量Q成正比，跟两板间的电压U成反比”。因为电容器的电容C是客观存在的，当两板不带电时，电容C依然存在。它的大小有【决定式】来决定。

平行板电容器电容C的【决定式】

决定式就是表示该物理量的大小都与哪些因素有关系，通常是由其物理特性决定的，与所连接电路无关。对于电容器的电容C来说：

C = εrS / 4πkd

其中k为静电力常量，库仑定律中的 k = 1 / (4πε0)，代入上面公式也可以得到更为简洁的公式：

C = εrε0S / d

ε0是真空介电常数，等于8.854187818 x 10-12 F/m
εr为平板电容器绝缘材料的相对介电常数，跟材料有关系，它没有量纲。εr越大，电容C越大
S为平行板正对面积。S越大，电容C越大
d为平行板之间的距离。d约大，电容C越小

第二部分：电容器与水桶的类比

---

电容器类比于水桶的概念，有助于快速理解电容器在电路中任一时刻电容C、电压U、电荷Q三者的关系。

根据电容器电容C的定义式得到：

电荷Q = 电容C * 电压U

对于水桶：

水的体积V = 底面积S * 水面高度H

我们可以做以下类比：

• 电容C大小类比于水桶的底面积S（两者都是造出来以后就固定了）。
• 电容器两端的电压U类比于水面高度H（注意，是水面的高度，不是桶的高度，放水的多少不同，水面高度是有变化的）。
• 电容器存储的电荷Q类比于水桶内水的体积V。
• 电容器的极限耐压值Umax类比于水桶的高度Hmax。

进一步来理解和验证以上的类比否合理：

• 同样电荷Q向不同的电容器充电，电容C越大电容器，电压U越小。类比到水桶，同样体积的水V倒入不同的水桶里，底面积S越大的桶子，水面高度H越小。
• 某一电容器，当有更多的电荷Q注入，电压U就会越来越高，直到达到电容器的极限耐压值Umax。类比到水桶，某一水桶，只有更多体积的水V倒入，水面高度H就会不断上升，直到达到水桶的高度Hmax。

• 电容器可以容纳的最大电荷Qmax是指两端电压U达到极限耐压值时的值： Qmax = C * Umax
  类比到水桶，一个水桶可以盛水的最大水的体积Vmax是指当水面高度H达到水桶高度时的值：Vmax= S * Hmax

• 平时我们说电容器充满了，是指在电容器两端的电压等于了外部电源电压，没有电势差之后，外部电源自然无法再向电容器充电。这时两者电压相同，C大的，所能存储的如果能进一步提高外部电压，电容器两端的电压U还可以继续升高直至极限耐压值Umax。类比到水桶，我们假设有两个水桶，两者底部是互通的。当水桶A（相当于电压源，也可以理解为电容器向电容器充电）的水面高度H比水桶B（相当于电容器）高时，水会从水桶A注入到水桶B中，直到两者的水面高度相同时停止。

  飞亚达最新发布的 印系列智能手表 。不同于目前数字屏的显示方式，这款手表拥有传统的石英表外观和一个智能的机芯，让钟情传统手表的商务人士也能体验智能设备带来的便利。同样类似的产品我比较喜欢的是Withing的 activite steel ，感觉Apple Watch瞬间被秒。
  
  除了配备基本的健康管理、消息提醒、防丢功能外，这款手表还提供30天的超长待机和NFC公交支付两大亮点。公交支付目前是非常火的移动应用，其使用率和用户粘性极高。

  9月1日小米发布的小米5 MiPay在手机端已经支持了北上广的公交卡应用

  飞亚达在手表端实现公交刷卡将绝对是更为友好的体验，目前功能还在测试中，据说10月底先会首先支持深圳通。在印系列手表上NFC公交支付与其他公交手环产品不同的是，据了解采用了与小米5采用了相同的全终端方案。可以通过空中发卡的方式来开通多个城市公交系统的支持，意味着用户去到不同的城市也可以非常方便的下载和使用当地城市的公交卡。

  这款手表基于NXP支付手环参考设计方案，一个完整的硬件 + 软件可穿戴二次开发平台。其中包含了MCU、NFC前端与嵌入式Secure Element、蓝牙网络控制器以及加速度计等主要4颗芯片：

• LPC5410x 低功耗微控制器
• PN66T NFC前端控制器与嵌入式Secure Element
• QN902x 低功耗蓝牙SoC
• MMA8652 低功耗加速度计

系统框图如下：

在参考设计方案中，除了线路设计图还包含有完整的SDK软件开发套件。NXP可穿戴支付SDK包含了一个由FreeRTOS实时内核调度的NFC中间件和抽象的SE API应用编程接口，NFC业务开发可以直接通过SE API提供的接口进行而无需关心底层是如何沟通的，同时这组接口还扩展了LoaderService与MiFare Open Platform的功能。

Loader Service 使服务提供商可以简化NFC安全应用的部署，具体可参考NXP官网的一篇白皮书 Loader Service: The Tipping Point for Secure NFC Payments

除了NFC和SE管理中间件，在SDK中还提供了多个系统组件以满足通用可穿戴设备Time to Market的要求：

• LPCXpresso驱动库
• 低功耗管理API和FreeRTOS tickless模式
• 计步器算法
• ANCS蓝牙Profile
• OTA 空中升级
• 参考Android APP

低功耗是可穿戴设备的一个重要指标，采用这个方案的系统待机功耗小于100uA，在典型工作场景下150mA电池可以使用一个月。

这两年可穿戴产品炒得太过火热，行业新增概念和亮点并不多，特别是手环类的产品，除了时间管理、消息通知、健康运动和位置追踪几个主打应用，能真正解决用户痛点的应用少之又少。今年行业领跑者估值大幅度缩水，Jawbone甚至跌回了5年前水平，几大品牌在小米和其他国产手环产品的低价策略冲击下处境艰难。设备制造商在这样的竞争环境下必须不断创新，找准出路。NFC可穿戴是一个不错的技术路线，同时市场也日渐成熟。

总结NFC移动支付和公交应用带来的改变：

• 服务提供商吸引客户通过手机和可穿戴设备进行业务操作，提升应用体验、增加用户粘度。
• 软硬件设备制造商依托于服务器提供商的平台，迅速提高产品销量和提升毛利率。
• 终端用户则简化了安全支付，公交充值，卡管理等等日常低效繁杂操作

HexiWear可穿戴技术原型开发平台

---


HexiWear 是由 mikroelektronika 与 NXP 一起开发的基于MCU的开源IoT与可穿戴原型开发。所有资料包括原理图、PCB设计文件、固件以及App的源码都可以从HexiWear网站或者 Github 获取。


NOTE : 其中固件的框架和GUI，计步器库等内容值得学习以用于进行二次开发

从系统框图来看，在这个小小的手表空间里包含了7颗NXP芯片，涵盖了MCU主控、BLE无线连接、9轴运动传感器、压力传感器和电源管理功能，除此之外还支持温湿度、环境光传感器和心率传感器。反正能找的传感器都已经支持了，如果能加上GPS就完美了。在印象中也就是Microsoft Band 2（主控似乎是Kinetis K26）有这么多Sensor了。

• Kinetis K64F 微控制器（主控）
• Kinetis KW40Z 单芯片BLE与802.15.4多协议无线处理器
• FXOS8700CQ 六轴加速度与地磁传感器
• FXAS21002 三轴角速度传感器（陀螺仪）
• MPL3115A2 绝对压力传感器
• MC34671 单节锂电池充电管理器
• Kinetis K20 OpenSDA调试器
  

在我看来这个平台最能吸引开发者的是HexiWear能通过Docking板来扩展mikroelektronika提供的上百种 click 物联网模块，可用最快的速度进行原型的开发与验证。(mikroelektronika我真是服，编译器，软件，硬件模块什么都能造）


Hearable属于Wearable可穿戴的一个分支。每年都有数以千万的耳塞、耳机被销售和使用。相比手腕位置，用户群体更广，在耳机产品平台上发展智能技术越来越受到重视。下面来看看由一根线引发革命：真无线耳塞

尽管Apple近年来一直在控制创新风险，做出的产品对于市场还是有极强的冲击力。这次随着iPhone7出来的AirPods让双耳无线耳塞产品火（吐槽）了一把。同类产品早在两年前就有不少的创业型公司已经有开始众筹，相信在AirPods的刺激下整个市场在今年下半年和明年会有一个爆发期。目前ifixit和Chipworks还看不到拆解分析，需要了解AirPods的小伙伴可以看看这篇YY分析： AirPods - a Speculative Teardown 。

在FTF上NXP展出的双耳无线耳塞技术基于NFMI的方案，这个技术算是NXP的独门绝技了。NFMI技术早在10年前就已经被采用在助听器技术中，用于提供两耳之间超低功耗的语音传输。NXP将这个技术进行的升级优化，提高了带宽以用于消费级的无线音乐传输目的，之前KickStart上非常火的无线耳机 the dash 就使用了NXP第一代的NFMI芯片，本次展出的是第二代NFMI芯片 NXH2280 。其他基于NFMI技术的耳机还有

• the headphone from Bragi
• Elite Sport from Jabra

NFMI = N ear F ield M agnetic I nductive = 近场无线磁传导

NFMI为什么在这个市场上占有一席之地需要从需求谈起。目前市面上的普通无线耳塞技术都是基于蓝牙Classic的A2DP协议，而A2DP协议本身设计是点对点传输音频数据，当用户希望两个耳朵完全没有线缆时这个技术在实现上需要做一些修改，最为常见的是CSR提供的中继方案：一个耳塞收到A2DP的立体声audio之后，本地分离出左右声道再次通过蓝牙传输到另外一个耳塞，同时做同步控制。早期的无线耳塞 Earin 就是使用的这个技术。它最大的问题是人体皮肤对于2.4G信号的吸收，导致其无线设计非常具有挑战，特别当耳机体积做的很小的时候几乎无法解决两耳之间音频传输的稳定性。而NFMI技术的出现解决了这个问题，对于人体免疫的特性让他非常适合作音频中继的用途。这次摆在展台的是NXP开发的基于NXH2280的ADK，系统组成近似于：


ADK = A pplication D evelopment K it = 应用开发套件

大致的工作流程：从手机蓝牙通过A2DP协议将经过SBC，AAC或者aptX压缩的双声道音频传输到其中一个耳塞中的蓝牙SOC，经过解码后将两个声道分离，本地的通道经过一定的延时（等同于无线）后播放出来，对端的声道发送给本地NXH2280进行压缩后和传输， 在另外一只耳塞的NXH2280收到音频数据包进行解压缩、重采样、延时控制后输出给CODEC进行播放。

需要注意的是虽然NXH2280主要的市场是无线音频，但也可以用于其他需要超低功耗和近距离通讯，特别是紧贴人体的传感器应用场景，比如标贴医疗传感器，体内药丸等，全靠脑洞大开的电子工程小伙伴们开发新的想法了。

最后总结一下NFMI技术的几个技术特点和限制：

• 超低功耗（传输经过压缩的48kHz单声道音频小于2mA）
• 免疫皮肤组织
• 可以在水下工作（游泳也可以听歌哦）
• 与其他无线技术的共存和兼容性
• 天然的安全性
• 在小天线和低功场景下，通讯距离短（<50cm）
• 吞吐率较低（596kbps）