Sampling Analog accelerometer

Hello Everyone,

I am new to Arduino, Microcontrollers and Electronics in general but Iam already reading Manuals and looking at projects similar to mine to learn as much as possible. My project is building a vibrtaion monitoring system for a machine's pump. So what I need to do is read data from an accelerometer to the computer throught he Arduino and save it for future analysis (and I want to read data for few days not just several minutes so the whole system will be running for few consecutive days).

I chose a triple axis analog accelerometer with Bandwidth 6KHz since high frequency components may be present in the measured signal. So I need to sample at atleast twice the bandwidth to get reliable data. Lets say I want to sample at 15KHz. But after so much research, I understood that Arduino Uno for example samples at most 10Khz because of the 100us to read an analog value. And in case we decreased this 100us value by decreasing the prescale factor in order to increase the maximum sampling rate, then we may loose resolution and this may affect the vibration readings.

Now lets say we can succesfully sample at the required data rates. I need to send this data serially through USB to the computer for a long period of time (probaably few days) and then save it for some analysis.

So my basic questions are: Can I use a certain Arduino model (Due for example) to do the Sampling at the required rate reliably and serial communication reliably? And what is the baud rate to use? In case something is not clear in the description please let me know. Thank you for any opinions!!

If you want to get the true motion vector and it's magnitude then you will need to use three ADCs with synchronous triggers or a 3DOF accelerometer with digital output, most do. The Teensy 3.2 has dual ADCs but none have three. The question becomes, can you get the data out of the sensors and into the PC and maintain a 15Ksps rate. The Arduino serial link can easily run at 2Mbps through an FTDI adapter to the PC's USB port. The Due is fast compared to other Arduinos and has lots of I/O pins. Look at some of the Pi boards as there may be one more suitable for your project.

Thank you for your reply!

I should have made it clear that i want to read just two of the axis. If I got it right, I can't use an Arduino Due to read tho analog outputs and serially communicate with PC beacuse it just have one ADC? So in general one cannot read values of two analog sensors to Arduino? And the baud rate is not a problem as you said, but what do you think about the 15Khz sampling rate. I know It can be achived by others microcontrollers such as Pi, but can this be achieved by Arduino Due for example still collecting reliable data?

Thanks again

The Teensy 3.2 has dual ADCs, 12 bit, that can be used in a synchronous read. You can use a timer interrupt to trigger the ADCs. I have two running at 62.5Ksps collecting data from a phased array sonar. There is an example in the TeensyDuino V1.27 library. It also has three extra hardware serial ports that can be pushed to 4.5Mbps. Check out the PJRC.com website for details.

Ok, Thank you!!

Be careful with the ADC 'result' output as it's a structure with two uint32_t components. You can send it as uint16_t( result.result_adc0 ) and uint16_t( result.result_adc1 ) to avoid sending four zero bytes with each sample.

I got that, thanks! Another question that came to my mind. Lets say I am sampling at 15KHz, then I am reading 30K analog values every second (since 2 axis). Cant I program the microcontroller to do ADC on those 30K values (using 1 ADC) and then send them serially? Which means now that I need a baud rate of 30Kreadings/sec * 20Bits/reading/sec=600K bps? But now I can see that in this case the ADC of the analog readings of each axis are not done at the same time but still I can have the data reliably on my pc for further analysis?

If you use one ADC then there will be a phase lag between the two data values giving a false vibration angle result. It will also take twice the time for a full capture. At 15Ksps you have 67usec loop time. Two sequential reads are about 32usec based on what I found with the Teensy. A dual synced ADC read is 16usec. However, transferring four bytes at 2Mbps is 16usec. You can push the Teensy to 4.5Mbps but the serial/USB adapter may not like that rate. So now you've consumed 32usec in just capture and transfer time and not accounting for any processing task. If you're very careful in your coding then you might be able to pull it off. However, if it's close then be prepared to lower your sampling rate to 2.2x of the high frequency corner.

If the above does not work then the ADC14C105 will sample at over 100Msps with a 14 bit parallel output. The data can be read using direct port manipulation. You may also have to switch to the Due to get enough pins. A pair of ADCs with synced capture would get the data fast enough but you may have to find a faster scheme of getting the data into the PC. USB3 and Ethernet are two possibilities. You may also have to move to one of the Pi processors.

Sorry I can't do more for you but at the present I'm out of ideas.

Let me first start by saying the what you provided is very helpfull, so thank you again! Since I have a high budget limit for this project, I will probably go for more advanced modules and using external ADCs as you stated and faster schemes to send the data to pc. But there still is some points that I didn't get in your analysis.

First regarding collecting the sensors data, I want to analyze the vibration on each of the three axis and there is no problem in doing it separately on each axis, since in vibration monitoring this is what is done if I am not mistaken. Usually a technicuan uses a one axis accelerometer and measures vibration on each of the three axises separatly by plugging it on three different places on the pump to analyse the health state of the pump. So I believe just taking the required samples (15KHz) from each axis for further analysis is okay?

Secondly, if it takes 16usec for a dual synced ADC read assuming we will use the Teensy, then aren't we sampling at a rate of 1/16u=62.5Khz? I know this is above the required sampling rate which is 15Khz so it is still good for us, but isn't it making our baud rate requirments higher which become 2Mbps as you stated compared to 4bytes*15Ksps=480 Kbps?? Maybe I am asking a silly question or getting something wrong but I am not able to understand how the processor really works. For example if I want to sample at 100Hz but the time needed for one ADC read is 16u, then aren't we getting in one second much more samples than the 100 we need and hence we are increasing the baud rate requirments to trasfer those uneeded samples to the pc?? Or we can aviod this by adding delays in our code??

A final question, what do you think about using an SD card for collecting the data?

The sampling and storage time(indexed array) for a dual synced scheme is 16usec which is a rate of 62.5Ksps. That does not allow any time for transfer of the data to some other location such as an SD card, serial, RF, or any offboard system. If you do the same capture but store the data someplace else then 16usec plus storage time limits your new max sampling rate. You can sample at any rate but the sampling plus storage time is still your upper limit. The dual ADC example allows you to set the timer duration but you just can't exceed that max rate. If you have an SD card attached with enough capacity for your total storage content then that would work. However, the storage time would have to be less than the serial transfer to be of any advantage. I2C on a Teensy can run at about 2.5Mbps. If you had an SD card that uses SPI then you could conceivably solve your problem and store all of the data locally and sample at 15Ksps. You would have to calculate your total data quantity and buy a card accordingly. I saw some at NewEgg.com of 128GB. A three day run would need about 16GB so you're safe with most any 32GB card or greater.

Regarding the pump. There is probably little vibration along the rotor shaft axis and most would be sideways and up/down. Using these two axes and dual ADC capture, you can get the max motion vector. I would stick with that scheme.

First thing to do is find an SPI interfaced SD card reader and determine the transfer time. Only then can you determine your hardware needs.

Here is an SD breakout board that supposedly runs at 25Mbps using the SPI buss. With this and a Teensy, you may have a winning combination in a very small package that can be attached to any item of interest.

Thank you very much for this usefull info!! I think I will go for this combination.

Look at the writing properties of SD cards in regard to page size. It might be better to capture a quantity of data to fill several whole pages, stop capture, write the data, then resume capture. Using that scheme, you can do the 15Ksps capture until you get a certain quantity. Can you tolerate time breaks in the data? If you're capturing enough data for an FFT analysis then you only need enough for the lowest frequency, write the data into a file, then resume capturing. The file names can be something with an incremented suffix on the name part. If you make everything a power of two then calculations and storage seem to work better.

The dual synced ADC example is almost exactly what you need. Set the timer value for your sampling rate and store the data in a structured array as a pair of unint16_t values. The 'result' variable is a pair of uint32_t values with four bytes always zero.

You would be much much better off capturing a short duration of samples and then running an DCT or FFT,
then sending that spectrum back by serial, then starting again.

  1. You do not need to monitor continuously, spot-checking every few seconds is fine. Vibration
    problems are a gradual failure mode.
  2. For high frequency signals you can grab a few hundred samples and process them offline
    for a crude spectrogram.
  3. Pushing back 15KSPS over a 115200 baud connection cannot work without compression and
    you don't have the CPU horsepower for that.