Invalid ADC values

25 Jul 2010 . Edited: 25 Jul 2010

I am sampling the ADC function at a rate of 50kHz (I attached an ADC convert function to "Ticker" that calls the ADC function every 20 microseconds).  I am grabbing 256 points of data for an FFT, and the ADC samples are _u16 ("unsigned int").

As part of my troubleshooting, I am collecting 256 samples, and then printing them out to hyperterminal to see what values I get.

I have installed a level shifter at the input of the ADC to bias the incoming audio sample at 1.15V (half of the 3.3V reference on the mBed).

With nothing connected to the MBed terminals (except a level shifter), I get the following numbers in the hyperterminal screen:

32743
32695
4294934568
32743
32583
32743
32743 (...etc)

 

If I am using the "read_u16" command, the max value is 65535, and half of this max is 32768.  The "32,000" values I am getting make sense, but where is the 4294934568 value coming from?  Is it a hardware error?

 

Update: When I use the regular read() function (for a float value from 0 to 1.0), all the values are very consistent with 0.5.  It seems that only using the read_u16 command can produce invalid results.

 

 

29 Jul 2010 . Edited: 29 Jul 2010

Hmm, at first thought, I was gonna suggest that it's a noise problem (see here) but noise would only saturate the output to 65535. It's weird how you get 4294934568 as that is far outside the range of u_16. Also, I have had a hard time to sample at 44100 and have other code run at the same time. I think 50kHz is much too fast if you expect to do some heavy processing while sampling. That could be cause of the problem.

Also, what kind of variable are you storing the result in? By the looks of it, it seems that its an unsigned int and somewhere in the code, the most significant byte gets set to 1111 1111. This could be because somewhere in the code you could be accessing memory you shouldn't be, but it's hard to tell without the code.

2^32 - 4294634568 = 32728

Since the problem does not appear with a float, try changing the type to something more suitable. You can try uint16_t (in stdint.h), or an unsigned short and see if you get funky results.. It is definately an interesting problem...

Hope that helps!