# LT Spice noise analysis

• posted

I wonder why it requires a noiseless input source to be specified.

Any why does it only analyze the noise at one node? Given that, why do I have to probe that one node?

```--
John Larkin         Highland Technology, Inc
picosecond timing   precision measurement  ```
• posted

Am 27.02.2017 um 20:21 schrieb John Larkin:

When the simulator knows where the input is, it can weigh all noise sources in how much they impair the input signal. A strong noise source that does not make it to the output is not interesting.

You can have as many components computed as you like and you can study their contribution to the result.

See <

>

The signal "gain" is predefined and does the obvious job.

The next picture shows the preamp in statu nascendi, it is still misbehaving. :-( ( 4 pairs of IF3602, they are all individuals; I'll have to spend another few hundred ??? to get 4 vaguely similar pairs.)

cheers, Gerhard

• posted

Not quite sure what you are saying here.

The point of knowing the input source is to calculate the equivalent input noise, referred to that source. For something like a bandgap voltage reference, there is no input source to refer it to. Only the output noise matters.

-- Kevin Aylward

- SuperSpice

• posted

Seems as though on modern hardware it ought to be possible to keep N**2 partial derivatives, so that you could change inoise and onoise without re-doing the analysis every time.

Cheers

Phil Hobbs

```--
Dr Philip C D Hobbs
Principal Consultant ```
• posted

If you are clever with .STEP analysis you can do just that (I am clever >:-}

Point of ease...

Doesn't matter WHERE you place the AC SOURCE... V(ONOISE), at your chosen node, will not change

V(INOISE) location is just a simulation subterfuge to calculate INPUT-REFERRED noise by calculating the gain from that node to the node you've designated for measuring V(ONOISE).

For a bandgap, use VDD as an AC source with a DC component equal to

+5V or whatever... measure V(ONOISE) at the bandgap output. ...Jim Thompson
```--
| James E.Thompson                                 |    mens     |
• posted

But LT Spice doesn't calculate input referred noise.

I just modified my circuit to add a new current source, dumping into a

1 ohm resistor, off to the side, connected to nothing else. And named that as the input reference device for the noise analysis. The gain from my new input device to the output is exactly zero.

The output noise didn't change. The named input device does nothing.

Besides, a circuit can have multiple inputs.

```--
John Larkin         Highland Technology, Inc
picosecond timing   precision measurement  ```
• posted

Am 01.03.2017 um 02:30 schrieb John Larkin:

Yes, it clearly does.

Compare the 680u.png and 6u8.png pictures:

Using only 6u8 for C1 (top center) does not kill the noise contribution of Q1 and D3 (5 times 1n4148 in series) for low frequencies. These are the gray and the white traces. And referred to the input, that clearly costs 30 pV/rtHz below 1KHz. It creates the bump in the top green line, which is v(onoise)/gain.

One can also see that it does not pay to use more than 680u because of the 1/f noise of the FETs. No need to swim faster than the shark. Faster than the neighbour is enough.

680uF: <
>

6.8uF: <

>

Without the active load and just a pull up, VCC noise was also a problem. That is modelled by R1=60 Ohm which delivers 1 nV/rtHz and this is multiplied to the desired noise density by E1.

V3, just 0 was needed to avoid a div by 0 or whatever. Whithout the current source load, 2nV/rtHz on VCC was limiting performance.

That would be OK if your previously used source also had a gain of 0.

Outch, scaling to the input would require division by gain, which is problematic for gain = 0.

In the worst case, that would require multiple runs. A differential input would not.

I happened to have this circuit in the simulator, it is in the middle of experimenting, not a finished work. But it was interesting to start with one BF862, identifying & eliminating the worst noise source and getting better by each iteration.

Cheers, Gerhard

• posted

So you keep telling us. ;)

But the simulator has to compute the exact same stuff over and over, which is a design wart.

Cheers

Phil Hobbs

• posted

Sure it does--INOISE is just V(ONOISE)/GAIN. LTspice has some curiosities with units in its plots, so I usually express GAIN as V(onoise)/inoise so I can plot input-referred noise due to various components.

Cheers

Phil Hobbs

• posted

Take it up with Berkeley... the method has never changed... all these years.

It's not like "over and over" is a big deal... noise/AC analysis occurs about as fast as you can blink. ...Jim Thompson

```--
| James E.Thompson                                 |    mens     |
• posted

And (AFAIK) all the copies and rewrites do it too. It's still a wart--numerical methods have come a long way since 1970, except in circuit design.

With discrete circuits, usually so. However, lots of IC models *cough* TI op amps *cough* have ugly convergence issues even with ".savebias internal", so waiting needlessly for that 50 times is annoying.

Cheers

Phil Hobbs

• posted

Take it up with TI and LTspice... LTspice had a lot of convergence issues with analog parts that other simulators don't.

(Also, You should read up on that important tool .STEP. You should be able to do component stepping within a single run... minimizing the bias recalculation.) ...Jim Thompson

```--
| James E.Thompson                                 |    mens     |
• posted

I can do that. How do I get Spice to do that?

And GAIN is not a number, it's a function of frequency.

My circuit is a transconductance amp, so GAIN is in ohms.

```--
John Larkin         Highland Technology, Inc

lunatic fringe electronics```
• posted

Nah, ragging you is way more entertaining.

I recall your having trouble with the OPA140 in PSPICE as well. And of course LTspice's price is right.

I use .step fairly often, but in LTspice it doesn't fix the bias issues. Changing resistors or voltages makes the bias different on each run.

Using .step to flip switches (nice infinitely differentiable ones) to connect INOISE to different places in the circuit shouldn't make the bias move, but for some reason with models like TI's OPA140 LTspice doesn't skip the entire bias calculation even with .savebias internal. (Super nice op amp, super crappy model.)

Cheers

Phil Hobbs

```--
Dr Philip C D Hobbs
Principal Consultant ```
• posted

Select the plot window, go ctl-A and type "inoise" into the dialogue box.

Cheers

Phil Hobbs

```--
Dr Philip C D Hobbs
Principal Consultant ```
• posted

OK, tried that. It shows V(inoise) as bigger than V(onoise), both in units of volts; my named input is a current source. The circuit has a gain of 3, 150 ohms Gm, so that makes no sense.

Hey, this is fun. I went to "edit simulation command" for noise and entered

V(AMP) as the output and

I(Ipd) as the input.

That made the thing go bezerk and made nonsense out of the sim parameters. Yes, it should have been V(AMP) and Ipd.

This is what it did to my setup:

This is the second time I managed to tie LT Spice in knots by entering an incorrect expression. Last time, I crashed it with mismatched parentheses, and Mike fixed it.

I can name a power supply as the input noise source, and it calculates my output noise as usual. If I then do the ctrl/A thing, I get a very weird input noise graph, a huge noise floor and a giant spike about 16 MHz.

I think I'll ignore the input noise thing. I have to name some source to get it to run, but apparently I can name anything. The calculated output noise does seem to make sense.

```--
John Larkin         Highland Technology, Inc

lunatic fringe electronics```
• posted

That is nice. TI is doing good linears lately.

My fave gumdrop is now OPA197. Cheaper than LM7301 and better.

```--
John Larkin         Highland Technology, Inc

lunatic fringe electronics```
• posted

Sure, the parser isn't very smart--it bumps you down to the next field when it gets confused.

There's probably a null in the transfer function. I nearly always have to change the vertical scale or do something like min(inoise, 100f) in the plot expression (that prevents the autoranging from screwing up the display when you re-run the sim).

I usually inoise in preference to onoise, because onoise is much harder to relate to the fundamental physics, which is what I usually care about. Inoise works fine.

Another nice thing is that LTspice does the right thing when you add noise contributions. For instance, in a front end with two parallelled JFETs Q1 and Q2, you can plot V(Q1)+V(Q2) and it comes out sqrt(2) times larger than just V(Q1) instead of doubled.

Cheers

Phil Hobbs

```--
Dr Philip C D Hobbs
Principal Consultant ```
• posted

Nice. 36V CMOS RRIO, reasonable noise, 70 cents. Drift fairly putrid, but not out of line.

Cheers

Phil Hobbs

```--
Dr Philip C D Hobbs
Principal Consultant ```
• posted

I know >:-}

I know how to model such creatures now, but have very little time to "play"... suddenly got busy :-)

Face it, LTspice is not that wonderful for lots of analog stuff. But I'm back into painful land... having to use Cadence Virtuoso for a customer... almost as bad a schematic entry as LTspice :-( ...Jim Thompson

```--
| James E.Thompson                                 |    mens     |