I just started playing around with the stuff this morning and have no problem with the Uno R3 and can talk to and receive data from the accelerometer via the Serial.println() command, but it seems to be slower than I'd hoped for logging data.
What is the time resolution on the Serial.println() output? Is it just the baud rate or is it significantly slower?
Would I be able to record data faster if I got a data logger shield and wrote directly to an SD card? Recommendations on a data logging shield would be great too.
What is the time resolution on the Serial.println() output?
It depends on the chosen baud rate.
Figure on baud rate / 10 characters per second.
Don't forget impact events are extremely short ( hopefully), so maybe best to buffer them, and dump the results when they've finished,
Would I be able to record data faster if I got a data logger shield and wrote directly to an SD card?
If you are talking about dropping a football, you are likely in need of recording over several ms range, but probably at low frequencies (5ksps for example. That means a SD/eeprom based solution isn't fast enough for you.
Once you figure out a way to trigger the logging, you may need to record to SRAM or FRAM devices.
Another alternative is to write to internal ram - but you need a mcu with large ram.
I setup the logger and it seems that writing the code out to serial happens rather quickly about 1ksps, but the accelerometer is only being sampled at about 4sps.
I think writing to SRAM or FRAM is the best option, but the on board SRAM is small 2 kB which wont allow a lot of recording time.
Is there a way to use a SRAM or FRAM shield? I'm really new to this so am just getting up to speed on things (pun not intended).
I thought in one of the other forums I saw a SD data logger doing 100ksps, but maybe that was for a different application.
fafcake:
the accelerometer is only being sampled at about 4sps.
What's the bottleneck? What speed is the serial interface to the accelerometer running at, and what's the highest sampling rate you can achieve if you do nothing but sample?
Also, if you're measuring impact accelerations, how long do these last and what sampling frequency do you need to achieve to measure them?
I set the baud rate to 115200 and if I comment out lines of code for time stamps and calls to a getvoltage function (see below) it seems I can reduce the bottleneck ie the curves look better, more like a curve than a delta function. So the bottle neck might come from the time stamps and serial write. So I can reduce the bottleneck, but then I lose my time resolution. I guess this isn't a huge deal as long as I can measure an acceleration curve, although being able to backward integrate velocities would be nice and for that I'd need time stamps or a known accurate sample rate.
I'm guessing for impacts the impact time is <0.5 sec for meaningful peak impact acceleration. I'd like to squeeze 2-4 samples into that time to generate a nice curve.
My code for now is very basic and I've reduced it and see better sampling but now don't know times (they are commented out), I plan on setting up a button press to start and a time record option, or possibly a buffer that constantly over writes and keeps the last 100 samples before an impact then records til full.
Code:
//int apin = A0;
float voltage, acceleration, time;
//float ACheck;
const int powerpin = A0;
const int groundpin = A1;
const int selftestpin = A2; //unused
const int apin = A3;
void setup()
{
Serial.begin(115200);
pinMode(powerpin, OUTPUT); //sets power pin for accelerometer
pinMode(groundpin, OUTPUT); //sets ground pin
digitalWrite(powerpin, HIGH); //powers accelerometer
digitalWrite(groundpin, LOW); // provides ground
}
void loop()
{
//voltage = getVoltage(apin); //gets the voltage from accelerometer
//ACheck = analogRead(apin); //takes analog reading again and recalculates acceleration
//time = micros(); //time for plot
// Serial.print(time);
//Serial.print(" V: ");
//Serial.print("\t");
//Serial.print(voltage);
//Serial.print("\t");
//Serial.print("A: ");
//Serial.print("\t");
acceleration = (analogRead(apin)*0.004882814 - 2.5)/0.008; //converts voltage to acceleratio
Serial.println(acceleration);
//Serial.print("\t");
//Serial.print(ACheck);
//Serial.print("\t");
//time = micros(); //checks serial time write lag
//Serial.println(time);
}
/*float getVoltage(int pin) //this function gets the voltage from the analog pin connected to the accelerometer
{
return(analogRead(pin)*0.004882814);
}*/
micros is always going to return a many-digit number, eating into available time when you print it, but absolute time probably isn't needed, and could be calculated from an initial time plus subsequent deltas.
I'd maintain a circular buffer of accelerometer readings and only print values when an impact is detected.
I didn't realise you were using a simple analog read to get the accelerometer values. That should be capable of providing accel samples hugely faster than you need, as long as you don't try to log them in real time.
If you're trying to capture transient events like a football hit, I think you should aim to be sampling at least at hundreds of Hz rather than just a few Hz. Since I/O is very slow compared to the sort of sampling interval you'd be looking at, I agree you should look to buffer the acceleration values and only output then after the acceleration event has completed.
I don't know how long the event your measuring will last (are you talking about a football bouncing off a surface, or a footballer bouncing off another footballer?) and since you have limited RAM and can realistically only afford to hold a few hundred samples in RAM you may need to compromise between the sampling frequency and the sampling duration. You can improve the accuracy by oversampling and then storing an average rather than storing each measured value, and you could also reduce the amount of data you need by doing your analysis within the Arduino so that it only needs to report the total cumulative impulse, percentile accelerations and whatever other metrics you want rather than having to store all the raw data - even if you sample at a few KHz, you will have lots of processor time available for number crunching between samples.
Thank you so much for the help. I'll work on setting up a rotating buffer and then outputting the data.
The experiment is designed to simulate the collision of two footballers, but peak acceleration is the biggest concern and should happen at the initial impact and last much less than a second, so hopefully the RAM should be able to store the needed data. The recommendation of doing the analysis on board is something I'll take into account.
I suppose you're already addressing this, but I'd expect that medics would be able to tell you what aspect of the impact is most important to control to avoid injury, and with this knowledge you could tailor your collection and analysis towards that answer rather than trying to capture and log every scrap of data you can obtain.