简介一份基于C语言的便携式肌电信号交互采集及云端平台完整项目包面向物联网、嵌入式及生物医学信号处理方向的毕业设计/课程设计开发者。方案以STM32F103RDT6为核心完成肌电信号采集、DMA连续扫描ADC、蓝牙5.0传输并配套Android移动端动态显示、边缘计算与云端上传链路兼顾硬件电路、嵌入式固件与上层应用。资源共1009个文件压缩包27.46MB主要包含561个C源码、250个H头文件、51个汇编文件及Keil/QT工程配置、Hex固件、文档说明等覆盖从底层驱动到界面交互的完整工程结构便于按模块检索学习。已有181人学习下载适合作为毕业设计、课程设计及项目开发的重要参考源码经过严格测试可直接编译运行帮助理解肌电信号处理、低功耗蓝牙通信、移动端多线程及云端数据流等关键实现。1. 便携肌电采集为什么选 C 语言边缘计算的入口到底在哪便携肌电设备要贴在皮肤上跑几个小时采样率上千赫兹还不能发烫、不能频繁充电。如果沿用服务器那套思路塞一块 Linux 板卡再跑 Python启动时间和功耗先把产品否掉了。C 语言在这个场景不是“老”而是把有限的 CPU、内存和电池预算压到极致的现实选择。整条链路里真正该做边缘计算的位置在电极后面那颗 MCU。原始肌电信号混着直流偏置、50Hz 工频和运动伪迹不先处理就往移动端推一秒波形几千字节蓝牙 BLE 扛不住。常见做法是在 C 代码里完成滤波、RMS 和活动段检测只把压缩结果发给手机。下面按“采集器侧 C 语言边缘计算 → 移动端实时显示 → 云端平台存储回放”的顺序拆开写给出可复现的信号处理代码、帧协议和存储思路适合做生物电采集、可穿戴设备和移动端联动硬件的工程师。2. C 语言端肌电采集与边缘计算从原始信号到特征压缩的落地实现2.1 采集前端选型电极、仪表放大器与 ADC 的电气边界肌电信号幅度从几十微伏到几毫伏信噪比不高。如果输入级噪声和共模干扰压不下去后边滤波做得再好也白搭。常见做法是电极后接仪表放大器INA 系列或者直接用集成前端。我一般用 ADS1292R 这类集成 ADC自带 PGA 和右腿驱动一个芯片同时解决微弱差分信号放大和 24 位转换。参数典型范围选择说明信号幅度20 µVpp - 5 mVpp取决于肌肉和电极位置静息时接近底噪主要能量20 - 150 Hz分析带宽一般取到 500 Hz 即可输入阻抗 10 MΩ匹配电极阻抗减小运动伪迹ADC 采样率500 - 2000 SPS实际常取 1000 SPS留出滤波过渡带共模抑制比 80 dB低于这个值工频纹波会明显淹没信号采样率的选择直接影响边缘计算量。肌电频谱主要能量在 20-150 Hz按奈奎斯特定理 500 Hz 就能采样但滤波器过渡带会挤占有效频段后续如果要算中值频率特征带宽也不够用。所以我通常把 1000 Hz 作为默认值这个数字能在时间分辨率和数据率之间取得较平衡的位置。2.2 SPIDMA 连续采样让 1 kHz 采样不占用 CPUADC 和 MCU 之间一般走 SPI每读一次样本约 6 到 9 字节。如果在中断里同步读取1000 Hz 的中断频率加上 SPI 等待时间CPU 占用率会高得没法做滤波。常见做法是用定时器触发 DMA 接收中断里只置一个标志位滤波和特征计算全部放到主循环。以 STM32 HAL 为例定时器中断里启动一次 SPI DMA 读取#define EMG_SAMPLE_RATE 1000u static uint8_t emg_spi_rx[9]; static volatile uint8_t emg_frame_ready; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM6) { /* 1 kHz 定时器 */ EMG_CS_LOW(); HAL_SPI_Receive_DMA(hspi1, emg_spi_rx, sizeof(emg_spi_rx)); } } void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi-Instance SPI1) { EMG_CS_HIGH(); emg_frame_ready 1; /* 主循环轮询这个标志 */ } }定时器预分频值和重装值由EMG_SAMPLE_RATE决定例如定时器时钟 16 MHz 时可用PSC15, ARR999得到 1 kHz 中断。emg_frame_ready必须声明为volatile因为在中断里被写、在主循环里被读避免编译器优化掉轮询。SPI 时钟极性、相位和字节序以你手头 ADC 的 datasheet 为准不要照抄同系列其他芯片的配置。注意每次定时器回调都启动一次 DMA如果上一次 DMA 还没完成就会丢样本。工程上常用乒乓缓冲两块 buffer 交替接收回调里只切换读写指针而不是复制数据。2.3 预处理高通、工频陷波和运动伪迹的 C 实现原始样本里有大量直流偏置和 50 Hz 工频。直流分量会导致 RMS 计算严重偏大工频干扰会让活动段检测误触发。常见做法是先做一阶高通滤直流再做双二阶陷波器滤工频。陷波器用 RBJ cookbook 公式设计C 代码如下typedef struct { float b0, b1, b2; float a1, a2; float x1, x2, y1, y2; } biquad_t; void biquad_notch_init(biquad_t *f, float fs, float f0, float bw_hz) { float w0 2.0f * 3.14159265f * f0 / fs; float alpha sinf(w0) * sinhf(logf(2.0f) * (bw_hz / fs) * w0 / (2.0f * sinf(w0))); float a0 1.0f alpha; f-b0 1.0f / a0; f-b1 -2.0f * cosf(w0) / a0; f-b2 1.0f / a0; f-a1 -2.0f * cosf(w0) / a0; f-a2 (1.0f - alpha) / a0; f-x1 f-x2 f-y1 f-y2 0.0f; } float biquad_run(biquad_t *f, float x) { float y f-b0 * x f-b1 * f-x1 f-b2 * f-x2 - f-a1 * f-y1 - f-a2 * f-y2; f-x2 f-x1; f-x1 x; f-y2 f-y1; f-y1 y; return y; }调用方式为biquad_notch_init(notch, 1000.0f, 50.0f, 10.0f)第三个参数是陷波中心频率第四个是带宽。bw_hz设 10 表示 45-55 Hz 范围内的衰减带因为电网频率不会严格卡在 50 Hz带宽太窄会在温度漂移后失效带宽太宽又会把相邻频段的肌电能量一起吃掉。系数全部用 floatCortex-M4F 自带 FPU 运行无压力如果你的 MCU 没有浮点单元需要把这组系数改成 Q15 定点实现否则每个样本跑几十次乘加会吃满 CPU。2.4 窗口特征RMS、过零率与活动段检测预处理完的数据仍然是一堆样本不能直接交给蓝牙。常用特征包括 RMS均方根、MAV平均绝对值、过零率和活动段标志。我一般以 256 个样本为一个窗口对应 256 ms1 kHz 采样率相邻窗口重叠 50%这样每秒产出约 8 个特征包。#define WIN_LEN 256u float emg_rms(const int16_t *buf, uint32_t n) { uint64_t sum 0; for (uint32_t i 0; i n; i) { int32_t v buf[i]; sum (uint64_t)(v * v); } return sqrtf((float)sum / (float)n); } uint32_t emg_zc(const int16_t *buf, uint32_t n, int16_t thr) { uint32_t cnt 0; for (uint32_t i 1; i n; i) { if ((buf[i-1] thr buf[i] -thr) || (buf[i-1] -thr buf[i] thr)) { cnt; } } return cnt; }过零率必须带阈值否则静息状态下的微小噪声也会不断穿越零点过零率会一直很高。thr通常取静息 RMS 的 1 到 2 倍只有在信号幅度真正超过噪声底时才计一次过零。活动段检测用滞回比较避免肌肉在阈值附近抖动时状态反复切换typedef struct { float threshold; float hysteresis; uint8_t on; } activity_t; uint8_t emg_activity_update(activity_t *det, float rms) { if (!det-on rms det-threshold) { det-on 1; } else if (det-on rms det-threshold - det-hysteresis) { det-on 0; } return det-on; }阈值初始化不能拍脑袋。我会先让用户静息 5 秒取这段 RMS 的中位数乘 3 作为threshold再取阈值的 30% 作为hysteresis。这个比例在不同电极贴合度下都相对稳定比固定绝对值可靠得多。2.5 把特征装进帧压缩后的输出协议特征计算完需要打包成紧凑的二进制帧再走 BLE 发给移动端。不要传 JSONJSON 的文本开销在嵌入式链路上是浪费。我用如下帧格式偏移长度含义02同步头 0xAA 0x5521类型 0x01 特征帧0x02 原始波形31包序号0-255 循环42ch0 RMS放大 100 倍存为 int1662ch1 RMS放大 100 倍存为 int1681活动状态 0/192CRC16-CCITT打包代码用#pragma pack取消对齐否则结构体内部会插入填充字节帧长度对不上#pragma pack(push, 1) typedef struct { uint8_t head[2]; uint8_t type; uint8_t seq; int16_t rms0; int16_t rms1; uint8_t activity; uint16_t crc; } emg_feature_frame_t; #pragma pack(pop) uint8_t emg_feature_frame_fill(uint8_t *out, uint8_t seq, float rms0, float rms1, uint8_t act) { emg_feature_frame_t *f (emg_feature_frame_t *)out; f-head[0] 0xAA; f-head[1] 0x55; f-type 0x01; f-seq seq; f-rms0 (int16_t)(rms0 * 100.0f); f-rms1 (int16_t)(rms1 * 100.0f); f-activity act; f-crc emg_crc16(out, sizeof(emg_feature_frame_t) - 2); return sizeof(emg_feature_frame_t); }RMS 放大 100 倍再存是因为 ADC 原始码值可能在几十到几百之间直接强转 int16 会把小数部分全部丢光。放大系数需要根据你实际的增益和基准电压调整不要固定写 100否则信号幅度大时 int16 会溢出。原始双通道数据按 1 kHz 算约 4 KB/s而特征帧每包 11 字节、每秒约 8 包总共不到 100 B/s这是边缘计算压缩数据量的直观体现。3. 移动端与采集器的数据通路帧协议、实时绘制与性能优化3.1 蓝牙 BLE 传输的选型与 GATT 结构采集器和移动端之间选 BLE 而不是经典蓝牙或 WiFi。BLE 4.2 之后的芯片普遍支持较长的 MTU功耗远低于经典蓝牙手机端也不需要额外配对流程。采集器做 GATT Server手机做 Client一个 Service 下放两个 Characteristic一个支持 Notify 用于上行特征帧一个支持 Write 用于下行控制命令。GATT 对象作用属性Service肌电数据服务0xFFE0Characteristic 1特征帧 Notify0xFFE1Characteristic 2移动端控制命令0xFFE2连接参数对实时性影响很大。手机通常会自动协商连接间隔写代码时可以根据采集频率申请 7.5ms 的间隔但也要接受手机拒绝后回退到 30ms。MTU 能协商到 185 以上时一个 Notification 可以装下十几帧特征数据减少手机侧中断次数如果只支持默认 23 字节 MTU则每包只能放 2 到 3 帧需要在帧协议里靠序号重组。3.2 从 Notification 到解析状态机不丢帧BLE 通知不保证次序和完整性尤其是连接间隔变化时特征帧可能在底层被分片或合并。移动端不能用“一次通知就是正好一帧”的假设需要做流式解析。我一般写一个逐字节状态机class EmgFrameParser( private val onFrame: (ByteArray) - Unit ) { private val buf ByteArray(64) private var len 0 fun push(data: ByteArray) { for (b in data) { buf[len] b while (len 2 (buf[0] ! 0xAA.toByte() || buf[1] ! 0x55.toByte())) { System.arraycopy(buf, 1, buf, 0, len - 1) len-- } if (len 11) { onFrame(buf.copyOf(11)) len 0 } } } }同步头错了就整体左移一个字节找到正确的帧边界后再按长度切帧。while而非if是因为损坏数据可能导致连续多个错位字节需要循环移位直到头匹配。帧长度从结构体定义看固定为 11 字节所以这里不用读长度字段如果以后要加变长波形帧应该先读 type 再决定帧长。提示这段代码里的buf.copyOf(11)在低频场景没问题但高频通知下每次分配都会产生短生命周期对象GC 会让曲线绘制明显掉帧。后面的对象池就是解决这个问题。3.3 显示与边缘计算的分工移动端只做重组和插值移动端拿到的是已经滤波和压缩的 RMS 特征不需要再做带通或陷波。重复做一遍边缘计算既消耗手机 CPU也没有信息增量因为陷波器会引入群延迟二次处理反而让波形相位更难对齐。移动端只做两件事按窗口时间戳重组成连续序列然后线性插值画曲线。如果调试时需要看原始波形可以设计一个“诊断模式”移动端发 Write 命令采集器切换 type 为 0x02按每包放 3 到 4 个 int16 原始样本的方式下发。这个模式只持续几秒不要长期开启否则蓝牙吞吐量和功耗都会回到不可用的状态。3.4 移动端性能优化循环缓冲让每帧分配降为零曲线绘制是移动端性能优化的重灾区。BLE 回调线程每收到一个特征包就invalidate()界面线程会在低端手机上被重绘请求淹没。我一般把数据写入循环缓冲再用 Choreographer 以 60 Hz 的频率统一刷新class WaveBuffer(private val capacity: Int) { val data ShortArray(capacity) var write 0 private var read 0 Synchronized fun put(v: Short) { data[write] v write (write 1) % capacity if (write read) read (read 1) % capacity } Synchronized fun snapshot(out: ShortArray) { for (i in out.indices) { out[i] data[read] read (read 1) % capacity } } }循环缓冲的好处是空间固定读写都在数组下标上移动不产生任何堆分配。put在 BLE 回调线程调用snapshot在 UI 线程调用加Synchronized保证两个线程不会同时踩坏下标。绘制时利用invalidate()之外还有一个细节onDraw里只画最近 500 ms 的点不要画整个会话的累积曲线否则 Canvas 绘制路径会越来越长卡顿只是时间问题。4. 云端平台的数据链路与部署上行、存储与回放4.1 上传统计特征而不是原始波形边缘端把 4 KB/s 的原始数据压成不到 100 B/s 的特征后移动端又做了一次聚合到此云端平台真正需要处理的数据体量已经很小。很多人拿着肌电项目的源码第一件事是把原始样本全部传到云端结果 1 小时产生约 14 MB 数据存储和带宽都不是问题问题在于查询、回放和分析时根本没有高效索引。我一般会把数据分为两类实时特征流和诊断波形段。实时特征流是常开的覆盖每一次肌肉收缩、放松的 RMS 和活动段标志诊断波形段只在用户主动触发时上传存储 10 到 30 秒原始信号即可。这样云端平台做统计分析时扫描的是特征表而不是扫原始波形。4.2 MQTT 主题设计与 QoS 选择移动端和云端之间建议用 MQTT 而不是轮询 HTTP。肌电特征是持续产生的流式数据HTTP 请求每个包都要建立连接头实时性也差。移动端作为网关把采集器发来的特征帧转换成 JSON 后发布到 MQTT broker。维度MQTTHTTP实时性长连接毫秒级推送轮询或长轮询秒级数据形态持续流式上行按请求拉取离线补传可复用离线主题需要自己管理任务队列典型位置实时特征上行管理接口、历史查询主题规划要能按设备维度和会话维度做隔离emg/{device_id}/{session_id}/feature emg/{device_id}/offline订阅方按设备维度订阅可以同时拿到多个会话的数据云端归档时按 session_id 分离。QoS 用 1采集过程要求至少一次不能丢数据但 QoS 1 会产生重复帧云端入库时要用唯一键去重。特征通知转成 JSON 的典型 payload 如下{ device_id: EMG-DEV-001, session_id: sess-20250213-1030, seq: 1823, ts_ms: 1739439000123, rms_ch0: 37.42, rms_ch1: 12.08, zc_ch0: 14 }seq是采集器上的原始序号不是移动端转发时重新编的ts_ms用移动端上传时的时间偏移量会引入几十毫秒误差但作为回放排序足够。真正要严格对齐动作时间轴时应该在采集器上维护单调时钟把 tick 一并放进 payload云端用 tick 而不是网络时间算时间差。4.3 云端时序存储的表设计特征数据按时间顺序写入查询通常按“某设备某会话某时间范围”进行适合用带分区的时间序列表。PostgreSQL 加 TimescaleDB 是常见的组合如果团队不想引入额外扩展原生 PostgreSQL 加按天分区也可以。CREATE TABLE emg_feature ( device_id TEXT NOT NULL, session_id TEXT NOT NULL, seq INT NOT NULL, ts TIMESTAMPTZ NOT NULL, rms_ch0 DOUBLE PRECISION, rms_ch1 DOUBLE PRECISION, zc_ch0 INT, PRIMARY KEY (device_id, session_id, ts, seq) ); CREATE INDEX idx_emg_feature_lookup ON emg_feature (device_id, session_id, ts DESC);复合主键里带上seq是为了在 QoS 1 重复投递时直接靠主键冲突跳过重复行不需要在业务代码里先查再插。rms_ch0和rms_ch1用浮点足够因为移动端已经做过一次特征聚合不需要把原始 ADC 码值精度保留到云端。索引顺序一定要把session_id放在ts前面否则按会话查询时用不到索引范围扫描。4.4 回放与补传接口历史回放走 REST 比 MQTT 更合适查询天然是请求-响应模型。数据量小的会话可以直接返回全量特征长会话要分页。接口设计如下curl -G http://127.0.0.1:8080/api/v1/sessions/sess-20250213-1030/segments \ --data-urlencode from1739439000 \ --data-urlencode to1739439300 \ --data-urlencode limit5000 \ --data-urlencode offset0from和to用 Unix 时间戳避免时区问题limit默认给 5000防止一次拉取把网关内存打满。移动端拿到数据后和本地缓存做一次seq对比发现缺失区间后从上一条断点开始向服务端请求补传。补传的数据也带有原始seq后端用相同的主键去重不会因为网络重试产生重复统计。5. 信号质量校准与滤波参数验证三步让边缘端结果可复现5.1 用 Python 先验算陷波器系数再烧进 CC 代码里陷波器系数来自 RBJ 公式手算容易把a1的符号写反导致滤波输出发散。我习惯先用 Python 复算一遍频响确认陷波深度和带宽再烧固件。import numpy as np from scipy.signal import freqz fs 1000.0 f0 50.0 bw 10.0 w0 2 * np.pi * f0 / fs alpha np.sin(w0) * np.sinh(np.log(2) / 2 * (bw / fs) * w0 / np.sin(w0)) b np.array([1.0, -2 * np.cos(w0), 1.0]) / (1 alpha) a np.array([1.0, -2 * np.cos(w0) / (1 alpha), (1 - alpha) / (1 alpha)]) w, h freqz(b, a, worN8192, fsfs) mask np.abs(w - f0) 1.0 notch_depth 20 * np.log10(np.abs(h[mask]).min()) print(f50Hz±1Hz 最小增益: {notch_depth:.1f} dB) flat_mask (np.abs(w - 80) 5) | (np.abs(w - 20) 5) flat_gain 20 * np.log10(np.abs(h[flat_mask]).max()) print(f通带最大增益: {flat_gain:.2f} dB)alpha的表达式要和 C 代码保持一致bw必须先除以fs再代入否则算出来的带宽会宽到把整个通带都吃掉。正常结果应该在 50 Hz 处出现至少 -20 dB 的凹陷而 20 Hz 和 80 Hz 附近增益接近 0 dB如果notch_depth只有 -5 dB先查sinh的带宽参数再查 C 代码里b0、b1有没有漏除a0。5.2 用差分法检验共模抑制与电极接触数据链路调试到最后问题往往不在代码而在模拟前端。最快速的检验方法是让设备在三种状态下各采集一段特征看 RMS 是否符合直觉测试状态预期 RMS可能问题静息 5 秒接近本底噪声若明显偏高查电极是否贴合握拳 3 秒至少为静息 5 倍若不到 2 倍查差分增益和信号线快速甩臂不应触发活动段若触发运动伪迹没滤干净静息和握拳的差异反映的是差分信号质量甩臂不触发活动段反映的是运动伪迹和陷波后的残留干扰。这两个结论无法靠代码 review 得到必须用真实信号验证。阈值标定时我会把静息 5 秒和握拳 3 秒的数据作为同一个 session 上传到云端先算出静息 RMS 中位数、握拳 RMS 中位数再回写设备侧的阈值参数。这两个时间窗口要写进 session 元数据云端回放时能直接把活动段对齐到动作时间轴后续更换设备或调整电极位置后也能用同一套数据重新标定。本文还有配套的精品资源点击获取