简介：4FSK（四频移键控）数字调制解调源码工程，面向需要理解四频移键控原理或基于Windows/MFC开发通信仿真软件的开发者。资源完整实现了4FSK发生器与解调器，涵盖D/A转换、频率合成以及包络检波、PLL等解调方法，并借助MFC类库提供图形界面，便于直观观察调制解调过程。压缩包共48个文件，以C++源代码（cpp/h）、Visual C++ 6.0工程文件（dsp/dsw）及编译中间文件（obj/sbr/pdb）为主，另含说明文档和图标资源，整体体积约5.98MB，目录结构清晰，可直接在VC6.0环境中打开调试。目前已有181人学习浏览，适合通信专业学生、嵌入式开发者及对数字调制有兴趣的入门者参考。通过阅读源码与运行Demo，读者可掌握4FSK信号生成的关键流程，理解检波判决逻辑，并学会在MFC框架下整合DSP算法与GUI交互，为后续无线通信项目开发提供可复用的工程模板和排错思路。

1. 4FSK解调为什么值得自己写一套：从频谱峰值到MFC落地的全链路

做无线数传或者仪器通信调试的人，大概率经历过这种场景：仿真程序里解调波形干干净净，一接到真实接收机或者从串口灌入录音数据，判决结果就开始反复跳变。4FSK（四进制频移键控）把一个符号的四个频点对应到两个比特，频谱效率比 2FSK 高了一倍，但解调端对频偏、符号定时和窗口截断的敏感度也成倍上升——任何一个环节处理不到位，误码率就会从千分之一直接掉到不可用。很多人拿到的 4FSK.zip 解调包里，往往只有一个核心解调函数，怎么在 MFC 界面里实时显示波形与频谱、怎么持续稳定出码、怎么抵抗频偏和定时抖动，全靠自己补齐。这篇文章从 4FSK 信号模型讲起，用 FFT 谱峰搜索作为主解调方案，给出可以直接照做的流程与 MFC 落地框架，并把频偏、窗口泄漏、定时抖动这三类最具杀伤力的工程问题单独拆开讲。适合正在做上位机工具、数据链测试或低速数传协议验证的开发者，也适合想把手里的 4fsk demodulation 代码从“能跑”改成“能用”的人。

2. 4FSK信号模型与解调选型：为什么优先用非相干谱峰判决

2.1 4FSK的频点映射与“两个比特放在一个符号里”的代价

4FSK 的调制思路并不复杂：把两个比特组合成 4 种符号，每种符号对应一个独立的载波频率。假设符号速率为 Rs，中心频率为 f0，相邻频点间隔为 Δf，那么四个符号的瞬时频率通常表示为 f0-1.5Δf、f0-0.5Δf、f0+0.5Δf、f0+1.5Δf。每个符号持续时间为 Ts=1/Rs，携带两个比特，所以比特速率 Rb=2Rs。相比 2FSK，同样带宽下可以传更多数据，这是 4FSK 最大的价值。

但代价也很实在：判决空间从“二选一”变成了“四选一”，四个频点在频谱上挤得更近。相同信噪比下，4FSK 的误符号率天然高于 2FSK，因为噪声能量更容易窜到相邻频点的判决区域内。频率间隔 Δf 的选取是关键，既不能太小导致四个谱峰混叠，也不能太大浪费带宽。工程上常见做法是取 Δf=(1~2)Rs，既能保证非相干检测时四个频点可分，又不会让频谱占用失控。

还需要理解一个容易被忽略的点：4FSK 是频率调制，信号本身没有固定的相位参考。接收端如果做相干解调，需要额外恢复出与发端完全同步的载波相位，这在低速数传和突发通信场景里成本很高。非相干解调只比较各频点上的能量大小，不需要相位信息，所以成为绝大多数 4FSK 接收方案的首选。

2.2 三种非相干解调方法的对比与选型依据

非相干解调听起来只有一个方向，但具体实现又分为几条路线。我在实际项目里先后试过过零检测、正交鉴频和 FFT 谱峰搜索，各自的行为差异很大。

过零检测是最朴素的做法：统计一个符号时间内信号穿过零点的次数，次数多说明频率高，次数少说明频率低。实现极其简单，一个计数器加一个比较器就能完成，但对噪声和直流偏置非常敏感。信号上叠加一点噪声，过零点就会来回抖动，统计结果在四个频点之间乱跳。只适合近距离、大频偏、信噪比要求不高的场景。

正交鉴频是模拟 FM 解调的数字化移植。把信号分别与 cos(2πf0t) 和 sin(2πf0t) 相乘得到 I/Q 两路，再用 I(n)Q(n-1)-I(n-1)Q(n) 这样的差分结构提取瞬时频率。它的优点是能连续输出频率估计，配合环路滤波器可以做频偏跟踪；缺点是 I/Q 两路的增益不平衡会直接反映为频率输出的谐波残留，校正起来很费劲。

FFT 谱峰搜索则是把每个符号窗口内的采样点做一次 FFT，找到功率最大的频点，再映射回符号。它的抗噪性能最好，因为 FFT 本身相当于对符号时间内的能量做相干积累，而且顺带能看出整个频谱的形状，对调试非常友好。代价是计算量比前两者大，但在 PC 级算力的 MFC 上位机上完全不是问题。三种方法的对比如下。

我一般会直接用 FFT 谱峰搜索作为主力方案，原因很简单：在 MFC 里做上位机，CPU 算力充裕，FFT 不仅能解调，还能顺手画出频谱给调试的人看。而且当频偏出现时，谱峰的偏移量可以直接读出来，比过零检测和鉴频法都直观得多。

2.3 解调链路框图与每个组件的职责

一个完整的 4FSK 非相干解调链路，按数据流向可以拆成六个环节：

• 幅度归一化或 AGC：把接收信号的幅度调整到 ADC 量程内，防止后续 FFT 结果被大信号饱和掩盖。
• 带通滤波：滤除带外噪声和邻道干扰，保留四个频点所在频带。滤波带宽通常取 4Δf 加上两倍频偏余量。
• 符号定时与分帧：确定每个符号的起始位置，把连续采样流切成一段段长度等于 Ts 的帧。定时不准是误码率飙升的头号原因。
• 加窗与 FFT：对每一帧乘以窗函数抑制频谱泄漏，再做 N 点 FFT。
• 谱峰定位与插值：在 FFT 结果里寻找最大幅值对应的频率索引，必要时用插值校正窗函数带来的频偏估计误差。
• 频点映射与并串输出：把估计频率与四个符号频率对比，取最近者作为判决符号，再把符号拆成两个比特输出。

每个环节都会直接影响最终误码率。幅度归一化做不好，AGC 增益抖动会淹没信号；带通滤波太窄，有频偏时直接把信号边缘切掉；符号定时错半个符号，FFT 结果同时包含两个相邻符号的能量，谱峰直接糊掉。后面第 5 章会集中讲这些坑的具体表现，先记住这条链路顺序就行。

3. 从采样数据到比特流：用FFT谱峰搜索做4FSK解调的最小实现

3.1 准备一个可复现的数据集：仿真生成4FSK信号

在没有真实接收机数据之前，先用仿真生成一段已知比特的 4FSK 信号是验证解调链路最稳的办法。这样可以精确控制信噪比、频偏和定时误差，任何解调异常都能对照已知比特定位原因。下面这段 Python 代码生成 128 个符号的 4FSK 信号，采样率 8000Hz，符号速率 200Bd，中心频率 1800Hz，相邻频点间隔 250Hz。

import numpy as np fs = 8000.0 # 采样率 Rs = 200.0 # 符号速率 Ts = fs / Rs # 每符号采样点数 = 40 f0 = 1800.0 # 中心频率 delta_f = 250.0 # 相邻频点间隔 # 四个符号频率：f0±0.5Δf, f0±1.5Δf sym_freqs = [f0 - 1.5*delta_f, f0 - 0.5*delta_f, f0 + 0.5*delta_f, f0 + 1.5*delta_f] # 生成随机比特流，并按两位一组映射到符号索引 0~3 bits = np.random.randint(0, 2, 256) # 256 bit = 128 symbol symbols = bits[0::2] * 2 + bits[1::2] # 高比特在前 # 逐符号生成连续相位正弦波 t = np.arange(int(Ts)) / fs signal = np.zeros(int(Ts) * len(symbols)) for i, s in enumerate(symbols): start = int(i * Ts) end = int((i+1) * Ts) signal[start:end] = np.cos(2*np.pi*sym_freqs[s]*t) # 叠加高斯白噪声，固定信噪比 10dB snr_db = 10.0 noise = np.random.randn(len(signal)) noise *= np.sqrt(np.mean(signal**2) / 10**(snr_db/10)) rx = signal + noise

这段代码有几个参数要留意。Ts 是每符号采样点数，这里 fs/Rs=40，意味着每个符号只有 40 个采样点，FFT 长度必须仔细选。符号映射采用“高比特在前”，也就是符号 3 对应二进制 11，符号 0 对应 00，这和后续判决映射必须保持一致。噪声功率按信噪比反推，先算信号平均功率，再除以 10^(SNR/10) 得到噪声方差，这是仿真里最常用的加噪方式。

3.2 分帧、加窗与FFT参数选择

解调的第一步是把连续采样流按符号周期切帧。理论上每 40 个点为一帧，但真实场景里符号起始位置未知，所以仿真阶段先从已知位置开始切，后面第 5.4 节再讲定时同步。切出来的每一帧先乘以窗函数再做 FFT，窗的选择直接影响谱峰定位的稳定性。

nfft = 128 # FFT 点数，含补零 window = np.hanning(int(Ts)) # 汉宁窗，长度等于帧长 def frame_fft(frame): # frame: 一个符号的采样点，长度 40 x = frame * window X = np.fft.rfft(x, nfft) freqs = np.fft.rfftfreq(nfft, 1/fs) return freqs, np.abs(X)

这里没有直接用 40 点 FFT，而是补零到 128 点。补零不会提高真实频率分辨率，但会让频谱曲线更平滑，谱峰位置的估算更稳定。实际分辨率是 fs/nfft=62.5Hz，而 Δf=250Hz，四个频点之间隔了约 4 个 bin，所以峰值不会混在一起。如果 Δf 再小，比如只有 100Hz，那就要考虑增大 nfft 或者直接对信号做更长帧的 FFT。

加窗前先想清楚：矩形窗的频谱泄漏最严重，旁瓣只衰减 13dB，噪声大时相邻频点的旁瓣会互相干扰；汉宁窗旁瓣衰减超过 30dB，但主瓣宽度变为矩形窗的两倍。在 250Hz 频点间隔下，汉宁窗的主瓣加宽后仍不会盖住相邻频点，所以优先用汉宁窗。只有当你确定频点间隔与 FFT 分辨率是严格整数倍关系且信噪比很高时，矩形窗才有优势。

3.3 谱峰搜索与符号判决：核心函数与判决门限

有了频谱就能做判决。对每一帧找到最大幅值对应的频率，然后看这个频率离四个符号频点哪个最近，直接映射成符号索引。这是最简实现，实际工程里还需要加一个判决门限，防止没有信号时把噪声尖峰当成有效符号。

def demod_one_frame(frame): freqs, mag = frame_fft(frame) peak_idx = int(np.argmax(mag)) f_est = freqs[peak_idx] # 抛物线插值，校正窗函数带来的峰值偏移 if 0 < peak_idx < len(mag)-1: y0, y1, y2 = mag[peak_idx-1], mag[peak_idx], mag[peak_idx+1] delta = 0.5 * (y0 - y2) / (y0 - 2*y1 + y2) f_est = freqs[peak_idx] + delta * (freqs[1] - freqs[0]) # 判决门限：峰值幅度需超过平均幅度的 3 倍才认为有效 avg_mag = np.mean(mag) if mag[peak_idx] < 3.0 * avg_mag: return -1 # 无效符号，可能无信号或信噪比过低 # 最近频点判决 dists = [abs(f_est - sf) for sf in sym_freqs] return int(np.argmin(dists))

代码里有两个容易被忽略的细节。一是抛物线插值，FFT 谱峰落在离散 bin 上，真实频率可能在两个 bin 之间，窗函数又会让谱峰变得圆钝，直接取 argmax 会有最大半个 bin 的偏差。用相邻三个点的幅值做抛物线拟合，可以把频率估计误差压到 bin 的十分之一以下。二是判决门限，用峰值幅度对整帧平均幅度做比值，而不是用绝对值，这样对 AGC 增益变化不敏感。门限取 3 倍是我在 10dB 信噪比下调试出的经验值，信噪比更高时可以适当降到 2 倍，更低时则要提高到 4 倍以上，否则噪声尖峰会被当成有效符号。

4. 用MFC把解调器做成上位机工具：界面线程与解调线程分离

4.1 MFC工程里如何组织解调类与界面类

很多人拿到 4FSK.zip 解调代码后，第一反应是把解调函数塞进对话框类的按钮响应里，点一下解调一段文件，界面卡死几秒钟再弹出来结果。这种做法在演示 Demo 里没问题，但做实时监测工具就必须把解调逻辑从界面线程里拆出去。

我一般先把第 3 章的 FFT 解调逻辑封装成一个独立的 C4FSKDemodulator 类，这个类不依赖任何窗口句柄，只接收 std::vector<double> 形式的采样数据，输出符号索引。界面类只负责两件事：把串口或文件读到的数据喂给解调类，把解调类返回的结果画出来。这样解调能在后台线程跑，界面拖动窗口时不会卡住。

class C4FSKDemodulator { public: void SetParams(double fs, double rs, double f0, double delta_f, int nfft); int DemodFrame(const std::vector<double>& frame, double& f_est); void GetSpectrum(std::vector<double>& mag); // 最近一帧的幅度谱，供界面绘制 private: double m_fs, m_rs, m_f0, m_delta_f; int m_nfft; std::vector<double> m_window; std::vector<double> m_last_mag; };

这个类设计上要克制：不要把波形绘制放到里面，不要让它知道窗口消息。界面需要频谱数据时调用 GetSpectrum 拿最近一帧的结果，解调线程和界面线程通过消息传递来交换数据。常见的做法是后台线程完成后向主窗口 PostMessage 一条自定义消息，消息参数带上解调出的符号值，主窗口收到后再触发重绘。

4.2 串口数据接入与缓冲区的环形队列设计

串口数据到达是不等节奏的，而解调要求按符号成帧。如果收到多少数据就立刻解调多少，会出现帧切在对齐位置之外的惨案。正确的做法是维护一个环形缓冲区，串口接收线程只往里写，解调线程按固定长度往外取，凑满一个符号帧就处理一次。

class CRingBuffer { public: explicit CRingBuffer(size_t capacity) : m_buf(capacity), m_cap(capacity), m_head(0), m_tail(0) {} size_t Push(const BYTE* data, size_t len) { // 返回实际写入长度，缓冲区满时丢弃最旧数据 } size_t Pop(BYTE* out, size_t len) { // 返回实际读取长度，数据不足时返回 0 } private: std::vector<BYTE> m_buf; size_t m_head, m_tail, m_cap; std::mutex m_mtx; };

串口回调里收到字节就 Push，解调线程每次尝试 Pop 一个符号帧长度的数据。注意这里缓冲区存储的是原始采样字节，可能是 uint8 或 int16，解调前需要转换成 double 并做幅度归一化。缓冲区容量至少要能放下 8~16 个符号帧，也就是 320~640 个采样点，否则串口突发数据会把未取走的数据冲掉。环形缓冲的好处是读写互不阻塞，Push 和 Pop 各自只移动自己的指针，加一个互斥量保护边界就够了。

4.3 波形与频谱绘制的双缓冲实现要点

MFC 里最常见的绘制翻车现场是在 OnPaint 里直接做 FFT 或者读串口，导致界面刷新一次要几十毫秒，拖动窗口时整个程序像死掉一样。频谱绘制一定要用最近一帧的缓存数据，而不是在绘制时现算。解调线程每处理完一帧，把幅度谱更新到 C4FSKDemodulator 内部，然后向主窗口 PostMessage 一个刷新消息。主窗口的 OnPaint 只做 BitBlt。

void C4FSKDemodulatorView::OnPaint() { CPaintDC dc(this); // 先画到内存 DC，避免屏幕闪烁 CDC memDC; memDC.CreateCompatibleDC(&dc); CRect rc; GetClientRect(&rc); CBitmap bmp; bmp.CreateCompatibleBitmap(&dc, rc.Width(), rc.Height()); memDC.SelectObject(&bmp); DrawWaveform(memDC); // 画接收波形缓存 DrawSpectrum(memDC); // 画最近一帧 FFT 幅度谱 dc.BitBlt(0, 0, rc.Width(), rc.Height(), &memDC, 0, 0, SRCCOPY); }

双缓冲的核心思路是先把所有图形绘制到内存 DC，最后一次 BitBlt 到屏幕，这样中间过程对用户不可见，也就不存在闪烁。波形数据和频谱数据都应该由后台线程更新到缓存数组里，OnPaint 只读缓存。还有一个细节：刷新消息不能每帧都发，否则 FFT 每 40 个采样点就触发一次重绘，界面会被消息洪水淹没。常见做法是限制刷新频率在 20~30Hz，让频谱看起来连续又不会拖累 CPU。

5. 4FSK解调常见问题排查：波形、频谱与误码的三个翻车现场

5.1 频谱峰值在边界bin跳变：Δf与FFT分辨率不匹配

现象：频谱图上四个峰的位置看起来正常，但解调出的符号序列里，某个符号经常在相邻两个值之间来回跳，误码率始终降不下去。用仿真数据验证时，信噪比已经很高了，问题依旧。

原因：FFT 分辨率 fs/nfft 和符号频点间隔 Δf 不是整数倍关系。峰值真实位置落在两个 bin 中间时，加窗后主瓣把能量摊到相邻多个 bin 上，最大幅值对应的 bin 会随着噪声随机落在左边或右边，判决结果跟着跳。这在 Δf 与分辨率接近时尤其严重。

解决：把 nfft 增大到 256 或 512，让每个频点至少占 4 个以上 bin；同时对幅值谱做抛物线插值，把真实峰值位置从离散 bin 中恢复出来。代码就是第 3.3 节里的 delta 计算，这个插值在频偏估计时同样有效。增大 nfft 的副作用是计算量上升，但对 MFC 上位机来说，256 点 FFT 连 0.1ms 都用不了。

5.2 载波频偏让四个频点整体漂移：符号映射边界失效

现象：接收频谱上的四个峰整体往一个方向偏移，偏移量超过 Δf/2 时，最外侧的符号被映射到邻居的判决区域。表现为误码集中在某个特定符号上，其他符号正常。

原因：收发两端晶振误差累计成载波频偏。比如发端 1800Hz 中心频率，收端本振实际是 1803Hz，四个频点全部偏移 3Hz。这个偏移量对过零检测和鉴频法可能不敏感，但对 FFT 谱峰判决是直接的系统性偏差。

解决：先用一段已知符号计算平均频偏，再把整个映射表平移。常见做法是在帧头插入一个固定导频符号，解调时把导频的估计频率减去已知频率得到偏置，后续每个符号的 f_est 都减去这个偏置再判决。第 6.1 节会给出实现。注意频偏估计要在解调前完成，并且每过一段时间要重新校准一次，因为晶振频偏会随温度漂移。

5.3 MFC界面卡死导致解调链路丢数

现象：界面刚启动时解调正常，一旦开始拖动窗口或者切换选项卡，解调结果出现大片连续丢码，重画停止后又能恢复。

原因：解调函数和频谱绘制都在主线程里执行。MFC 主线程要处理窗口消息时，如果解调正在跑几十毫秒的 FFT，窗口消息被阻塞；反过来窗口重绘占用主线程时，串口数据没人取，环形缓冲区被冲掉旧数据。两边互相拖累，本质是单线程做了两件事。

解决：把解调从主线程挪到工作线程，串口接收用单独的线程回调，主线程只做绘制。工作线程每解调完一帧，把结果 PostMessage 给主线程，主线程只更新显示缓存。环形缓冲区的读写要加锁，但锁的粒度要小——只在指针移动时加锁，不要在整段数据拷贝时加锁。我见过有人把整个解调放进临界区，串口一来数据就被堵死，反而更糟。

5.4 判决点落在符号切换沿：码元定时缺失

现象：误码率不是随机分布，而是呈现出某种周期性，比如每 4 个符号错 1 个。画波形时能看到，解调切帧的位置刚好压在两个符号的跳变沿上，一帧里同时含有前一个符号的尾巴和当前符号的头。

原因：4FSK 是频率调制，符号切换时频率会跳变，但幅度包络没有明显缺口，靠波形本身很难看出符号边界。如果直接用串口数据流按固定长度切帧，没有找到真正的符号起始位置，每一帧都包含跨符号的过渡区，频谱被两个频率的能量同时污染。

解决：在正式解调前做一次定时捕获。常见做法是对采样信号做鉴频处理，得到瞬时频率序列，然后计算频率跳变点的位置。频率突变的时刻就是符号边界。实际工程里可以用一个滑动窗口计算相邻两段信号的频率差异，差异超过阈值的位置即为边界。找到第一个符号起点后，以 Ts 为步长连续切帧，不再需要逐帧搜索。这个方法的精度可以做到一个采样点以内，足够支撑正常判决。

6. 把解调器变成可交付的工具：频偏自校正与误码率统计验证

6.1 用导频符号估算残余频偏并自动修正

解调链路跑通之后，下一步就是让它在真实数据上稳定工作。第一步是加频偏自校正。我一般会在每帧数据开头留出 4 个导频符号，发端固定发送符号 0 和符号 3 交替的模式。解调端把这 4 个符号的估计频率取平均值，减去已知频点，就得到当前频偏估计值。把这个值缓存起来，后续所有符号在判决前都先减去它。

// 导频频偏校正：已知导频符号索引与频点 double offset = 0.0; for (int i = 0; i < 4; i++) { // pilot_syms[i] 已知，比如 0, 3, 0, 3 double f_est; demod.DemodFrame(pilot_frame[i], f_est); offset += (f_est - sym_freqs[pilot_syms[i]]); } offset /= 4.0; // 平均频偏 // 后续判决前整体平移 f_est_corrected = f_est - offset;

这段代码的逻辑不复杂，但要注意 offset 的更新频率。静止场景下晶振频偏变化很慢，每几秒校准一次就够；如果接收机有温度漂移或者工作在移动环境，最好用滑窗持续估计 offset，比如每解调 100 个符号就用最近一段导频重新算一次。注意导频符号不要放在数据流中间太多，否则浪费有效带宽，4 个符号每 200 个数据符号校准一次是比较均衡的选择。

6.2 误码率统计与信噪比扫描验证

交付前一定要做一次成体系的误码率验证，不能只看几次解调“看起来正常”。我把验证过程固定为三步：固定信噪比跑 10000 个符号，统计误码率；改变信噪比从 0dB 到 15dB，画出误码率随信噪比变化的趋势；最后加一个固定频偏，确认校正逻辑确实把误码率拉回到正常水平。

int CountBitErrors(const std::vector<int>& rx_symbols, const std::vector<int>& tx_symbols) { // 比较符号级误码，再按每个符号 2bit 折算成比特误码 int err = 0; for (size_t i = 0; i < rx_symbols.size(); i++) { if (rx_symbols[i] < 0) { err += 2; // 无效符号算 2 bit 错误 } else { int xor_val = rx_symbols[i] ^ tx_symbols[i]; err += (xor_val & 1) + ((xor_val >> 1) & 1); } } return err; }

验证用的参考参数可以固定为一组：采样率 8000Hz、符号速率 200Bd、Δf 250Hz、nfft 128。这个配置下，10dB 以上信噪比基本可以做到近乎无误码，6dB 以下误码率会明显抬头。如果你的解调器性能比这个差很多，先回头检查符号定时和频偏校正，这两项是最大的性能杀手。贝叶斯一点说：噪声是公平的，但定时错误和频偏错误不是。

6.3 交付前的一项习惯：先看频谱再调参数

最后说一个我自己的习惯：每次拿到一段陌生采样数据，我不会直接跑解调，而是先画一帧频谱看看。四个峰的间隔是否均匀、整体是否有偏移、峰底是否太宽，这三个观察结果能直接告诉你参数该怎么调，比反复试解调结果高效得多。间隔不均匀说明 Δf 设错了；整体偏移说明频偏校正没生效；峰底太宽说明带通滤波太窄或者加窗不合适。这段频谱观察法帮我在无数个深夜少走弯路，虽然不是自动化流程，但比任何自动调参都管用。希望这篇 4FSK 解调的落地笔记，能帮你在自己的 MFC 工具里少踩几个坑，把 4fsk demodulation 真正变成能交付的工程能力。

本文还有配套的精品资源，点击获取