AT90USB647 and LM358 problem

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

Using the AT90USB647 PINF[1] as a digital input (without pull up), I try to read a manchester encoded data that is coming from the output of an LM358 opamp. The opamp is used as a non-inverted amplifier:

                        5V 
                        ===          
                      |\ | 
                      | \| 
----------------------|+ \ 
                      |   \ 
                      |   /----------- PINF[1]
                ------|- /      | 
               |      | /|      | 
               |      |/ |      | 
               |        ===     | 
               |                | 
               |------100K------ 
               | 
              10 Ohm 
               | 
              === 
               - 

The oscilloscope is connected to the output of the opamp and when using this function I can see the manchester encoded data.

while(1){
    __watchdog_reset();
}

But when I pole the PINF[1] like this:

while(1){
    if (PINF_Bit1){
        ....
    }
    else{
        ....
    }
    __watchdog_reset();

}

then something mysterious is happened. The manchester data is changing it's level randomly and in higher frequency than the original one. It seems like when I test the PINF[1] pin something causes the data voltage level, to be change randomly.

Do you have any idea?

Thank you.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In addition of my first post I made a test. I disoldered the the PINF[1] pin from the opamp output and I run the same routine:

while(1){ 
    if (PINF_Bit1){ 
        .... 
    } 
    else{ 
        .... 
    } 
    __watchdog_reset(); 

}

Now the opamp data is Ok, but the uC cannot read it.

What do you think?

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

CAST AWAY

Help............................

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys, please take a look to this problem.

HHHHHHHHEEEEEEEELLLLLLLLLPPPPPPPPPP..............

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using 100k and 10 ohm resistors the gain is 10001,if there is no a typing error i think this gain is too much because 5v/10001=500uv or less input is needed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not my problem. Yes, the input is too small sometimes, lower than 5mV. This circuit works fine.

My problem is that if this circuit is connected to an input works fine. But each time I write instructions to read the data coming from the opamp output, these data are changed. I could say that they are corrupted.

I changed the input pin with another one from another port, but the results are the same.

Hell. What is going wrong?

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With that much gain you are probably just getting noise on the AVR input pin. Have you checked it with a scope?

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of signal feeds the non inverting input of the operational amplifier ?
Frequency, Vlow, Vhigh, almost sinewave, perfect squarewave ?

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a manchester encoded signal (1 and 2KHz square waves) in the input of the LM358. The voltage is Vpp = 5 to 100mV.

When I use this function:

while(1){ 
    __watchdog_reset(); 
} 

I see the data at the AVR input just fine.(DDRF[1] = 0, PORTF[1] = 0, DIDR0[1] = 0)

But when I use this function:

while(1){ 
    if (PINF_Bit1){ 
        .... 
    } 
    else{ 
        .... 
    } 
    __watchdog_reset(); 

} 

The changes between 0 and 1 at the input of the AVR are irregular and the signal is not periodical.

I change the connection to another input, from another port of the AVR, but the results was the same.

Also while using the second function with the PINF[1] disconnected, the data is ok and when I reconnect it, the problem arears again.

It makes me crazy.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The input impedance of non inverted input as seen in the scheme is infinite,it depends actually from the output impedance of the circuit that is connected.If it is very high and in combination with high gain it might getting noise and amplifies it,or the opamp might self oscillating.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope you know that the max output of a LM358 at 5V is only 3.5V max at best.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the most datasheets, LM358 has an open loop gain of over 100dB in DC, but only 50dB at 2kHz. That makes a gain of 300 without any negative loop, so you external resistor divider trying to set the gain to 10,000 is useless, because the opamp acts as an open loop one at that frequency. That makes it very unstable, maybe even self oscillating at any random stimulus and susceptible to noise.

My decision would be to use the entire LM358 package (if must be this one) as follows:

first stage opamp as a 3kHz low pass filter with DC gain set to 50, followed by the second stage acting as a hysteresis comparator (0.15V, +/- 50mV) for covering the entire input range 5-100mVpp. The comparator's output has to be tied to V+ by a 1-10K resistor because LM358 will output only 3.5V as John already told you.

Depending by your signal source i would also consider AC coupled input.
The voltage supply must be separated by the digital circuit by an RC or LC filter, decoupling must be well done and analog ground tied in only one point to the digital ground.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys,

I red very carefully your answers. Yes I know it is not a rail to rail. Before reading your answers, I made some tests, yesterday night. I connected the same circuit output to an ATmega48 and F..K, it works fine.

Why is this happening???

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

icarus1 wrote:
Guys,
I red very carefully your answers.

I doubt, 3 people told you about noise and too much gain.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok,

A gain of 10000 is too much. I will set it to a level of 300 and I will post the results.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most likely is to be no change and if it is, the circuit will be unreliable IMO. You already had that gain of 300 (50dB) at 2kHz however you set it equal 300, 1000, or 10,000.
Check the datasheet, the open loop gain of LM358 at 2kHz is 50dB = 300. You can't make it higher whatever resistors you put or not.
Trying to set it to 10,000 or 300, or just not adding any resistor will keep gain to 300. However you set it as 300, it will behave as an open loop opamp with all its troubles at that frequency.

All you can do is to lower it. If you want those simple relations between resistors and gain to be almost true, and thus have a predictable circuit, you have to accept only 1/10 of open loop gain as your maximum gain. That makes 30 at 2kHz and I suggested 50.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, changed the divider to a gain of 46 (100K and 2K2).

Guess...

The problem still remains.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Itdor gave you a good solution above, use both op-amps in the package. The first as an amp, the second as a comparator with the threshold set midway between the low and high values outputed by the first stage.

Incorporating the LPF into the first gain stage is a good idea, but probably not entirely needed.

Set the threshold for the comparator stage with a pot, and use your scope to see the signal from the first stage.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JC,

All you here, told me to decrease the gain from 10000 to a physical level. Ok I did it. Now the value of gain is 46.

As I told you before, the problem still remains.

Also, I think that doing this solution (a comparator before the uC), it means that the problem must remain, because the comparator has infinite gain. This reminds me the solution with the 10000 gain.

Before doing changes to the circuit that currently seems that is working fine, I think that it's better to find why the problem still apears.

Guys, a devil lives in my pcb. I think I show his tail behind a capacitor.

Can you spend some more time for my problem?

Thanks.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If a different type of AVR lives with your circuit fine, the problem is somewhere in the configuration of your pins, potentially affected by something you hide behind the "...." in your conditional statement. Unfortunately, this means that the datasheet has to be studied carefully many times: Atmel doesn't like to mention same thing twice.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A comparator has infinite gain indeed, but it also has hysteresis you may set how you wish for avoiding instability. Interfacing analog to digital is always done with comparators. Operational amplifiers are used just to make the analog level suitable for comparator.

One thing is still not clear for me. How are you seeing these devilish higher frequency transitions ? Analyzing data received by AVR, or viewing waveform on scope ? If you see them on your dual channel oscilloscope, can you figure if they appear at a specific analog level or they are really random ? They appear whatever your analog signal is 5mVpp or 100mVpp ?

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. I made the tests using an ATmega48PV and the citcuit works fine. I mean that I just connected the same circuit to a uC input, using the same program.

2. svofski, the "..." is just:

while(1){ 
    if (PINF_Bit1){ 
        .... 
    } 
    else{ 
        .... 
    } 
    __watchdog_reset(); 

} 

where pinTest is a digital output. I use it to connect the scope in order to see what the AVR read.
Also, I have checked the pin configuration a handred of times (DDRF, PORTF, DIDR0, PUD). I wish I had a problem to these configurations.

3. ltdor, that's correct about the comparator, but the circuit works fine and that's make me searching in other ways.
Yes I read the data using the scope. I also see them at the pinTest with the scope. This phenomenon apears whenever I test the PINF_Bit1, for any voltage.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you've pasted the wrong snippet, same "...." there.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oooops sorry.

while(1){ 
    if (PINF_Bit1){ 
        pinTest = true;
    } 
    else{ 
        pinTest = false;
    } 
    __watchdog_reset(); 

} 

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW, now that you're using PORT F, what is the state of your JTAGEN fuse bit?

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the PINF[1] has clear logic levels of random 0 and 1 on scope, my opinion is they are set this way by the op-amp. It's not about PINF[1] becoming output from time to time and shorting two outputs.
My bet would be that different instructions generate different supply currents which triggers false flip-flops in the op-amp especially when the input signal is in the mid-range. That is why i would use a comparator with hysteresis.

However, is worth checking if these problems still appears when the analog input is at steady 0V and 5mV.
Would be also good to temporary put a 10K resistor between analog input and ground and see if it helps.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
BTW, now that you're using PORT F, what is the state of your JTAGEN fuse bit?

The same problem apears for both cases (JTAGEN = 1 or 0).

Quote:
If the PINF[1] has clear logic levels of random 0 and 1 on scope, my opinion is they are set this way by the op-amp. It's not about PINF[1] becoming output from time to time and shorting two outputs.
My bet would be that different instructions generate different supply currents which triggers false flip-flops in the op-amp especially when the input signal is in the mid-range.

Running this code and seeing the data input using the scope, it shows me the problem. Now while the program is running I cut the line that connects the opamp output with the digital input, having the scope connected at the opamps side, I see the data are Ok. This could be happened if the uC pin would act as an output, like you say, but I have checked it and it is an input.
Ah, I have an idea here, I will connect another probe at the uC, side and I will do the same test. Maybe the scope will show me something new.

Quote:
Would be also good to temporary put a 10K resistor between analog input and ground and see if it helps.

Yes, I did this test before, but nothing.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about not directly connecting the op-amp output to the uC, but using a 1-10K resistor ? Would be interesting if the evil stays alive.

Dor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking to do something like this, because I found that the input capacitance is 10pF.

Please wait some minutes to post the result.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried the 10K in series but this causes nothing.

Ooooooooofffffffff.........

It's crazy.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nothing means that the waveforms are scrambled in the same way at op-amp output and uC input ?

Dor