5
\$\begingroup\$

I have an MCU with an accelerometer, tightly mounted onto an AC motor inside a production hall.

Once an hour, it collects 1 sec. (Sample rate is 5000) of acceleration data for the motor and saves it.

When I try to display this data, I get these weird spikes:

Raw data from Accelerometer

Can somebody tell me, what these spikes/artifacts could be?

I'm sure my import/chart setup is correct, so I'm pretty sure it's an issue with my components.

Extra info: The components are located inside a plastic box that's mounted with a metal backplate. Everything should be electrically isolated from the AC motor. When testing in office environment (On a test motor), these spikes did not occur.

EDIT: I come from software - I'm pretty new to hardware and electronics, so bear with me, thanks! :-)

\$\endgroup\$
  • \$\begingroup\$ My guess is induced noise. Do you get those spikes if it is in almost the same location but not mounted to detect vibration? \$\endgroup\$ – DKNguyen Sep 11 at 13:53
  • \$\begingroup\$ @DKNguyen I have not tested that yet (I only have access to the production hall every now and then). But these spikes was first introduced in my results after I took the components in to the production. When I was sitting at my desk, I didn't have any issues. I also had an AC motor at my desk to test with, and this didn't produce the issue either. \$\endgroup\$ – Claes Zacho Sep 11 at 14:03
  • \$\begingroup\$ I don't know what your production hall looks like, but in my mind production halls are very different from office desks, even with a single AC motor. Maybe it or something it is mounted to is just getting banged every now and then from outside. Need more info. \$\endgroup\$ – DKNguyen Sep 11 at 14:05
  • \$\begingroup\$ @DKNguyen I think you might be right about it being induced noise. Asking as an electronics newbie, do you think the induced noise comes from the components them selves, or from external sources? Because you're right, there are a lot of different machines running near it. \$\endgroup\$ – Claes Zacho Sep 11 at 14:12
  • \$\begingroup\$ It's both but huge spikes like that tend to come from without rather than within. Noise from within components tends to be constant low levels similar to static. \$\endgroup\$ – DKNguyen Sep 11 at 14:13
8
\$\begingroup\$

The spikes seem to have a few common heights that are roughly related by factors of 2, which strongly suggests that they are noise-induced single-bit errors in the binary data.

One good way to address this is to take the standard deviation of all the data, and then simply throw away any samples that are more than, say, 2σ from the mean.

Another technique is to use a median-value filter, which looks at a sliding window of, say, 3 or 5 samples, and replaces the middle sample with the median value of the samples in the window. I've used this technique to remove "salt and pepper noise" (same problem) in video data.


Simply post-processing the data as described above might be adequate for your purposes of monitoring equipment health, etc. But if you want to find and fix the root cause of the bit errors, you'll need to focus on the digital communications paths in the system:

  • between the accelerometer and the MCU
  • between the MCU and the system where you're analyzing the data

Switching the plastic box to a metal one might be a good first step, especially for the upper bullet item. Shielded cable (if you're not already using it) would help with the second item.

\$\endgroup\$
  • 2
    \$\begingroup\$ Yes, data errors would be my suspect as well - but I'd consider design faults as well as induced error. One test worth doing is figuring out a way to mount a sensor in a similar environment but decoupled from the machinery and see if it still exhibits such spikes. Also worth checking bus timings (at least if SPI is used), and even looking for buffering faults in the software. \$\endgroup\$ – Chris Stratton Sep 11 at 14:23
  • 1
    \$\begingroup\$ Not necessarily, there is i2c interface that is connected to internal registers, there are timing caveats with i2c and spi sensors like this abound, detailed in the datasheet, just a suggestion to check that as well. \$\endgroup\$ – crasic Sep 11 at 15:01
  • 2
    \$\begingroup\$ Here is an example, your sample is near a byte boundary, 0x00ff and 0x0100 , the internal of the device might use a simple shift register for i2c interface. If this is not accounted for by the device designer , you can get a mixed sample on the bus 0x01ff . This is a somewhat annoying higher order issue with polling simple serial sampling devices in general. If one doesn't use i2c/spi or always uses the right devices and proper implementation perhaps they may never encounter it but I always try to sniff the bus and verify the system before committing to an electrical investigation. \$\endgroup\$ – crasic Sep 11 at 15:17
  • 2
    \$\begingroup\$ It's also possible to make sign extension errors when reassembling multibyte values in software which interprets them, and in quiet or unluckily biased settings to not see the issue until the low byte excursion reaches a value misinterpreted as "negative" \$\endgroup\$ – Chris Stratton Sep 11 at 15:31
  • 1
    \$\begingroup\$ Post processing works to an extent, and if it can be proven as electrical noise it is likely long term reliable if it is predictable, but timing issues I wouldn't leave as they are often inherently unpredictable, they fester and will pop up unexpectedly when you try to change the system or add features. \$\endgroup\$ – crasic Sep 11 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.