中值滤波算法分析报告

中值滤波在脉冲计量里的那点事：一段真实调试记录

先说个场景。我们做智慧供暖RTU时，设备要采集热计量表的脉冲信号，用来算供热流量和热量。有一阵子客户反复反馈"表没走，读数却偶尔跳几格"。最初怀疑传感器，一次次换件排查，最后才发现问题出在基线脉冲值的计算上——现场变频泵启停带来的电磁干扰，会在原始信号里混进毛刺脉冲，把基线直接顶偏，于是误判成"有脉冲"。

解决的办法就是中值滤波：把最近几次采到的脉冲放进一个环形缓冲区，取中间的那个值当基线，而不是简单求平均。平均会被极端毛刺带偏，中值不会。这就是这篇文章要展开的东西——不是理论课，而是一个能直接落地的调试记录。

1. 目前的实现长什么样

先看代码。原始脉冲存一个数组，滤波结果另存一个，环形缓冲区和基线值各占一个变量：

1.1 数据结构定义

// 原始脉冲数据数组
uint16_t p[300];

// 滤波后脉冲数据数组
uint16_t filtered_p[300];

// 脉冲历史数据（用于中值滤波）
uint16_t pulse_history[8];
uint8_t history_index = 0;

// 基线脉冲值
uint16_t baseline_pulse = 0;

1.2 中值滤波器实现

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  uint16_t temp[8];  // 固定大小8的临时数组
  uint8_t i, j;

  // 复制数据到临时数组
  for (i = 0; i < len; i++)
  {
    temp[i] = data[i];
  }

  // 冒泡排序
  for (i = 0; i < len - 1; i++)
  {
    for (j = 0; j < len - i - 1; j++)
    {
      if (temp[j] > temp[j + 1])
      {
        uint16_t t = temp[j];
        temp[j] = temp[j + 1];
        temp[j + 1] = t;
      }
    }
  }

  return temp[len / 2];  // 返回中值
}

这部分说白了就是"复制一遍，冒泡排个序，取中间那个"。`len` 固定传 8，正好和环形缓冲区一样大。第一次看到这段代码时我也没多想，直到排查跳变问题才意识到：参数传对传错、缓冲区会不会越界、取中值的下标靠不靠得住，这些"理所当然"的地方恰恰是坑。

1.3 调用流程

脉冲输入 → pulse_history[8] → update_baseline() → median_filter(pulse_history, 8)
                                                      ↓
                                            baseline_pulse = 中值

调用位置就在这里，关键就在 update_baseline 里：

void update_baseline(uint16_t pulse)
{
  pulse_history[history_index] = pulse;
  history_index = (history_index + 1) % 8;  // 环形缓冲区

  if (history_index == 0 && !baseline_valid)
  {
    baseline_valid = 1;
  }

  if (baseline_valid)
  {
    baseline_pulse = median_filter(pulse_history, 8);  // 调用中值滤波
    // ...
  }
}

2. 参数传对了吗：顺着数据流捋一遍

排查阶段我先把整条数据流从头到尾画了一遍，确认每个环节传进去、传出来的数组和长度是不是对得上。下面这张图是我当时的笔记：

2.1 数据流向

┌─────────────────────────────────────────────────────────┐
│ 数据流                                         │
├─────────────────────────────────────────────────────────┤
│                                                 │
│ 1. 脉冲输入 → raw_pulse_buffer[300]             │
│                                                 │
│ 2. 处理 → data_processing_pipeline()              │
│                                                 │
│ 3. 滤波 → moving_average() (8点窗口)           │
│                                                 │
│ 4. 更新历史 → pulse_history[8] (环形缓冲区)     │
│                                                 │
│ 5. 中值滤波 → median_filter(pulse_history, 8)     │
│                                                 │
│ 6. 输出 → baseline_pulse                        │
│                                                 │
└─────────────────────────────────────────────────────────┘

2.2 参数传递验证

捋下来的结论很直接：len=8 和所有相关数组的大小都对得上，参数传对了，不是这条链路的问题。真正的隐患在后面——函数内部。

3. 隐患其实藏在这两个地方

函数内部真正让人不放心的是两点：一个写死的临时数组，和一个几乎没做的参数校验。眼下 `len=8` 碰巧都安全，可这不是写的代码该有的样子。

3.1 数组大小写死了

问题在 median_filter 内部用了个固定大小的临时数组：

uint16_t temp[8];  // 固定大小8

眼下的坑就在这儿：靠 `len=8` 和 `temp[8]` 恰好对上，暂时还没越界；可将来一旦有人把 `len` 加大，数组就会越界，代码里却没有任何一道防护拦着。

风险分两头说：当下因为 `len=8` 和 `temp[8]` 正好匹配，属于低风险；可一旦改了 `len` 却没同步改 `temp` 大小，就直接落到中等风险了。

3.2 参数校验基本没做

更实在的一点：函数压根不检查传进来的 len。

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  uint16_t temp[8];  // 没有检查 len <= 8
  // ...
}

这么写带来的隐患有两个：len > 8 时数组直接越界，len == 0 时取中值的地方（temp[len / 2]）又会除零。建议很直接——进函数先把参数校验补上。

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  if (len == 0 || len > 8) return 0;  // 添加验证

  uint16_t temp[8];
  // ...
}

4. 窗口到底开多大：纠结过的权衡

跳变问题排查到这儿，我停下来认真想了想窗口长度。中值滤波的窗口（也就是 `len`）直接决定了两件事：压得住多少噪声，以及能不能跟上真实信号的变化。窗口太小，毛刺压不掉；太大，反应又太迟钝。下文把性能和效果一表一表摊开看。

4.1 当前的 len=8 行不行

4.1.1 计算效率

计算复杂度拆开算就是下面这两笔账：

比较次数 = n(n-1)/2 = 8×7/2 = 28次
时间复杂度 = O(8²) = O(64)

4.1.2 滤波效果

滤波效果上，对单点脉冲噪声几乎全抑制，随机噪声也压得明显；唯一打折扣的是周期性噪声——中值滤波本质上不擅长对付它，那种情况得另想办法（比如转成频域处理）。保真度这边，边缘保持得好、不会过度平滑，延迟也低，4 个样本就出结果，很适合实时系统。基线这块，8 个样本就能建起稳定基线，跟踪快、抗干扰强——这正是它能治住跳变问题的底气。

4.2 不同长度对比分析

4.2.1 计算复杂度对比

单纯看计算量，`len=8` 在实时系统里完全站得住；加到 12 以后 CPU 负载会明显抬头；压到 4 以下又压不住噪声。这个区间里，8 是个不偏不倚的选择。

4.2.2 滤波效果对比

滤波效果上也是这一套规律：`len=8` 在"压得住噪声"和"保得住细节"之间平衡得最好。窗口再大就开始过度平滑、把真实细节抹平；太小又压不住干扰。对表里的综合评分，直觉和数字是吻合的。

4.2.3 边缘效应分析

先说清"边缘效应"（Edge Effect）这个概念：它指的是滤波器在数据边界处的表现。

边缘效应这块，`len=8` 属于"能接受"的水平——好在我们用了环形缓冲区，把数据边界带来的影响缓解了不少，8 个样本的恢复期也不算拖沓。

5. 现场信号是啥脾气：先摸清噪声底数

选窗口不能拍脑袋，得先摸清现场信号到底长什么样、噪声是哪一种。结合系统设计和我们在现场抓的数据，大致是这个底数。

5.1 脉冲信号特征

脉冲信号的主要参数如下：

5.2 噪声特性分析

5.2.1 主要噪声源

电磁干扰 (EMI)：表现为随机脉冲噪声，幅度高（可达信号幅度的50-100%），持续时间短（1-2个样本），偶发。

量化噪声：低幅度随机噪声，幅度低（±1-2个计数器值），持续存在，频率高。

传感器噪声：低频波动，幅度中等（±5-10%），持续时间较长，频率低。

5.2.2 滤波器适应性

这正好对上了现场噪声的构成（电磁干扰毛刺、量化噪声、传感器低频波动）——`len=8` 对三种都有不错的表现，选型时是个很踏实的结论。

6. 性能账要算清楚

做产品，尤其是实时采集的固件，CPU 占用和内存都得心里有数。这块我们把计算量和内存分别估一估，确保窗口别拖垮整个主循环。

6.1 计算效率分析

6.1.1 当前实现 (len=8)

// 每次调用的计算量
比较次数: 28次
交换次数: 平均14次
总操作数: ~42次

// 执行时间 (@16MHz)
每次调用: 5-10μs
1kHz频率: 5-10ms/秒 (0.5-1% CPU)
10kHz频率: 50-100ms/秒 (5-10% CPU)

6.1.2 不同len的计算量

结论：`len=8` 的 CPU 占用对我们这套系统绰绰有余；窗口加到 12 以上才开始显出负担；压到 4 虽然省电，但滤波质量就守不住了。

6.2 内存使用分析

6.2.1 当前实现

// 内存使用
pulse_history[8]: 16字节 (8 × uint16_t)
temp[8]: 16字节 (8 × uint16_t)
总计: 32字节

6.2.2 不同len的内存使用

内存这块不用太担心——STM32L0 的 RAM 很充足，`len=8` 才占 32 字节，怎么调都宽裕。真正要盯的只有上面算的那笔 CPU 账。

7. 不同现场频率下的表现

数值分析终归要落到场景。我们这批设备实际在 100Hz、1kHz、10kHz 三档脉冲下跑过，分别说说体会。

7.1 低频场景 (100Hz)

这一档脉冲间隔 10ms，处理时间很充足，噪声也相对较少。

`len=8` 在这种现场有点"杀鸡用牛刀"的意思——毛刺基本压得干干净净，CPU 占用几乎可以忽略，基线也稳。结论：保持 `len=8`，不用折腾。

7.2 中频场景 (1kHz)

这一档脉冲间隔 1ms，处理时间适中，噪声中等。

`len=8` 依然合适：滤波效果良好、CPU 只占约 0.7%、基线稳定。这一档也保持 `len=8`。

7.3 高频场景 (10kHz)

这一档脉冲间隔只有 0.1ms，处理时间紧张，噪声也偏多。

`len=8` 滤波效果依然在线，基线也稳，但 CPU 占用抬到了约 7%，偏高。真要长时间在 10kHz 满速跑，得考虑优化排序算法——窗口先不换。

8. 该动哪些地方：我的优化顺序

下面是我实际动手改的顺序，从改动最小、风险最低的开始，逐步往上加。核心判断没变——窗口保持 `len=8` 不动。

8.1 短期优化 (保持len=8)

这几项属于"当天就能上"的改动，先把代码做扎实。

8.1.1 添加参数验证

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  // 参数验证
  if (data == NULL || len == 0 || len > 8)
  {
    return 0;
  }

  uint16_t temp[8];
  uint8_t i, j;

  for (i = 0; i < len; i++)
  {
    temp[i] = data[i];
  }

  for (i = 0; i < len - 1; i++)
  {
    for (j = 0; j < len - i - 1; j++)
    {
      if (temp[j] > temp[j + 1])
      {
        uint16_t t = temp[j];
        temp[j] = temp[j + 1];
        temp[j + 1] = t;
      }
    }
  }

  return temp[len / 2];
}

这层校验花不了几行，换来的是三个实打实的好处：代码更抗造、不会静默越界、出问题时好定位。

8.1.2 优化排序算法

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  if (data == NULL || len == 0 || len > 8)
  {
    return 0;
  }

  uint16_t temp[8];
  uint8_t i, j;

  // 复制数据
  for (i = 0; i < len; i++)
  {
    temp[i] = data[i];
  }

  // 使用选择排序（对小数组更高效）
  for (i = 0; i < len / 2 + 1; i++)
  {
    uint8_t min_idx = i;
    for (j = i + 1; j < len; j++)
    {
      if (temp[j] < temp[min_idx])
      {
        min_idx = j;
      }
    }
    // 交换
    if (min_idx != i)
    {
      uint16_t t = temp[i];
      temp[i] = temp[min_idx];
      temp[min_idx] = t;
    }
  }

  return temp[len / 2];
}

一头一尾的收益：比较次数从 28 次降到约 20 次，CPU 占用少三成左右，滤波效果一分不差。

8.1.3 使用快速选择算法

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  if (data == NULL || len == 0 || len > 8)
  {
    return 0;
  }

  uint16_t temp[8];
  uint8_t i;

  // 复制数据
  for (i = 0; i < len; i++)
  {
    temp[i] = data[i];
  }

  // 快速选择算法（平均O(n)）
  uint8_t low = 0;
  uint8_t high = len - 1;
  uint8_t median = len / 2;

  while (low < high)
  {
    uint16_t pivot = temp[median];
    uint8_t i = low;
    uint8_t j = high;

    while (1)
    {
      while (temp[i] < pivot) i++;
      while (temp[j] > pivot) j--;
      if (i >= j) break;

      uint16_t t = temp[i];
      temp[i] = temp[j];
      temp[j] = t;
    }

    if (i < median) low = i + 1;
    else high = i;
  }

  return temp[median];
}

这套算法更激进一点：比较次数平均压到约 15 次，CPU 占用能省近一半，效果同样不打折。唯一代价是实现稍绕，要看团队能不能维护住。

8.2 中期优化 (考虑调整len)

如果现场噪声变化大，可以进一步让窗口自适应性强一点，以下是两个方向。

8.2.1 自适应滤波器长度

uint8_t adaptive_median_len = 8;

uint16_t adaptive_median_filter(uint16_t *data, uint8_t len)
{
  // 根据信号特性自适应调整
  uint16_t variance = calculate_variance(data, len);

  if (variance < 100)
  {
    adaptive_median_len = 4;  // 低噪声：小窗口
  }
  else if (variance < 500)
  {
    adaptive_median_len = 8;  // 中等噪声：中等窗口
  }
  else
  {
    adaptive_median_len = 12; // 高噪声：大窗口
  }

  return median_filter(data, adaptive_median_len);
}

好处是让窗口跟着实际噪声水平走：噪声大了自动开大窗口，安静了又收回来，在"滤波效果"和"实时性"之间自动找平衡。

8.2.2 分层滤波

uint16_t layered_median_filter(uint16_t *data, uint8_t len)
{
  // 第一层：粗滤波（len=4）
  uint16_t coarse = median_filter(data, 4);

  // 第二层：细滤波（len=8）
  uint16_t fine = median_filter(data, 8);

  // 加权组合
  return (coarse + fine * 3) / 4;
}

把粗滤（小窗口）和细滤（大窗口）按权重拼起来，能用较小的实时代价换更高的滤波质量。实测在干扰偏重的现场，这套对猝发噪声更顶用。

8.3 长期优化 (算法改进)

8.3.1 使用更高效的算法

选项1: 插入排序

• 对小数组效率高
• 时间复杂度: O(n²)
• 但常数因子小

选项2: 堆排序

• 对大数组效率高
• 时间复杂度: O(n log n)
• 但对小数组可能不如冒泡排序

选项3: 快速选择

• 平均时间复杂度: O(n)
• 最坏情况: O(n²)
• 适合找中值

8.3.2 使用硬件加速

选项1: DMA加速

• 使用DMA进行数据复制
• 减少CPU干预

选项2: DSP指令

• 使用STM32的DSP指令
• 加速排序操作

9. 我的建议：窗口别动，代码补强

9.1 一句话结论

综合前面的分析，落到动作上其实就三条：窗口保持 `len=8` 不动，把参数校验补上，再按需优化一下排序算法。下面把理由和适用场景说清楚。

9.1.1 主要建议：保持len=8

这么选理由很朴素：`len=8` 在计算效率和滤波效果之间平衡得最好，对主要噪声类型都压制到位，还能保住信号边缘和细节；CPU 占用不过 0.7-7%、内存只占 32 字节，边缘效应 8 个样本就能恢复。覆盖场景也够——100Hz 到 10kHz 的脉冲都能跑，混着来也没问题，换句话说我们现有的场景全部适用。

9.1.2 次要建议：优化算法

第一件事，把参数校验补上，进函数先拦一道，别让非法输入往下走：

if (data == NULL || len == 0 || len > 8)
{
  return 0;
}

第二件事，按需优化排序算法，方向是选择排序或快速选择——比较次数能降 30-50%，CPU 占用跟着下来。

第三件事，用宏把滤波长度定义出来，以后要改只动一处：

#define MEDIAN_FILTER_LEN 8

uint16_t pulse_history[MEDIAN_FILTER_LEN];
uint16_t temp[MEDIAN_FILTER_LEN];

baseline_pulse = median_filter(pulse_history, MEDIAN_FILTER_LEN);

9.2 不建议调整 len 的理由

9.2.1 把 len 加到 8 以上

把 `len` 调大基本是得不偿失：CPU 占用显著抬升、信号延迟变长，大窗口还会过度平滑、把真实细节抹掉，边缘效应也更严重，而来之不易的滤波效果提升却很有限。这一档不推荐动。

9.2.2 把 len 减到 8 以下

调小 `len` 换来的问题是噪声压不住、基线波动大，还会因为判断区间太窄把正常脉冲误判成异常。除非现场噪声低到可以忽略，否则不建议这么干。

10. 落地节奏

落地顺序上我不主张一上来就上复杂算法。先把参数校验和宏定义做掉——当天就能完，风险最低；再根据现场实际的 CPU 占用，评估要不要换排序算法。自适应和分层滤波属于"噪声真的复杂到搞不定"时才值得上，优先级靠后；至于 DMA 这类硬件加速，目前看是过度设计，先不动。

11. 测试验证

11.1 功能测试

测试1: 参数验证测试

// 测试NULL指针
uint16_t result = median_filter(NULL, 8);
assert(result == 0);

// 测试len=0
result = median_filter(pulse_history, 0);
assert(result == 0);

// 测试len>8
result = median_filter(pulse_history, 16);
assert(result == 0);

测试2: 滤波效果测试

// 测试脉冲噪声
uint16_t test_data[8] = {100, 1000, 100, 100, 100, 100, 100, 100};
uint16_t result = median_filter(test_data, 8);
assert(result == 100);  // 应该过滤掉1000

// 测试正常数据
uint16_t test_data2[8] = {100, 101, 102, 103, 104, 105, 106, 107};
result = median_filter(test_data2, 8);
assert(result == 103);  // 中值

11.2 性能测试

测试3: 执行时间测试

uint32_t start = DWT->CYCCNT;
for (int i = 0; i < 1000; i++)
{
  median_filter(pulse_history, 8);
}
uint32_t end = DWT->CYCCNT;
uint32_t avg_cycles = (end - start) / 1000;
printf("Average cycles: %lu\n", avg_cycles);

测试4: CPU占用测试

// 测量1kHz下的CPU占用
uint32_t start_time = HAL_GetTick();
uint32_t interrupt_count = 0;

while (HAL_GetTick() - start_time < 1000)
{
  median_filter(pulse_history, 8);
  interrupt_count++;
}

float cpu_usage = (interrupt_count * 10) / 1000.0f;
printf("CPU usage: %.2f%%\n", cpu_usage);

11.3 对比测试

测试5: 不同len对比

// 测试len=4, 6, 8, 10, 12
for (uint8_t len = 4; len <= 12; len += 2)
{
  uint32_t start = DWT->CYCCNT;
  for (int i = 0; i < 1000; i++)
  {
    median_filter(pulse_history, len);
  }
  uint32_t end = DWT->CYCCNT;
  uint32_t avg_cycles = (end - start) / 1000;
  printf("len=%d, avg_cycles=%lu\n", len, avg_cycles);
}

12. 一句话收尾

12.1 这件事最终怎么定的

回到开头的跳变问题——加上中值滤波并保持 `len=8` 后，现场读数就没再乱跳过，问题算正式关单。整体来看，这套实现的性能、滤波效果、稳定性、适用性都够用，唯一显得单薄的是健壮性：参数校验没做。

12.2 最终建议

核心：保持 len=8，把算法实现做扎实。理由很朴素——它在性能和效果之间平衡得最好，覆盖现有全部场景，CPU 占用也可接受。

具体动作，按优先级排

1. 马上做——补参数验证
2. 短期做——优化排序算法
3. 看情况做——自适应滤波器
4. 先不做——硬件加速（目前属于过度设计）

两个方向我明确不建议碰：把 `len` 加到 8 以上（CPU 占用过高、收益有限），或者减到 8 以下（压不住噪声）。

12.3 做完之后的好处

把这几点落地，预期能看到：CPU 占用降 30–50%，代码健壮性明显提升，用宏定义后参数更好维护、也更方便以后调整。

附录

A. 参考数据

A.1 测试数据样本

// 正常脉冲数据
uint16_t normal_data[8] = {100, 101, 102, 103, 104, 105, 106, 107};

// 脉冲噪声数据
uint16_t pulse_noise_data[8] = {100, 1000, 100, 100, 100, 100, 100, 100};

// 随机噪声数据
uint16_t random_noise_data[8] = {100, 102, 98, 103, 99, 105, 97, 104};

A.2 性能基准数据

B. 代码示例

B.1 完整的优化实现

#define MEDIAN_FILTER_LEN 8

uint16_t median_filter(uint16_t *data, uint8_t len)
{
  // 参数验证
  if (data == NULL || len == 0 || len > MEDIAN_FILTER_LEN)
  {
    return 0;
  }

  uint16_t temp[MEDIAN_FILTER_LEN];
  uint8_t i, j;

  // 复制数据
  for (i = 0; i < len; i++)
  {
    temp[i] = data[i];
  }

  // 选择排序（对小数组更高效）
  for (i = 0; i < len / 2 + 1; i++)
  {
    uint8_t min_idx = i;
    for (j = i + 1; j < len; j++)
    {
      if (temp[j] < temp[min_idx])
      {
        min_idx = j;
      }
    }
    // 交换
    if (min_idx != i)
    {
      uint16_t t = temp[i];
      temp[i] = temp[min_idx];
      temp[min_idx] = t;
    }
  }

  return temp[len / 2];
}

C. 参考资料

• 数字信号处理基础
• 中值滤波器理论
• STM32L0参考手册
• 实时系统设计原则

还想接着看

如果你也在做嵌入式信号处理或物联网采集，下面几篇大概率能接着帮上忙：

• 传感器温度补偿指南——与滤波配合，把传感器温漂一起压下去，采集链路才真正稳。
• STM32定时器与PWM配置指南——本文的脉冲采集就建立在定时器中断上，配置细节不踩坑。
• STM32 / ESP32 / GD32 选型对比——换平台前先把 MCU 的坑捋一遍，少走弯路。

这篇调试记录整理自智慧供暖 RTU 项目。如果你手头也有类似的信号毛刺或基线漂移问题，欢迎按页尾的方式联系我们，聊聊你们的现场。