1. 背景
客户的项目是无线控制灯具，目前采用2.4G芯片，一端是2.4G遥控器，一端是2.4G灯具。现在客户的需求是在不增加成本的条件下增加手机APP控制。因为BLE芯片一般会比纯2.4G芯片价格高，所以客户不想用BLE芯片替代掉2.4G芯片，毕竟省下的钱都进了客户自己的腰包。
2. 项目评估
BLE和2.4G都工作在2.4GHz频段，所以让他们互相通信在物理层上理论是可行的。在物理层之上只要手机BLE发送的数据包能被2.4G芯片解析就可以达到目的，所以本项目的技术点就转换到手机BLE模拟2.4G的数据包发送数据。
3. 技术实现
频移键控（FSK）接收机的一个特点：其接收连续相同比特的能力很差，当接收机收到一连串的“0000000000”时，会认为发射机的频率向左移了，进而导致频率失锁，以致导致数据接收失败。所以为了避免数据传输中出现一连串的全0或者全1，BLE设备会对数据做白化处理。
白化这个词，可能在深度学习领域比较常遇到，挺起来就是高大上的名词，然而其实白化是一个比PCA稍微高级一点的算法而已，所以如果熟悉PCA，那么其实会发现这是一个非常简单的算法。白化的目的是去除输入数据的冗余信息。假设训练数据是图像，由于图像中相邻像素之间具有很强的相关性，所以用于训练时输入是冗余的；白化的目的就是降低输入的冗余性。
输入数据集X，经过白化处理后，新的数据X'满足两个性质：
(1)特征之间相关性较低；
(2)所有特征具有相同的方差。
其实我们之前学的PCA算法中，可能PCA给我们的印象是一般用于降维操作。然而其实PCA如果不降维，而是仅仅使用PCA求出特征向量，然后把数据X映射到新的特征空间，这样的一个映射过程，其实就是满足了我们白化的第一个性质：除去特征之间的相关性。因此白化算法的实现过程，第一步操作就是PCA，求出新特征空间中X的新坐标，然后再对新的坐标进行方差归一化操作。
然而手机端的白化处理是无法直接通过软件接口关掉的，所以在发送时就需要做反白化处理。另外，2.4G芯片接收机的特点是：从空中抓取2.4GHz信道的数据包，逐BIT对比，硬件过滤掉不是自己想要的数据包（不是只对比数据包头）。
手机端APP的实现原理如下：
文档中包头部分（Header）是指必须在手机端APP里添加的头，并非标准BLE的包头。
Packet Format:
|---------------------------------------------------------------------------|
|---------------------------------------------------------------|----------------------------------------| |---------------------------| |
| | | | | |
| |---------------| |-----------------| |---------------| | |--------------| |-----------------| | | |---------------------| | |
| | Pdu_head(2B) | + | Mac_address(6B) | + | Menu_head(4B) | +| | Preamble(3B) | + | Dev_address(4B) | | + | | Payload(Max is 18B) | | |
| |---------------| |-----------------| |---------------| | |--------------| |-----------------| | | |---------------------| | |
| | | | | |
|----------------------------------------Header Format----------|----------------------------------------| |------.4G Control---------| |
| |
|-----------------------.4G Packet Format----------------------------------|
Pdu_head： 标准BLE数据包的PDU head(BLE协议规定)，此值可通过Android API设置。
Mac_address: BLE设备的MAC 地址(BLE协议规定)，此字段可通过Android API设置。
Menu_head: Menufacture data head(BLE协议规定), 此字段占4个字节。目前设置为1E FF F0 FF，此值是通过Android API设置的。
Preamble: 引导码，此字段占3个字节。此字段必须设置为2.4G接收芯片端规定的值，.4G接收芯片端规定此值为0x710F55，Android端发送值见下。
Dev_address：设备地址，此字段占4个字节。此字段也必须和2.4G接收端确认。
Payload: 有效数据，此字段最大为18个字节。用于2.4G应用控制数据包，此字段用于应用控制协议，若应用控制协议大于18Byte需另做说明。
//以下代码可以直接编译、运行，然后直接查看最后结果
#include <stdio.h>
/**数据准备：
定义一个37字节的数组（标准BLE广播数据包最大的payload为37字节）,BLE数据包LSB发送在前。
根据Header Format结构，可得到data[11] - data[13]为Preamble字段，data[14] - data[17]为Dev_address字段。
而且Preamble和Dev_address必须进行比特的反转。
Example：
2.4G接收端Preamble为： 0x71 0x0F 0x55
| | |
那么，对应Android端为： 0x8E 0xF0 0xAA
2.4G接收端Dev_address为： 0xC0 0xC1 0xC2 0xC3
| | | |
那么，对应Android端为： 0x03 0x83 0x43 0xC3
*/
] = {,,,,,,,,,,,,};
] = {};
；
void whitening_init(int channel_index)
{
;
whitening_reg[] = ;
; i < ; i++)
{
whitening_reg[i] = (channel_index >> ( - i)) & 0x01;
}
}
int whitening_output(void)
{
] ^ whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = whitening_reg[];
whitening_reg[] = temp;
];
}
int whitening_decode(int *data, int length)
{
;
; data_index < length; data_index++)
{
int data_input = data[data_index];
;
;
; bit_index < ; bit_index++)
{
data_bit = (data_input >> (bit_index)) & 0x01;
data_bit ^= whitening_output();
data_output += (data_bit << (bit_index));
}
data_re = data_output;
//此处可以得到最后转换完成的数据
&& data_index < )
{
printf("Result == %x\n", data_re);
}
}
return data_re;
}
int main(int argc, char * argv[])
{
;
//37代表传输在2402频点， 38代表传输在2426频点， 39代表传输在2480频点， 参数只能为这3个值其中一个，需和2.4G接收端协调一致。
whitening_init();
//此处可以对data数组index=20以后赋值，赋值即为2.4G控制协议字段
//whitening_decode(*,*)函数第二个参数代表要转换的数组个数
result = whitening_decode(data, );
getchar();
;
}
该实现方式缺点：
1. 无法实现跳频，如果BLE的37/38/39某个频点严重拥堵的话可能会造成接受成功率低
2. 以上主要适用于Android手机版本BLE4.0/4.1/4.2，BLE5.0新增加了37个信道用于广播。