利用PLL（LM567)做频率解调的实例

条件限定为：一个MONO的蓝牙音频模块，把它做成蓝牙遥控器，而且，控制的时候还要播放主机走蓝牙过来的声音。

同时，这个蓝牙模块没有数据片可以走，直接输出载着直流的音频差分信号。

讨论的结果就是，在要播放的声音里混音进人耳听不到的频率部分，然后在蓝牙音频模块输出端把数据解调出来。

解调部分

核心部分就是LM567的解调端，中心频率设定在人耳基本听不到的18.5Khz

核心的部分是音调检测，用了一款NS家很老的专门做音调检测的LM567。

其原理就是利用本地RC震荡产生一个频率，与输入频率进行鉴频，8脚是专门做鉴频输出用。

f0的公式电容用uF，电阻用KOmh，频率为kHz

算出来18.5Khz下

Cx=6.8nF

Rx=7.5K

但实际调试的时候RX建议用10K的微调电阻，因为其他器件可能会有误差

带宽跟C2和输入信号的有效值有关。

Vi是直接取蓝牙输出的还没过功放的小信号，振幅很小，所以实际上电路的带宽会很小，这是有利于做频率辨识的，以防谐波以及声音文件里夹杂的各种频率信号的干扰。

这里C2用的0.1uF，C3用的10uF。测量出来带宽在500～1kHz左右。

电源用5V，跟后端解码的单片机电压一致。

有18.5Khz输入的时候，8脚输出低电平。

焊好的板子如下～

声音部分

首先用一个叫做SweepGen的软件来做音频发生，用Total Recorder的虚拟声卡映射把生成的声音捕捉下来。

注意SweepGen和Total Recoder默认的电平和音量不是0db，记得调节到0db的原始声音状态。

在SweepGen里面记得把波形设置成正弦，因为18.5Khz的方波的谐波能听出来。

编辑声音妥妥的就得靠Adobe Audition了，cool edit是它的前身。其实声音生产也可以用它，只是我没找到在哪生成正弦波形。

在Audition里面可以看到，剪辑的声音频谱落点很明显。

解调部分

因为播放器在播放的时候可能会淡出淡入，以及蓝牙模块刚开始播放的时候会开启内部codec所以正式的编码数据前要加一段静音。

经过测试，18.5Khz的信号要维持50ms以上，LM567的输出低电平才跟着18.5Khz的持续时间接近，所以一帧数据长度暂时设置为50ms。

由于无输入的时候解调部分输出为高，所以同步头用一个低电平来做下降沿触发，在触发MCU这边的中断后对IO进行采样，1ms采样一次，50ms为一个帧，算上采样内执行延时，一帧共采样32次，超过16次为低就认为是0。

MCU用的是8051核的新塘N79E8132，2块钱一颗的单片机

采样的代码段：

for (cntbit=0;cntbit<8;cntbit++)

{

sample=0;

for(samcnt=0;samcnt<32;samcnt++)

{

sample=sample+(P0&0X1); //

Delay1ms(1); //read process

}//

//printf("sample%d = %d ",cntbit,sample);

if(sample <16) //HIGH/LOW LEVEL SET

{

state_t=state_t | (0x1

}

}

这里的delay是新塘的bsp包里用定时器标志位来做的，并且用一个IO反转测过执行延时才得出32次循环50ms的结果。

RC的频率是22M。

同步头设定为0101，后面四位作为命令位

比如01011110的波形就是下图

头尾1秒静音用来避免播放器的截头截尾效应导致数据不全。

下图是用示波器测蓝牙的音频输出和解调器的输出

黄色的CH1是解调器输出，蓝色的CH2是音频输入

下图是另外一组01011101的波形

基本出来这个波形，解调就不是问题了。

延时问题

如果你真的需要用LM567，以下这个问题你必须要考虑

咱们看图

LM567的鉴频脚 PIN8的锁定延时以及失锁以后恢复高电平的延时如图

锁定延时大概5ms

失锁的延时大概是10ms

而且锁定延时和失锁延时会浮动，不是每一次都一样。观察下来的结果，这个浮动多的时候会到上面数据的50%之多。

也就是表明，你的最小帧长度必须大于15ms的2倍+帧持续长度

这也是为什么一帧数据要50ms之长，并且要在一帧的采样周期里采样这么多次，还得用阈值来判别采样期间的电平的原因。