AVR-Chat

On Sat, 08 Sep 2007 03:11:18 -0400
 Gustavo Goretkin <gustavo@goretkin.com> wrote:
> Hi,
>  I'm running some code on an ATMega32 (PDIP, 16mHz) I'm
> using 4 of the 8 
> ADC channels to collect data from sensors (gyros and
> accelerometers). 
> These are channels 1,2,3,4 (channels from 0-7). I am, in
> reality, using 
> only channel 1,3,4 (plan to add a sensor connected to 2
> soon). Channels 
> 1 and 3 receive very accurate data, but for some reason
> channel 4's data 
> is always off. For example, I'm using a two-axis accel.
> connected to 
> channels 3 and 4. After I average 3 and 4's values for a
> while to get 
> the bias of the accelerometer's outputs, 3 always returns
> a value of 
> zero (after removing the bias and having the sensor
> still), but 4 always 
> returns some random value that is anywhere from 15-30 ADC
> units off. I 
> have switched the sensor configuration (swapped 3 and 4),
> and still 4 
> returns non-ideal values and 3 is fine. I have read of
> problems on the 
> ATMega 128 with JTAG on the first four pins of Port A,
> but Port A's 
> alternate function on the ATMega 32 is ADC only. Is there
> something I am 
> missing?
> 
> Thanks.
> Gustavo Goretkin

Is the axis with steady signal the Z axis, perhaps? If it
is, you are just measuring gravity?

Jim

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

Hi,
 I'm running some code on an ATMega32 (PDIP, 16mHz) I'm using 4 of the 8 
ADC channels to collect data from sensors (gyros and accelerometers). 
These are channels 1,2,3,4 (channels from 0-7). I am, in reality, using 
only channel 1,3,4 (plan to add a sensor connected to 2 soon). Channels 
1 and 3 receive very accurate data, but for some reason channel 4's data 
is always off. For example, I'm using a two-axis accel. connected to 
channels 3 and 4. After I average 3 and 4's values for a while to get 
the bias of the accelerometer's outputs, 3 always returns a value of 
zero (after removing the bias and having the sensor still), but 4 always 
returns some random value that is anywhere from 15-30 ADC units off. I 
have switched the sensor configuration (swapped 3 and 4), and still 4 
returns non-ideal values and 3 is fine. I have read of problems on the 
ATMega 128 with JTAG on the first four pins of Port A, but Port A's 
alternate function on the ATMega 32 is ADC only. Is there something I am 
missing?

Thanks.
Gustavo Goretkin

I tried it with both axis, and I've unbiased my signal. One axis works 
fantastically; the other does not.
Gustavo

Jim Wagner wrote:

>
> On Sat, 08 Sep 2007 03:11:18 -0400
> Gustavo Goretkin <gustavo@goretkin.com 
> <mailto:gustavo%40goretkin.com>> wrote:
> > Hi,
> > I'm running some code on an ATMega32 (PDIP, 16mHz) I'm
> > using 4 of the 8
> > ADC channels to collect data from sensors (gyros and
> > accelerometers).
> > These are channels 1,2,3,4 (channels from 0-7). I am, in
> > reality, using
> > only channel 1,3,4 (plan to add a sensor connected to 2
> > soon). Channels
> > 1 and 3 receive very accurate data, but for some reason
> > channel 4's data
> > is always off. For example, I'm using a two-axis accel.
> > connected to
> > channels 3 and 4. After I average 3 and 4's values for a
> > while to get
> > the bias of the accelerometer's outputs, 3 always returns
> > a value of
> > zero (after removing the bias and having the sensor
> > still), but 4 always
> > returns some random value that is anywhere from 15-30 ADC
> > units off. I
> > have switched the sensor configuration (swapped 3 and 4),
> > and still 4
> > returns non-ideal values and 3 is fine. I have read of
> > problems on the
> > ATMega 128 with JTAG on the first four pins of Port A,
> > but Port A's
> > alternate function on the ATMega 32 is ADC only. Is there
> > something I am
> > missing?
> >
> > Thanks.
> > Gustavo Goretkin
>
> Is the axis with steady signal the Z axis, perhaps? If it
> is, you are just measuring gravity?
>
> Jim
>
> ----------------------------------------------------------
> The Think Different Store
> http://www.thinkdifferentstore.com/ <http://www.thinkdifferentstore.com/>
> For All Your Mac Gear
> ----------------------------------------------------------
>
>

Gustavo Goretkin wrote:
> After I average 3 and 4's values for a while to get the bias of the
>  accelerometer's outputs, 3 always returns a value of zero (after
>  removing the bias and having the sensor still), but 4 always returns
>  some random value that is anywhere from 15-30 ADC units off. I have
>  switched the sensor configuration (swapped 3 and 4), and still 4
>  returns non-ideal values and 3 is fine.

Is the "random value" always off in the same direction or is it really
random? In the first case I suspect some error in the way you're
removing the bias. In the latter case, it looks like you have too much
noise, so a check of the signal preparation circuitry would perhaps
reveal something. Do you have access to a scope?

AS

The values are truly random. They seem to sway sometimes to one sign or 
the other, but typically it is distributed negative and positive 
equally. There is no biasing error because whichever axis is connected 
to ADC input 3 (0 being the first input) is fine. The biased, still 
value is always zero. I haven't had the chance to check the rest of the 
ADC, but I feel that the first half of the ADC is operating well, while 
the other half is exhibiting some sort of problem. Are there any 
pull-up/down settings? Port A on the Atmega 32 has no other alternate 
function besides ADC input, but perhaps there is something I am missing.

I do have access to the scope, and the signal looks clean to me. 
Furthermore, when I switch the two channels and axes, the error is 
pertinent to the input channel of the ADC, and not the output of the sensor

Thanks.
Gustavo Goretkin

Andreas Stemmer wrote:

>
> Gustavo Goretkin wrote:
> > After I average 3 and 4's values for a while to get the bias of the
> > accelerometer's outputs, 3 always returns a value of zero (after
> > removing the bias and having the sensor still), but 4 always returns
> > some random value that is anywhere from 15-30 ADC units off. I have
> > switched the sensor configuration (swapped 3 and 4), and still 4
> > returns non-ideal values and 3 is fine.
>
> Is the "random value" always off in the same direction or is it really
> random? In the first case I suspect some error in the way you're
> removing the bias. In the latter case, it looks like you have too much
> noise, so a check of the signal preparation circuitry would perhaps
> reveal something. Do you have access to a scope?
>
> AS
>
>

At 03:49 PM 11/09/2007, you wrote:
>the error is
>pertinent to the input channel of the ADC, and not the output of the sensor

I know this is a silly question but have you tried another chip?

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Gustavo Goretkin wrote:
> I do have access to the scope, and the signal looks clean to me. 
> Furthermore, when I switch the two channels and axes, the error is 
> pertinent to the input channel of the ADC, and not the output of the sensor

Did you measure directly at the pin of the atmel or do you have any
"preprocessing" ciruit like an amplifier, filter, buffer etc.?

If your input on the pin of the ADC is fine, only two possiblities
remain. You could have a faulty chip or some problem with your software.
I haven't read the datasheet of the atmega32, but I can't imagine any
misconfiguration that would produce random noise on the input. I once
had a problem with the ADC because I didn't wait long enough after
switching channels, so I got data from the wrong channel sometimes,
which produced strange results of course.

AS

Yes, the switching channels delay was a big gotcha for me as well.
Ken

> Gustavo Goretkin wrote:
>> I do have access to the scope, and the signal looks clean to me.
>> Furthermore, when I switch the two channels and axes, the error is
>> pertinent to the input channel of the ADC, and not the output of the
>> sensor
>
> Did you measure directly at the pin of the atmel or do you have any
> "preprocessing" ciruit like an amplifier, filter, buffer etc.?
>
> If your input on the pin of the ADC is fine, only two possiblities
> remain. You could have a faulty chip or some problem with your software.
> I haven't read the datasheet of the atmega32, but I can't imagine any
> misconfiguration that would produce random noise on the input. I once
> had a problem with the ADC because I didn't wait long enough after
> switching channels, so I got data from the wrong channel sometimes,
> which produced strange results of course.
>
> AS
>

Gustavo,

Assuming that the chip is good, fig 98 in the data sheet (pg 202) shows
channels 3 and 4 going directly into the input mux so, if properly configured,
thay should act identically.

Changing the REF select bits or putting the inputs into differential or
pseudo-differential mode by setting the MUX3 and/or MUX4 bits can lead to
unexpected values.

Have you verified the ADMUX register content?

Bruce

Thanks for the replies, all. It turns out the problem, of course, was 
due to a programming error on my behalf. Whenever channel 3's value was 
within a certain  deadband, I set the variable for the X acceleration 
AND the Y acceleration to zero instead of just the X acceleration. 
Certainly caused some interesting results.

Gustavo

Bruce Parham wrote:

>
> Gustavo,
>
> Assuming that the chip is good, fig 98 in the data sheet (pg 202) shows
> channels 3 and 4 going directly into the input mux so, if properly 
> configured,
> thay should act identically.
>
> Changing the REF select bits or putting the inputs into differential or
> pseudo-differential mode by setting the MUX3 and/or MUX4 bits can lead to
> unexpected values.
>
> Have you verified the ADMUX register content?
>
> Bruce
>
>

> ... a programming error...

I am forever amazed that a software error can so convincingly look like 
an unlikely and obscure hardware problem.


Tom

--- In AVR-Chat@yahoogroups.com, Gustavo Goretkin <gustavo@...> wrote:
>
> Thanks for the replies, all. It turns out the problem, of course, was 
> due to a programming error on my behalf....

hehehe - do you know this?
http://www.embedded.com/columns/esdeic/200001794?_requestid=882101


Chuckling greetings from Berlin, Germany,
Stefan