I believe the quote is referring to Digital pins, but I am not 100% sure.
I believe the device that reads the analog pins voltage and converts it to decimal is completely separate from the device that controls the digital pins. So, the sampling rates are probably not the same.
There has been someone who has already looked into the sampling rates, but it seems he did not get his question answered either:
He had another thread that has been either deleted, or has gone missing. In that thread he seemed to indicate that the sampling rate was 7 ms.
I took his code from that thread, and modified it to test multiple reads in a row. What I see is that the reads take about 8.6 milliseconds. Doing them one after another did not seem to help, still about 7-8 milliseconds. Which is about 100 Hz.
Attached is the sketch that I used to measure the time.
A better method for sampling Audio would probably be USB audio device. Of course, that could be done at the Linux level, and then you would need to figure out some way of getting it to the Android side. Or maybe the best option is to just work in the Linux side? There are Siri clones on the Rassberry Pi. I would hope they can also be run on the Galileo, though, I have not heard of anyone trying that yet.
analog_read_time.zip 574 bytes
I was thinking that the GPIO was only referring to the Digital pins as well, but just like you, I can't say I am certain of that.
So your estimations put the Sampling Rate for the signals supplied to the Analog input is even less than 230 Hz? 7 ms puts it somewhere around 140 Hz, which is an unacceptable rate for what I intend to design (a guitar capable of being used as a MIDI controller).
I need to have a sampling rate of about 10 kHz at the very least. Plus I need to process 6 different signals (one for each string), so it appears that I am going to need to rethink my approach.
I definitely think that you are correct in that a Linux approach could remedy low sampling rate that is achieved with the Arduino IDE. The AD7298 ADC used on the Galileo is "spec-ed" as an 8-channel ADC with 12-bit depth, with a 1 MSPS throughput (according to the datasheet for the ADC, which I found a link to in the Galileo Datasheet PDF).
However, I don't have any knowledge or experience with programming as it pertains to the level of OS architecture. I have a fairly decent familiarity with C, and fundamental levels of Assembly Language and Machine Code (limitations of a typical electrical engineer here...), but I'm not really so sure I'll be able to handle things with Linux. The thought of that alone just scares me.
1 of 1 people found this helpful
This would be a good place to start for getting the audio data to Linux: http://www.malinov.com/Home/sergeys-projects/compact-usb-audio-adapter. You'll have to use a Linux image with the audio driver, but Sergey also has an excellent blog post about it along with the patches for download: http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage. This should be the extent of low-level Linux programming you would need. Once the data is sampled and stored in a file or whatnot, you can manipulate it with C/Python and shuttle it to the Arduino sketch if needed.
The AD7298 might be spec'd to 1MSPS, but since the default Galileo OS isn't real-time and the board doesn't have a buffer for ADC samples it'll never come close to 1MSPS.
Unfortunately, I don't believe that a usb connection would be a feasible solution in my unique circumstances. My input is coming from a special, "hexaphonic" pickup from a guitar, so I need to process 6 individual signals, which are each being carried on their own individual wires. I specifically need the use of the 6 Analog inputs (or any means of an input that will still allow for the 6 signals to remain isolated from one another).
As far as the rate of 1 MSPS is concerned, I don't believe that I will be approaching that threshold of sampling and data conversion (I would likely be in the range of tens of KSPS at the very most). I brought that up just in regards to the suggestion chofrock made about the possibility of a Linux solution which could achieve faster sampling rates.
Nevertheless, I have come up with some other ideas in response to the new information I have.
I was considering the possibility of using a few external ADC chips to perform the sampling and data conversion. Then, instead of using the Analog inputs, I could use the Digital pins of the GPIO as the input. However, I am then faced with one of my original questions regarding the GPIO:
- Does this 500 Hz, or 2 millisecond, restriction (230 Hz when factoring in the software overhead) only apply specifically to Data OUTPUT (as in, INPUT data is not affected by this limitation)?
Since reading the input still has to go through the I2C expander, it would also have the 2ms limit. There are two pins, IO2 and IO3, which can be faster (https://communities.intel.com/message/207904#207904) - 477kHz to 2.93MHz.
You might be able to use these two lines to bit-bang a protocol to an external ADC if you get one that uses I2C since SPI would require a third line.
I ran into the same issue and ended up using a MSP430G2553 to handle high-speed behavior (200ksps internal ADC) then buffering the results before sending it back to the Galileo.
I actually just came across the post you referenced about IO2 and IO3 being able to be run at faster speeds, and was navigating back to this thread so that I could bring up that point, as well as to ask whether that specifically applied to the case when these pins are outputs. You kind of preemptively answered that question for me though.
I am not quite sure that I will be able to use the Galileo for my purposes, as I am trying to execute some successive FFT's and obtain real-time (or close to real-time) data analysis with the signals that I need to sample.
Wait, actually I had another thought...
Perhaps, if I used an ADC external to the Galileo, then took the serial data streams I would obtain and transmitted them over a cat 5 or cat 5e cable to the on-board Ethernet port. The Ethernet port would allow me to bypass the I2C expander altogether, and should be capable of transmitting the data with more than enough speed.
The only difficulty that this would present is the fact that I could only send, at most, 4 signals at a time, whereas I need to be sending 6 signals.
Maybe if I used 3 of the twisted-pair channels to individually transmit 3 of the signals, and then, if I could figure out a way to have each twisted-pair channel alternate between transmitting the data for 2 of my signals (probably alternate every time a sample-size increment is sent).
Possibly, I would need more than one Galileo board in order to handle all 6 signals...
As long as there isn't any overhead limitations with the Galileo or with the Arduino IDE, of which I am unaware, that might limit the rate at which the data can be interpreted, maybe this could be the solution.