I want to data log two two accelerometers sensors simultaneously for suspension analysis at a sampling rate of around 1000 times a second and compare and then analyse the measurements collected from the two sensors in a spread sheet.
The easiest way I envisage doing this is storing the data on an SD card or USB memory stick in something like a csv format and then plugging the SC card into a PC to analyse the data.
I am a novice with this stuff (I guess this is where everybody starts from) so please excuse me in advance for any questions that seem a bit dumb.
Initially I only need to measure acceleration in one direction but I can see that later on it might be valuable to measure acceleration in 3 dimensions.
To get the sample rate I need and to be able to store the data on to the SD card, does anyone have any thought on wherther am I going to better to use a digital or analog accelerometer?
If I use a digital acelerometer a good choice might be the ADXL345 which has a sampling rage of 3.2kHz and can measure accelerations of up to 16 G which I think will cover the range of vibrations I want to record.
Initially I think I am going to try using ADXL345 accelerometers.
Given the high sampling rate that I think I am going to need (around 1000 times per second), I am guessing the speed of the arduino board might play a part in being able to sample the two accelerometers fast enough and then write the data in CSV format to an SD card?
Can anyone suggest a suitable arduino board for this project?
You could look at using an Arduino Due or a Teesey
what interface does the mems device have?
do you have extensive floating point calculations?
use a Raspberry Pi and communicate with the PC using Ethernet of wiFi?
horace:
You could look at using an Arduino Due or a Teesey
what interface does the mems device have?
do you have extensive floating point calculations?
use a Raspberry Pi and communicate with the PC using Ethernet of wiFi?
horace:
You could look at using an Arduino Due or a Teesey
what interface does the mems device have?
do you have extensive floating point calculations?
use a Raspberry Pi and communicate with the PC using Ethernet of wiFi?
Thanks Horace I am not going to need to do do any floating point calculations etc. This is just going go be a data logging device. The reason I am thinking I might need something with a bit of grunt is the high sampling speed and high speed storage of this data to an SD card?
I am not sure if I am thinking about this right? It appears he ADXL345 accelerometer with high resolution (13-bit) measurement at up to ±16 g. Digital output data is formatted as 16-bit twos complement and is accessible through either a SPI (3- or 4-wire) or I2C digital interface and I want them to sample at 1000 times per second.
I think that SD cards with a fast enough write speed are readily avaliable. "The SD Association has two UHS Speed Classes, UHS Speed Class 1 and UHS Speed Class 3. UHS Speed Class 1 supports a minimum 10MB/s write speed, whereas UHS Speed Class 3 supports at least 30MB/s write speed. UHS Speed Class-rated devices will also use one of two UHS Bus Interfaces that indicates the theoretical maximum read and write speeds. They’ll be listed as either UHS-I or UHS-II to show which interface is used. UHS-I devices have a maximum read speed of 104MB/s, whereas a UHS-II card has a maximum read speed of 312MB/s. Note, that unlike the UHS Speed Class, these are not sustained speeds."
So I think the potential bottleneck if there is going to be one is the arduino card sitting between the two and formatting and writing the samples to the SD card in something like a CSV file format that I can read with an excel spreadsheet?
I want to simultaneously read and store accelerometer values from two Accelermeters, so my plan was to store the data on to an SD card and then when I have finished recording just plug the SD card into an SD card reader in my computer and import it into an Excel spread sheet for analysis.
The bottleneck is the Arduino doesn't use the full SD card interface. It's using only 2 wires. That slows down transfers drastically. You also have the problem that occasionally the SD card wants to write a big block and that interrupts the timing of your samples.
The Teensy 3.5 and 3.6 do have 4-wire SD card slots on board and they use all 4 wires, so if you find that SD write speed is a problem then you can switch to one of those.
I've sucessfully logged 4 ADXL345 accelerometers at 100Hz with a Teensy 3.2. The accelerometers were oversampled at 400Hz and then digitally filtered on the Teensy before writing to a flash memory chip. I didn't use an SD card because I was worried about the vibration affecting the card connection to the socket. (I won't use that memory chip again either, it was terrible to make it work at reasonable speed, despite a claimed 80MB/s write speed.)
Synchronising the ADXL345's to each other is a problem. I got them all set up in the right mode and then simultaneously gave them all the same 'start' signal. (Assert the CS line on all and send the SPI signal.) Then they run on their own internal clocks from that point and those clocks have no accuracy specification in the datasheet. How long do you expect a test to take? I'd trust the clocks to be OK for about 30-60 seconds but then they could drift.
MorganS:
The bottleneck is the Arduino doesn't use the full SD card interface. It's using only 2 wires. That slows down transfers drastically. You also have the problem that occasionally the SD card wants to write a big block and that interrupts the timing of your samples.
The Teensy 3.5 and 3.6 do have 4-wire SD card slots on board and they use all 4 wires, so if you find that SD write speed is a problem then you can switch to one of those.
I've sucessfully logged 4 ADXL345 accelerometers at 100Hz with a Teensy 3.2. The accelerometers were oversampled at 400Hz and then digitally filtered on the Teensy before writing to a flash memory chip. I didn't use an SD card because I was worried about the vibration affecting the card connection to the socket. (I won't use that memory chip again either, it was terrible to make it work at reasonable speed, despite a claimed 80MB/s write speed.)
Synchronising the ADXL345's to each other is a problem. I got them all set up in the right mode and then simultaneously gave them all the same 'start' signal. (Assert the CS line on all and send the SPI signal.) Then they run on their own internal clocks from that point and those clocks have no accuracy specification in the datasheet. How long do you expect a test to take? I'd trust the clocks to be OK for about 30-60 seconds but then they could drift.
Thanks for the great info. I guess that you were oversampling and filtering to get rid of noise. I am curious to know how much noise (perhaps in %) you were observing.
You have also brought up and issue that I am also concerned about in synchronising the ADXL345's to each other. Accurate synchronisation is key to this project. I will want to store as large a sample as it will be possible to store on the vehicle. Pin 14 is the SCL serial communications clock. Might it be possible to clock both ADXL345s to each other using this?
So you don't want it to drift by more than 1/1000th of a second over the recording period. How long is that? Hours or minutes?
As far as I can tell, the SCL or CLK signals you give to the ADXL345s don't affect the internal clock. There's very little detail in the datasheet.
Noise is not the reason for oversampling. The problem with using these specific accelerometers for engineering measurements is frequency folding. If you're sampling at 50Hz and you get a 51Hz input, then it shows in your data as a 1Hz input and there's no way to undo that fold after the samples are taken. You simply cannot remove the 51Hz signal without also deleting any "real" 1Hz data you're interested in.
Real engineers use analog filtering before it gets to the digital samples. That's why they use analog accelerometers which cost hundreds of dollars. You must remove all frequencies above the Nyquist frequency which is half the sample frequency. In practice, you use an analog filter which starts to cut well below the Nyquist frequency and has some acceptably-low level above the Nyquist frequency. You may also have to change the sample rate depending on the performance of the analog filter.
The ADXL345 datasheet is lacking in detail on the analog filtering. It implies that when you give it a specific sample rate then it will take care of the filtering but since there's no detail, it probably doesn't. I never had time to really test out that theory but it did seem like sampling at 20Hz would not be fooled by a 21Hz input.
In my particular application, I could be pretty sure that there was no significant amplitudes above 200Hz. (The filter was the soft adhesive holding the accelerometers.) So I sampled at 400Hz and decimated down to 100Hz for recording. Note that decimation is not as simple as just taking every Nth sample. I used a digital filter to virtually eliminate all frequencies above the 30Hz that I actually wanted. The digital filter is much easier to control than an analog one and much more selective - the attenuation of all frequencies outside the passband can be stupendously good. I could be sure that there was nothing above 50Hz in my 100Hz datastream and the actual analysis could start from there.
MorganS:
So you don't want it to drift by more than 1/1000th of a second over the recording period. How long is that? Hours or minutes?
As far as I can tell, the SCL or CLK signals you give to the ADXL345s don't affect the internal clock. There's very little detail in the datasheet.
Noise is not the reason for oversampling. The problem with using these specific accelerometers for engineering measurements is frequency folding. If you're sampling at 50Hz and you get a 51Hz input, then it shows in your data as a 1Hz input and there's no way to undo that fold after the samples are taken. You simply cannot remove the 51Hz signal without also deleting any "real" 1Hz data you're interested in.
Real engineers use analog filtering before it gets to the digital samples. That's why they use analog accelerometers which cost hundreds of dollars. You must remove all frequencies above the Nyquist frequency which is half the sample frequency. In practice, you use an analog filter which starts to cut well below the Nyquist frequency and has some acceptably-low level above the Nyquist frequency. You may also have to change the sample rate depending on the performance of the analog filter.
The ADXL345 datasheet is lacking in detail on the analog filtering. It implies that when you give it a specific sample rate then it will take care of the filtering but since there's no detail, it probably doesn't. I never had time to really test out that theory but it did seem like sampling at 20Hz would not be fooled by a 21Hz input.
In my particular application, I could be pretty sure that there was no significant amplitudes above 200Hz. (The filter was the soft adhesive holding the accelerometers.) So I sampled at 400Hz and decimated down to 100Hz for recording. Note that decimation is not as simple as just taking every Nth sample. I used a digital filter to virtually eliminate all frequencies above the 30Hz that I actually wanted. The digital filter is much easier to control than an analog one and much more selective - the attenuation of all frequencies outside the passband can be stupendously good. I could be sure that there was nothing above 50Hz in my 100Hz datastream and the actual analysis could start from there.
Many thanks for taking the time to respond with your experience.
I don't mind if the samples drift or dither over time. As long as sample 5 from accelerometer A and sample 5 taken at nearly the same time (less than 1/1000th second apart can be compared with each other) It would be nice to be able to have a collection period of a few minutes but I see 1 minute as being the smallest time period that would have value.
Great explanation on the Nyquist frequency. I had encountered the Nyquist sampling rate before but not the Nyquist frequency. I am familar with analogue filters but have done very little with digital filtering.