加速度传感器采集时无效数据的产生及消除

现象1 明显的上升沿

1.1 故障溯源

这是振动传感器的原始采样信号，它有一个明显的上升沿，这个上升沿，看时间轴标尺，大概持续了至少50ms，它是从哪里来的呢？

加速度传感器一般是由恒流源驱动的。而恒流源的原始电源输入是个经由电源模块整流后的电压源，所有的信号都不可能突变，在电源的手册里可以查到这个沿的数据：

上图中,SetupTime，500ms可以认为是冷启动时间。30ms的rising time就是电源一侧在负载发生变化时的上升时间。因为我们的电路后续还有电流源的建立过程。所以，最终在采样时，必须让出比如前50ms~100ms的时间。

 1.2.处理

第一，首先根据当前saps计算头部需要抛弃的点数：

int getMoreSapsCntOfDataSampleBegin(float saps)
{
    int moreSamplesIn100ms = ceil(100e-3*saps);
    if(moreSamplesIn100ms>= PT_OF_SENSOR_SHAKE_SAMPLE/2)
    {
        moreSamplesIn100ms = PT_OF_SENSOR_SHAKE_SAMPLE/2;
    }
    return moreSamplesIn100ms;
}

第二，修改单次批处理采样的点数（加上预采样修正点）

第三，在进行缓冲区整理拷贝时，抛弃掉前面的预采样点。

这个工作估计对示波器处理而言是个必修课。

1.3.修正后的加速度信号

现象2 数据出现断层

 这组加速度信号是一个数据传输错误，还是一些真实的冲击信号？注意啊，加速度传感器测量的核心是振动，冲击信号的变现是一组沿加速度信号零点位置，上下对称的一组冲击波，类似这样：

冲击信号会陡然冲到最大，然后振幅开始衰减——所以上面给出的加速度传感器数据一定是假的。

2.1 故障溯源及处理

还有一个必为故障信号的判定依据。积分后，可以求v_rms，你会发现那个值远远超过国标。这几乎可以立即作为判错依据。

2.1.1 采样率的限制

提示一下，所有的采集器的能力能不是无穷无尽的。你可能超出了采集器的工作能力，采集器的最高采样率saps会有一个上限。因为传感器往往组成阵列，而在多通道同步采样时，采集器的允许最高采样率会进一步降低，要特别注意这类指标。比如某采集器技术参数：

另外，如果采集器远端放置，可能还要考虑总采样点数的因素。如果采集器的缓冲区不足，会遭遇在和远端数据处理中断因为网络延迟而导致的数据丢失。

实际工作在修改采样率和确认网络状况后，可以尝试生成速度通道数据，取V_RMS，冲击信号对V_RMS的增量是有限的，一旦数据出现断层，会大大提升V_RMS的值，依据V_RMS可以轻松得到数据帧索引，进而快速定位到原始的采样数据帧。

2.1.2 数据拼接

接缝部分，最根本的原因其实是缓冲区拼接造成的。有没有注意到那个接缝很像现象一修正前的那个上升沿。。。是的，它就是源自那里。

多采集器同时工作，然后要把多个采集结果转入各个逻辑通道，就会很容易出现类似故障。

现象3 加速度信号的直流偏移

当你在真实地采集加速度传感器的信号时，你会发现最终的加速度信号总会有一个比较稳定的直流偏移，现在先不论它的原因是因为电路方面的0点偏移造成的，还是传感器的振动轴与重力的夹角，作为设计人员，你应该做去直处理吗？这个问题留作一个题目，有兴趣的同志可以把自己的想法写下来。

<end> Jun28,2024