Comment by Dano on April 20, 2011 at 5:37pm

Nice reference for the group

Comment by Nathan on April 20, 2011 at 8:42pm

There was a thread a while back on low gyro drift obtained by ADC oversampling. I've been using this on my sparkfun AVC project and it works well. I sample a gyro at 9.6 kHz on an ardupilot, using the free-running ADC mode. Works like a champ (and runs in the background!)

Comment by SciFly on April 20, 2011 at 10:05pm

@Nathan

Cool!Could but could you elaborate on how an increased resolution helps mitigate gyro drift?

Comment by frederic reblewski on April 20, 2011 at 11:23pm

I am not sure this is that simple. you have to be careful with that method and understand what you really get. oversampling and doing some kind averaging ( average, median, geometric average...) will help reduce the average error due to noise, it will not increase the accuracy of each sample because in presence of white noise you can be "unlucky" on one individual sample. in addition that technique works better with "slow" signal ( far from the nyquist frequency). a simple example: if your signal is an amplitude A sinus at a frequency close to nyquist a non oversampled signal will give you all the values between -A and A, but if you oversample a lot the resulting "samples" will be between -A/2 and A/2 more or less, so the error will be far bigger with the oversampling. and of course there are also other problems that are not covered here like the non linearity of the code or the impact of the  jitter on the sampling clock...

So in the right environment and with the understanding of the limits of the method, oversampling and averaging will on average eliminate some noise, but if you want for example to measure a temperature with a 16 bits real accuracy do not think that averaging 64K samples from a cheap 8 bit ADC will do the trick...

my 2 cents

Comment by Fokko Driesprong on April 20, 2011 at 11:51pm

Great article! I am not an electrical engineering, but the essence of the over sampeling is clear to me. Very interesting.

Comment by Gord Likar on 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.

Comment by Fokko Driesprong on 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.

Comment by Gord Likar on 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.

Comment by SciFly on 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.

Comment by SciFly on 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.....

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page