8 Replies Latest reply on Mar 7, 2014 10:01 AM by gnate

    Sampling Rate of the Analog Inputs




      I am working on a project that requires the use of audio signals as inputs, and I had some concerns regarding the sampling rates of the Analog inputs


      I'm confused about what the Galileo's actual capabilities are in terms of the sampling rates for the ADC used with the analog input pins (A0 through A5). I understand that the Galileo is capable of handling up to 12 bits per sample, and is set to 10 bits per sample by default, as is mentioned in the FAQ.


      However, my concern relates to the question in the FAQ regarding the maximum rate at which the GPIO output pins can be updated, and how this might impact sampling rates.

      The answer given says:


      The GPIO output pins on Intel® Galileo are provided by an I2C Port Expander that is running at standard mode (100 kHz). Each I2C request to update a GPIO requires approximately 2ms. In addition to software overhead, this restricts the frequency achievable on the GPIO outputs to approximately 230 Hz.


      So, what I am having trouble understanding is:

      • Does the GPIO only refer to the 14 Digital I/O pins, or is it also a blanket term that incorporates the 6 Analog pins as well?
      • 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)?
      • If INPUTS to the 6 Analog pins are not ultimately hindered by this 230 Hz limitation, what is the actual maximum sampling rate that can be achieved for an input signal?



      Any clarification would be appreciated.

        • 1. Re: Sampling Rate of the Analog Inputs
          Clayton Hofrock

          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:

          Sampling Rate of the Analog Inputs


          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.

          1 of 1 people found this helpful
          • 2. Re: Sampling Rate of the Analog Inputs

            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.

            • 3. Re: Sampling Rate of the Analog Inputs

              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.

              1 of 1 people found this helpful
              • 4. Re: Sampling Rate of the Analog Inputs

                Hi MarkBunney,


                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)?
                • 5. Re: Sampling Rate of the Analog Inputs

                  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.

                  • 6. Re: Sampling Rate of the Analog Inputs

                    Hi MarkBunney,


                    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.

                    • 7. Re: Sampling Rate of the Analog Inputs

                      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.

                      • 8. Re: Sampling Rate of the Analog Inputs

                        According to the Galileo Schematic, the ADC is on an SPI bus at 4MHz (capable of 25MHz). That being said, reading 6 channels at 44khz would certainly require faster speeds than 4MZ, but at least we are not talking 100kHz.


                        (Why couldn't they have put the GPIO on SPI and the Flash on I2C?)