Hi all. Before I dive in and trial-and-error my way to a sub-optimal solution, perhaps I could mine the forum's collective knowledge for some pointers on designing a capture system for vibration data?
I've not looked at signal processing for a very long time. I just about remember the principles of DFT/FFT, windowing etc. Any dummies guides you can point me at are welcomed.
The vibrations I'm interested in are in the frequency range 10Hz-10kHz, of the sort a large kitchen appliance might produce. I'd like to record segments of several minutes at a time. Getting raw data from the device is fine but even better if I can process these signals on-device to produce power spectral density data at, say, 1s intervals. Ultimately, I'm looking to train a statistical model on this data before deploying it back to the same device: a 'Tiny ML' proof-of-concept, if you like.
First question I have is: what kind of sensor should I be looking at employing? Will a 3-axis accelerometer with 2/4/8g sensitivity (something like this) be capable of measuring these vibrations? I've been reading datasheets which seem to indicate 1kHz might be an upper bound for data updates, does that crudely equate to the maximum sample rate?
Perhaps I could make my life a lot easier by just recording audio? I assume, other than losing the spatial component, the outputs would look rather similar?
Should I try to use analog sensors and sample with the onboard ADC or use an I2C version? I suppose the latter has some sort of buffer so I won't need to constantly read from the sensor?
Would I be better to stream the raw data out over a serial connection, or use something like a SD module to log the data? Feels like the latter would be more efficient providing I'm not opening and closing files frequently.
And lastly, can anyone recommend an efficient implementation of FFT? This library looks fairly straightforward but any recommendations are very welcome.
which seem to indicate 1kHz might be an upper bound for data updates, does that crudely equate to the maximum sample rate?
The data update rate is the sample rate.
For reasonably accurate signal recovery, the sample frequency should be at least 10 times the maximum frequency of interest. So 1 kHz sample frequency limits you to monitoring vibrations of up to 100 Hz. If you just want to know if vibration exists, then 500 Hz.
However, vibration at frequencies higher than (sample frequency)/2 in the equipment will lead to "aliasing artifacts" that may make the sensor output uninterpretable, in which case you would use an audio microphone instead.
You may want to note that in the first data sheet I linked to they cover frequency response. You mention I believe recording the data? Normally with the types accelerometers I linked to we come off the accelerometer and run the output to a charge amplifier where we can convert the pC/G. The signal is then recorded.
Attached is an example of measuring vibrations off a common household floor fan. You need to decide just how far you want to go and what engineering units? I assume G force and what axis? If you can get by with a simple ADXL3xx 3 Axis inexpensive accelerometer that would be great.
I would look at data rates and what you can expect to do .
Reading three axis at say 20khz will produce a lot of data over several minutes , you need to decide if you can process this in real time and what you do with it all . Sounds ambitious for Arduino - I’d probably go for a National instruments setup on a PC , which can do all that stuff
If you're going to be Fourier transforms the sample rate can be as little as 2.5x the max frequency of interest,
so long as you have an appropriate anti-aliasing filter with steep enough cutoff - you don't need lots of
oversampling, although that does make anti-aliasing much easier.
This sort of sampling is best done using a PC sound-card I think - just record like audio, simple.
So an analog output accelerometer through a DC-blocking capacitor is all you need really,
although many benefit from an I2C connection for configuring.
Regarding the suggestions of recording via PC: well, I mentioned tiny ML. Ultimately, I'm aiming to run a basic model with tflite micro for a 'condition monitoring' demo. So ideally, I'd use the same hardware for gathering training data as running inference to avoid dataset shift. Understand this is almost certainly making a rod for my own back, but it at least gives me an idea of what is possible.
Sounds as though these commodity accelerometers are too limited in frequency response and something like an I2S microphone might be a better choice? There's an example here that shows being able to plot audio sampled at 16kHz and 32 bit resolution. It should then be possible to log it to an SD card, I imagine.
I presume the available RAM on my MCU will dictate how long each continuous sample can be?
If you just want quick and dirty along with inexpensive I would look at acoustical sensors used on musical instruments. In an earlier post I linked to an accelerometer vibe sensor with an upper frequency limit of 32 KHz, they are not cheap. Anyway a cheap acoustical pickup fed into a PC MIC input. Then use either Windows or an audio program like Audacity to record. Audacity is pretty good and free.
