I need to sample as many analog readings as possible over a 90 second interval. (or possibly 3 sets of 30 second intervals) I then need to transfer this data to a pc for later review/analysis.
I've read on the forum that using direct port manipulation instead of the arduino libraries will greatly improve speed and a I plan on doing that.
I've also thought of a couple possible solutions and if there is a better way to do it please let me know.
Sample data and send it through a serial connection to my pc as fast as the serial connection it will let me.
Sample data and save it into the atmega eeprom (or possibly an additional eeprom chip) and then send it through serial later.
Use a combination of 1 and 2 and some type of buffer.
Sample data and save it to an SD card (seems to be pretty difficult to get it working).
I'll have to talk to my mentor at school tomorrow and find out the minimum number of samples we have to have. However, I'm pretty sure we are going to need more than 1,920 samples per second.
If, we do need more samples per second, what options do I have?
115,200 baud rate / 10 bits per byte = 11,520 bytes per second
At least six bytes per sample = 1,920 samples per second
The first part I understand. The maximum supported baud rate is 115,200, so 11,520 bytes per second is reasonable.
Where did the 6 bytes per sample come from? If the analogRead (or direct port manipulation equivalent) returns an integer, that's only 2 bytes. Even if an delimiter were added after each byte, that's only 3 bytes per sample, doubling the rate to 3,840 samples per second.
Chris, what are you sampling (not sound, I hope) that needs to be sampled that often? How much do the samples change? If the rate of change is small, you could send the base value, then the delta between samples, increasing your sample rate to 11,520 samples per second. That wouldn't work if the delta between samples is larger than 1/4 of the range (0 to 1023) that analogRead returns.
Chris, what are you sampling (not sound, I hope) that needs to be sampled that often?
Or perhaps even worse an oscilloscope. In general, if performance is a problem I would rather suggest to look for a platform that can buffer the data for one segment. That makes your life a lot easier than fiddle round with 2kB of memory.
If the analogRead (or direct port manipulation equivalent) returns an integer, that's only 2 bytes. Even if an delimiter were added after each byte, that's only 3 bytes per sample doubling the rate to 3,840 samples per second.
Higher data rate but more difficult to synchronize if a byte is dropped.
The questions are how much difficulty will chrismcbride76 be able to overcome and how reliable is the serial connection and reciever code.
One more potential hitch-in-the-get-along: My understanding is that, from the sensor's perspective, the ADC is like a capacitor. The sensor has to charge the capacitor to get an accurate reading. If chrismcbride76's sensor is not able to effect the capacitor's charge in a timely fasion, the readings won't be accurate.
Thank you all for your insight and help. I believe that 1,900 samples per second should be enough, although I've yet to hear back from my mentor and those that will be using the device. If it turns out that we need more samples....well, it looks that could get pretty tricky.