[En-Nut-Discussion] AD conversion resolution?

Mon Dec 19 21:08:06 CET 2005

Hi Gerwin,
Noise does not affect an successive approximation ADC as a random
disturbance only, you get these triangular cutouts near major
carry point like 01111 -> 10000. You say: "the 
value would stay on 255 for a very long time while I was doing my 
voltage sweep." 

1. We do not know if you are the only one affected,
   the way I use the ethernut board I would not notice.

   Some things to try (References assume you use an ATMEGA128 on a 1.3F
board)
2a. Check your ADC Power Connection decoupling, fig. 114 in my datasheet.
    On my old 1.3F boards I changed R13 to an inductance.
    Check that C22 is in place. Check value if you can (or put in a new
one). 
2b. Try a slower AD conversion clock in your setup.
2c. If you use the multiplexer, check your timing from MUXing to conversion
start against the data sheet.
2d. Try the noise canceler as suggested in the data sheet, (I have never
tried this).
    From the data sheet:
    "The ADC features a noise canceler that enables conversion during sleep
mode to
    reduce noise induced from the CPU core and other I/O peripherals." 

Hope this helps,
Lars H Andersson 

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de 
> [mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of 
> Gerwin Voorsluijs
> Sent: Monday, 19 December, 2005 12:54
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] AD conversion resolution?
> 
> 
> Hi Lars,
> 
> Being mostly a software guy, I am struggling to follow your way of 
> thinking, but I do understand your end suggestion of what might be 
> causing the problem. I have two questions however:
> 
> 1> How come it seems that I am the only one having this problem 
> considering the fact that the problem (noise) originates on 
> the Ethernut 
> board itself?
> 
> 2> How do I solve it?
> 
> Sincerely,
> 
> Gerwin
> 
> Lars Andersson wrote:
> > Hi group,
> > being a mostly hardware guy I feel I might contribute 2 
> cents of opinion
> > here.
> > 
> > IMHO, what you see here is the result of noise uppsetting 
> the comparator
> > of the internal SAR A/D converter in the atmega chip. As 
> the SAR works
> > its way towards the LSB the voltage differences on the comparator
> > gets smaller and smaller and chances for a mistaken reading 
> increases.
> > 
> > Considering how SAR works one comparator mistake at a low value bit,
> > say 3rd LSB, makes all bits of even lower value will be wrong and
> > also of the same value, either 1 or 0.
> > 
> > There are three ways (or more?)  to introduce noise in an 
> SAR AD, signal,
> > reference and comparator power supply.
> > 
> > I am suggesting that the noise is possibly not on your 
> signal or your
> > reference
> > but on your power supply to the analog part of the AVR chip (AVCC). 
> > 
> > I have got several good ideas from this group in the past, 
> so hope this 
> > might help someone,
> > 
> > Lars H. Andersson
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: en-nut-discussion-bounces at egnite.de 
> >>[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of 
> >>Arius - Rick Collins
> >>Sent: Saturday, 17 December, 2005 16:02
> >>To: Ethernut User Chat (English)
> >>Subject: Re: [En-Nut-Discussion] AD conversion resolution?
> >>
> >>
> >>At 06:11 AM 12/16/2005, you wrote:
> >>
> >>>Been investigating it a bit further based on the same data 
> >>
> >>and I found 
> >>
> >>>that the two major gaps in my data show a "funny" symmetry:
> >>>255 - 304 and 719 - 768 both have a gap of 49 and 255+768 = 
> >>
> >>304+719 = 1023.
> >>
> >>>Been investigating the gaps in the data a bit more and to my 
> >>
> >>surprise, 
> >>
> >>>this symmetry occurs throughout the data: check out the plot 
> >>
> >>of the gaps 
> >>
> >>>versus the mean value of the two endpoints and the same data 
> >>
> >>mirrored in 
> >>
> >>>1023/2 which I added to http://130.161.167.171/ethernut.zip
> >>>
> >>>Anyone?
> >>
> >>
> >>I have looked at your data and it is a bit mystifying.  In 
> >>the one graph, I 
> >>believe I am looking at a time graph of data values as you 
> sweep the 
> >>pot.  The first 40,000 readings look like they are with the pot 
> >>undisturbed.  Since you seem to get so much of a jump which 
> >>would be due to 
> >>noise, you could investigate that further without the 
> >>complication of the 
> >>wiper.  I see three (maybe four) discrete levels in this range.
> >>
> >>Looking back at one of your original posts, it appears to me 
> >>that your data 
> >>bus may be scrambled.  If the data bus is serial, then I 
> >>suggest that you 
> >>look for a problem with timing in the data vs. clk.  If you 
> >>are clocking on 
> >>the wrong edge, you may see some problems like this.  I was almost 
> >>convinced that it was a mix up of the bits on the bus until I 
> >>looked at the 
> >>raw data and realized that the four lowest readings were 0, 
> >>1, 3, 7 and 
> >>15.  Yes, I know that was five values, I can't count.
> >>
> >>I can't explain that sequence by a data bus scramble, but I 
> >>can explain it 
> >>by a problem with timing on a serial bus or possibly a 
> >>problem with the 
> >>voltage levels, pull up value or some other issue that would 
> >>result in a 1 
> >>bit smearing into other bit time windows.
> >>
> >>
> >>
> >>_______________________________________________
> >>En-Nut-Discussion mailing list
> >>En-Nut-Discussion at egnite.de
> >>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> >>
> > 
> > 
> > _______________________________________________
> > En-Nut-Discussion mailing list
> > En-Nut-Discussion at egnite.de
> > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> > 
> > 
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 