AnalogIn 'glitches' --- a 'cure' and a tool

17 Feb 2011

Many people have started threads about problems that they have had with the ADC on the LPC1768 - this is yet another one, but with a tool that others can use to reach their own conclusions.

I built the tool (link above) to analyze the ADC performance after reading, with some horror, the earlier threads, and it confirms (for me at least) that the ADC is prone to glitches - and by glitch I mean a hardware event (fault), probably related to some actual noise (internal or introduced via the input lead) disrupting the successive approximation process that is at the heart of the converter. SAR converters are particularly vulnerable to noise at the comparator input when a "bit" is being determined; if an error occurs, it cannot be later corrected and will show up as a "spike" in the result.

Noise at the input to an A/D should appear as a gaussian (bell shaped) distribution of readings. The reading distributions of the LPC1768 show significant departures from a gaussian distribution. With very clean inputs, the readings distribution are nominally gaussian, but "spikes" (outliers in the distribution that are statistically improbable) appear. If good circuit practices are not followed, these spikes predominate and the ADC becomes unusable.

The glitch suppression technique that is included in the tool appears to be effective when good circuit practices have been followed, and makes the onboard ADC useable for most applications.

For those that are offended by the "fix", I suggest using an MCP3208 (SPI 12 bit ADC) - it's what I use with great success.

17 Feb 2011

My test setup is on a breadboard with flying leads; there is a 10k pot connected between VOUT (pin 40) (probably a noisy place to get 3.3 volts) and gnd (pin 1); there is a 100nF (0.1 microF) ceramic capacitor between p20 and gnd.

The following (slightly edited) text shows the effect of getting the statistics of 1,000,000 readings: 1) without glitch suppression; 2) with glitch suppression; 3)without the 100nF cap from p20 to gnd even with glitch suppression.

In short, glitch suppression is effective (but never totally guaranteed) when reasonable steps have been taken with the input circuit.

/media/uploads/bobanderson/capture.txt

17 Feb 2011

The thread on problems with the ADC that initially caught my attention is:

http://mbed.org/forum/bugs-suggestions/topic/1514/ (Mbed design of analog part)

I know that at least one participant in that thread felt that the ADC was "unusable". I'm not ready to go that far, but it is at the very least finicky in that setups that work without problems in, say, the PIC world, fail miserably here.

The "glitch" suppression that am using seems to work well, but one is still left with the uncomfortable feeling that is a workaround.

18 Feb 2011

I have published a new version of AnalogInAnalyzer that incorporates code to read from an external ADC (MCP3304 was used, but should work with an MCP3208 as well) and give side-by-side comparisons with the LPC1768 ADC.

Here are some results with a "clean" input (2 alkaline batteries in series) and a 10K pot between 3v3 (which adds some noise of its own) and gnd.

/media/uploads/bobanderson/capturebatteryinput.txt

/media/uploads/bobanderson/capturepotto3v3.txt

The "delicacy" of the internal ADC and the robustness of the MCP3304 are apparent.

12 Mar 2011

I have also these spikes (around one spike per 6000 measurements). This is per definition no noise and definitively doesn't come from the analog side. It seem that there is a software bug or a timing problem in AnalogIn library. In this case it is really bad that this code is not accessible. Has somebody already a workaround? (please no external ADC)

08 Aug 2011

I had some problems with glitches too. /media/uploads/solland/glitch.jpg

I "solved" it this way:

for(int i=0; i<1024; i++) {
        if (abs((samples[i]-samples[i-1]))>3500 && i!=0){samples[i]=((samples[i-1]+samples[i+1])/2);}
        sampleresult= (float(samples[i])*3.3)/(65536);
        printf("%.2f,\r", sampleresult);
        }

Its a very simple way to filter, but it works good for me, see the result here:

/media/uploads/solland/wglitch.jpg

Of course this only works if glitches doesnt appear more than 1 time consecutevly (which never happened for me) The "3500" limit depends on the max. frequency you want to measure.

08 Aug 2011

Nice Software filter !

We added a low pass filter onto our LPC1768 product, as well as some software filtering, and I can read "analogue ins" down to 0.01v now.

Now you are going to ask me what low pass filter we added aren't you ?

and I'm going to say that I don't know, as I do software, and the hardware is done by someone else.

I can tell you it's as simple as a resistor and a cap, maybe someone with a bit more knowledge of these things can say, or maybe google is a friend, or maybe I should read more of my copy of Hill and Horowitz !

Just thought Iu'd mention it in passing though.

cheers,

Dave

09 Aug 2011

I thought this was 'fixed' in the 29 beta?

see http://mbed.org/forum/bugs-suggestions/topic/1980/

09 Aug 2011

I didnt knew about that beta Version. As far as i can see its still a beta and therefore not included standartly. I will try that out!

09 Aug 2011

I made following quick fix:

                raw[0] = ax.read_u16();
                raw[1] = ax.read_u16();
                raw[2] = ax.read_u16();
                raw01 = abs(raw[0]-raw[1]);
                raw12 = abs(raw[1]-raw[2]);
                raw20 = abs(raw[2]-raw[0]);    
                if((raw01<=raw12)&&(raw01<=raw20))
                    rawM = (raw[0]+raw[1])/2;
                if((raw12<=raw01)&&(raw12<=raw20))
                    rawM = (raw[1]+raw[2])/2;
                if((raw20<=raw12)&&(raw20<=raw01))
                    rawM = (raw[2]+raw[0])/2;

I read 3 times directly and chose than the averages of the two values with the least difference. Its a dirty hack but it works very well.

20 Aug 2011

If you don't like the software fix then here is a way to make the ADC work without glitches, with just a resistor and a small capacitor, at the full sampling rate:

http://mbed.org/forum/bugs-suggestions/topic/1514/?page=2#comment-7783

Best,

Mischa

28 Feb 2012

Can someone show a full example of how this is implemented? I'm not understanding this...

for(int i=0; i<1024; i++) { if (abs((samples[i]-samples[i-1]))>3500 && i!=0){samples[i]=((samples[i-1]+samples[i+1])/2);} sampleresult= (float(samples[i])*3.3)/(65536); printf("%.2f,\r", sampleresult); }

29 Feb 2012

Hi All,

Don't know if you saw this, but I did a bit of an investigation into ADC glitches, and found some simple stuff that cures it without the need for software filtering.

http:mbed.org/users/chris/notebook/Getting-best-ADC-performance

Hope this helps!

Cheers, Chris

10 May 2017

Hello,

Late to the party, but I need your help on a same issue...

My question: Is ADC performance of LPC1788 improved compared to LPC176x?

The latter has known issues as stated on its Errata, but the Errata sheet of the first one doesn't show such issue. I had many difficulties using LPC1768 ADC even considering all of the guidelines on forums, so I am thinking to switch to LPC1788.

Thanks! Sam

You need to log in to post a reply