Blogs

Great article on the benefits of ADC oversampling.

Posted by SciFly on April 20, 2011 at 3:33pm

 

3689401818?profile=original

 

As you all probably know, the Ardupilot/ArduIMU uses ADC  oversampling to achieve greater than 10 bit resolution of the internal ADC. I beleive they achieved alomost 12 bit resolution- not bad, I'd say.When I discovered this, I started using that approach to increase the resolution of cheap ADC's at my work, saving but loads of $ in the process.

Anyway to any curious parties interested, here is a good article that decribes how its done and why.

improveADCbyOverSAmpling.pdf

E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Tom in NOVA April 23, 2011 at 11:39am
    Thank you John.  I am digesting it... :)
  • Developer
    John Arne Birkeland April 23, 2011 at 6:04am

    Here is a quick example to show a simple framework for a timed loop and interrupt driven ADC sampling. You will have to replace the adc interrupt example code with actual working AVR code and interrupt initialization. Hint: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html for more information. You can also look at the APM code. I am pretty sure they use free running ADC interrupts.

    ------------

    unsigned long loop_timer;
    volatile unsigned long adc_integration;
    volatile unsigned int adc_counter;

    // Free running ADC interrupt that is called everytime ADC hardware is ready with a new sample
    void adc_interrupt( void )
    {
     // ADC sample integration
     adc_integration += //latest adc sample from adc interrupt//;
     // Increment adc counter   
     adc_counter++;   
    }

    // Main loop
    void loop( void )
    {
     // 100hz timed loop check
     if( micros() - loop_timer >= 10000 )
     {
      // Update loop timer
      loop_timer += 10000;
      // Disable interrupts   
      cli();   
      // Calculate ADC mean value
      unsigned long adc_value = adc_integration / adc_counter;
      // Reset ADC integration and counter
      adc_integration = 0;
      adc_counter = 0;
      // Enable interrupts
      sei();
     }
    }

    avr-libc: : Interrupts
  • Tom in NOVA April 22, 2011 at 5:26am

    Newbie question: How can you tell or how you calculate the sampling speed (HZ)  based on the hardware and/or software? For example for the APM? 

    How do I know that (for example) the main loop runs at 100HZ and how do I make sure that my sensor over-sample loop fits within that loop cycle?

  • ken April 21, 2011 at 12:59pm
    About lag: Even if you have if you are running your main loop at 50 MHz (as in here), then a lag of a couple samples on a ADC sampled at 400 Hz to 2 MHz won't even invade a cycle in the main loop.

    About SNR: SNR or S/N of a single sample is typically proportional to the sqrt of time for a single sample. By oversampling you decrease the SNR of a single sample, but when using averaging (aka filtering) you can get back the higher SNR at the cost of decreased temporal resolution (and more 'lag'). The real benefit of oversampling (the main point of the article) is to reduce the quantization error. The noise in our measurements is from both quantization and white noise. As Frederic suggested, there will be a limit (eg once you have reduced quantization error to well below white noise, there is little to no benefit in accuracy when increasing oversampling even further).
  • Developer
    John Arne Birkeland April 21, 2011 at 7:19am
    @Fokko: If implemented properly this will not produce lag in a practical applications. We can use a autopilot PID controller routine as an example. The PID main loop might run at 100hz, while the gyro ADC is sampled at 5000hz. This means that every time the PID loop runs it uses a gyro value generated from the last 50 ADC samples. So looking at the system from the viewpoint of the PID (100hz) there is no lag.
  • SciFly April 21, 2011 at 6:00am
    An important motivation for this in the arduino/inexpensive imu world is that you can get more out of the onboard ADC, satisfying the requirments of many projects while reducing a more complicated, multi- chip design.It all depends on the user and application requirements though.The arduIMU is  a great product - i'd be curious to see a comparison of the S/N and signal variance with and without the oversampling.....
  • SciFly April 21, 2011 at 5:57am

    @Fokko,

    In esence, the software averaging is acting as a low pass filter, and so the frequency response will be biased low.

  • Gord Likar April 21, 2011 at 12:32am
    Fokko your right. Over sampling won't cause lag, it's the averaging that will, although given the high sampling rates were talking about a few sample points lag is probably insignificant anyway.
  • Fokko Driesprong April 21, 2011 at 12:12am

    God Likar,

     

    I can't see why it should produce lag. The sample frequency is increased in a way that when it normaly would do one sample, it takes four and avarages the values. This shouldn't take more time if the clock frequency of the ADC is increased properly.

  • Gord Likar April 21, 2011 at 12:06am
    Frederic I totally agree.  

    Improve s/n yes, but can't see how over sampling can increase resolution.    A simple or moving average is going to introduce lag and those that don't lag require take at least two iterations of the data plus some math to complete. For example the Hull Moving Average should work on any data and usually lags only one sample.
This reply was deleted.