Bland Spices

[6502nop]

Huh. There's no Spice/Sim category. Posting here.

Okay, EEVers, grab some coffee or popcorn whilst nop tells a long tale of head-banging frustration.

A while back, user king.oslo posted a schem {eev-xstrosc-oslo1.png} that featured a simple two-transistor astable oscillator that old timers have seen and played with dozens of times. Thing is, oslo couldn't get LTSpice to show it oscillating. He also couldn't get it working on a breadboard. Being one to try and help, I got it working on my breadboard without issue. In fact, unless I really hooked things up wrong, I couldn't get it to NOT oscillate! So, after many had posted their screenshots of the working circuit in LTSpice (and my mis-reading of the schem!), the thread seemed to have died. I'm guessing oslo figured it out, but it got me to thinking (always a bad thing, really...)

So, I fired up my Fedora Electronics Lab (FEL) programs that I never seem to use, as I prefer to test with  breadboard, perf, or dead-bug. I imported the schem into NGSpice (actually gSpiceUI, a front-end to NGSpice and GnuCAP), picked my nodes (<-does that sound funny?), and ran.

Flatline(s). Hmmm.

Over the last month (?), I have poked, edited, tweaked, and learned more about NGSpice than I ever thought I wanted to. I can't get this simple circuit to run. Aha! I also have GnuCAP installed, and it's just a simple click in gSpiceUI to send the data to it...

Flatline(s).

WhatTheFaraday? I've now got two simulators that can't model this right. So, I broke down and booted up Windows (gasp!) and ran LTSpice...

Flatline(s). Grrr!

I'm now beginning to understand why I breadboard things all the time. Lo! What light through yon Windows breaks? It is a sub-directory called "examples" - and it has an astable two-transistor circuit {eev-xstrosc-oslo2.png}! It's not set up like ours, but it's pretty darn close, so...

Huh. It works great.

Hey! Let's use LTSpice's circuit in NGSpice/GnuCAP and see what happens, shall we? Let's shall...!

Huh. It works great. Well, kiss my shiny metal a...

This is where all the head-banging comes into play. If oslo2 schem works in my sims, but oslo1 doesn't, that means:
1) NGSpice/GnuCAP works.
2) My 2N2222 model works (downloaded from Zetex - thanks, guys!).
3) My parameters are set/reading right.

So, that means something is wrong with the circuit (which is proven good on my breadboard), or there's something that oslo and I are doing wrong that we're not seeing. Hopefully, someone out there more acquainted with Spice can spot the problem.

Models: Built-in for voltage, resistors, and caps. Thinking that maybe the pins were screwed up for the generic BJT-NPN model, I downloaded and used the one I labeled "Q2N2222". Since this model was used with the working LTSpice example (oslo2), I know it's good. So, this is the output of oslo1 from gSpiceUI before sending it to NGSpice:

OSLO1:  (NOT working)

Code: [Select]

* /usr/bin/gnetlist -v -g spice-sdb -o ~/Documents/eev/spice/eev-xstrosc-oslo1.ckt ~/Documents/eev/spice/eev-xstrosc-oslo1.sch
*********************************************************
* Spice file generated by gnetlist                      *
* spice-sdb version 4.28.2007 by SDB --                 *
* provides advanced spice netlisting capability.        *
* Documentation at http://www.brorson.com/gEDA/SPICE/   *
*********************************************************
*vvvvvvvv  Included SPICE model from ~/Documents/elec-sch/models/q2n2222.mod vvvvvvvv
.MODEL Q2N2222 NPN (IS=61.0f NF=1.00 BF=410 VAF=114 IKF=0.121 ISE=14.8p NE=2.00 BR=4.00 NR=1.00 VAR=24.0 IKR=0.300 RE=0.269 RB=1.08 RC=0.108 XTB=1.5 CJE=27.6p VJE=1.10 MJE=0.500 CJC=15.0p VJC=0.300 MJC=0.300 TF=496p TR=84.1n EG=1.12)

*^^^^^^^^  End of included SPICE model from ~/Documents/elec-sch/models/q2n2222.mod ^^^^^^^^
*
*==============  Begin SPICE netlist of main design ============
Q1 3 1 0 Q2N2222
Q2 2 4 0 Q2N2222
Vcc 5 0 DC 9V
R3 1 5 3310 
R4 2 5 1000 
R1 3 5 1000 
R2 4 5 3300 
C1 3 4 100nF 
C2 1 2 100nF 
.end
SIMULATION1:

Code: [Select]

**************************************************************
*  Electronic circuit simulation file generated by gSpiceUI  *
*             Version 0.9.98 Alpha (14/10/2009)              *
**************************************************************

* Schematic : ~/Documents/eev/spice/eev-xstrosc-oslo1.sch

* Component Definitions
C1 3 4 100nF
C2 1 2 100nF
Q1 3 1 0 Q2N2222
Q2 2 4 0 Q2N2222
R1 3 5 1000
R2 4 5 3300
R3 1 5 3310
R4 2 5 1000
Vcc 5 0 DC 9V

* Model Definitions
.MODEL Q2N2222 NPN (IS=61.0f NF=1.00 BF=410 VAF=114 IKF=0.121 ISE=14.8p NE=2.00 BR=4.00 NR=1.00 VAR=24.0 IKR=0.300 RE=0.269 RB=1.08 RC=0.108 XTB=1.5 CJE=27.6p VJE=1.10 MJE=0.500 CJC=15.0p VJC=0.300 MJC=0.300 TF=496p TR=84.1n EG=1.12)

* NG-Spice Simulation Commands
.OPTIONS NOPAGE NUMDGT=6 UNITS=Degress WIDTH=104
.PRINT TRAN V(3,5) V(4)
.TRAN 10.00m 100.00m 0.00m

.END
OUTPUT1:

Code: [Select]

#time          V(R1)         V(4)
 0.00E+00     -8.97E+00      6.96E-01     
 {All the same - flatline}
 9.86E-02     -8.97E+00      6.96E-01     
 1.00E-01     -8.97E+00      6.96E-01

OSLO2:  (working)

Code: [Select]

* /usr/bin/gnetlist -v -g spice-sdb -o ~/Documents/eev/spice/eev-xstrosc-oslo2.ckt ~/Documents/eev/spice/eev-xstrosc-oslo2.sch
*********************************************************
* Spice file generated by gnetlist                      *
* spice-sdb version 4.28.2007 by SDB --                 *
* provides advanced spice netlisting capability.        *
* Documentation at http://www.brorson.com/gEDA/SPICE/   *
*********************************************************
*vvvvvvvv  Included SPICE model from ~/Documents/elec-sch/models/q2n2222.mod vvvvvvvv
.MODEL Q2N2222 NPN (IS=61.0f NF=1.00 BF=410 VAF=114 IKF=0.121 ISE=14.8p NE=2.00 BR=4.00 NR=1.00 VAR=24.0 IKR=0.300 RE=0.269 RB=1.08 RC=0.108 XTB=1.5 CJE=27.6p VJE=1.10 MJE=0.500 CJC=15.0p VJC=0.300 MJC=0.300 TF=496p TR=84.1n EG=1.12)

*^^^^^^^^  End of included SPICE model from ~/Documents/elec-sch/models/q2n2222.mod ^^^^^^^^
*
*==============  Begin SPICE netlist of main design ============
Q1 1 3 0 Q2N2222
Q2 4 2 0 Q2N2222
Vcc 5 0 DC 9V
R3 2 4 100K 
R4 4 5 2200 
R1 1 5 2200 
R2 3 1 101K 
C1 3 4 0.01uF 
C2 1 2 0.01uF 
.end
SIMULATION2:

Code: [Select]

**************************************************************
*  Electronic circuit simulation file generated by gSpiceUI  *
*             Version 0.9.98 Alpha (14/10/2009)              *
**************************************************************

* Schematic : ~/Documents/eev/spice/eev-xstrosc-oslo2.sch

* Component Definitions
C1 3 4 0.01uF
C2 1 2 0.01uF
Q1 1 3 0 Q2N2222
Q2 4 2 0 Q2N2222
R1 1 5 2200
R2 3 1 101K
R3 2 4 100K
R4 4 5 2200
Vcc 5 0 DC 9V

* Model Definitions
.MODEL Q2N2222 NPN (IS=61.0f NF=1.00 BF=410 VAF=114 IKF=0.121 ISE=14.8p NE=2.00 BR=4.00 NR=1.00 VAR=24.0 IKR=0.300 RE=0.269 RB=1.08 RC=0.108 XTB=1.5 CJE=27.6p VJE=1.10 MJE=0.500 CJC=15.0p VJC=0.300 MJC=0.300 TF=496p TR=84.1n EG=1.12)

* NG-Spice Simulation Commands
.OPTIONS NOPAGE NUMDGT=6 UNITS=Degress WIDTH=104
.PRINT TRAN V(2,4) V(4)
.TRAN 10.00m 100.00m 0.00m

.END
OUTPUT2:

Code: [Select]

#time          V(R3)         V(4)
 0.00E+00     -1.18E+00      1.82E+00     
~
 8.56E-03     -1.19E+00      1.83E+00     
~
 1.22E-02     -3.46E+00      4.09E+00     
~
 1.23E-02      6.20E-01      3.89E-02     
~
 1.24E-02     -1.09E+01      2.79E+00     
~
 1.25E-02     -1.52E+01      8.60E+00     
~
 1.96E-02     -1.05E+00      1.69E+00     
 1.96E-02     -1.05E+00      1.69E+00     
 1.96E-02     -1.05E+00      1.69E+00     
 1.96E-02     -1.05E+00      1.69E+00     
 1.96E-02     -1.05E+00      1.70E+00     

Text control maximum line count (ie. 1000) reached.
{the ~ lines are edits for brevity, as if this wasn't long enough already!}

As you can see, the oslo1 run doesn't change, but the oslo2 is spot on. The last picture is the gwave plot of the oslo2 data, which matches what LTSpice shows.

So, any guesses? Is it me, Spice, or the circuit?

nop

Note: Yes, I've tried both "Warm" startup and "Cold" startup options. Cold startup just adds "UIC" to the tran line - (Use Initial Condition).

[AndyC_772]

Hi,

I tried your first circuit (eev-xstrosc-oslo1.png) in LTSpice, and I agree it doesn't start oscillating. Instead it sits in a perfectly valid, stable state in which both transistors are on, and both capacitors are charged to about 0.7V. Admittedly in real life the circuit may never actually enter this state, but it's not 'wrong'.

What it needs is a kick to get the simulated circuit oscillating. I'm sure there are plenty of ways to achieve this, but I did it by including a resistive element which grounds the base of one of the transistors at time t=0, then goes away after a short delay. In LTSpice, one way to achieve this is to include a resistor with a value equal to "R=V(kick)", where "kick" is the name of a labelled node elsewhere in the circuit. In my circuit, that label is applied to a voltage source which equals 1V at t=0 and changes to 1MV at t=100msec. This results in a resistor which has a value of 1 Ohm at t=0 (to force the oscillator into an asymmetric state), and which becomes 1 MOhm after 100ms in order to let the circuit oscillate.

This is quite a handy technique which I often use to model switches and potentiometers, or which I use to try and seek out optimum resistor values in circuits without having to run lots of separate simulations or get buried in maths.

With the circuit forced into an asymmetric state, it oscillates just as expected.

[Bored@Work]

Oscillators not oscillating in SPICE is typical.  The initial search for a quiescent DC operating point is a search for a balance in the circuit. If one is found and there is nothing time-wise in the circuit tipping the balance over then the circuit will sit there for ever.

The more stable the found balance is, the harder it is to start the oscillation, because a disturbance of the balance might just result in the circuit drifting back to the quiescent state instead of starting to oscillate.

A solution is to specify an initial condition for a relevant component, e.g. a voltage over a cap, or a current through an inductor, different from what would be found in the DC operating point search. Specify the UIC flag (Use Initial Conditions) to the .TRAN statement, and specify an IC for one or both of the caps.

[6502nop]

You two realize you've provided me with more info than over 50 or so tutorials and boring vids on YT?

Man, I love this site!

Anyway, I got the damned thing to oscillate!

Andy's suggestion to "kick" the thing had me wondering. See, in the oslo1 schem, I had intentionally set R3 to 3310R to make sure that it didn't stall, as current through a 3300 (R2) is different from a 3310 (R3). You'll note that LT did the same thing in their circuit, too (101K vs. 100K). I had this problem figured out about ten minutes into my first simulation. Since it didn't work, I then tried 4K7/4K71, then 10K/10K1, etc., to no avail.
What I didn't try was to make R2 vastly different from R3 (that "kick" this circuit needed). So, I just tried using 3300/4700, and... It works!

Now, armed with the info Andy and Bored provided, I then started dropping the value of R3 until I no longer got that kick. Turns out that NGSpice wants that to be 3365R (1.96969~% tolerance). If I use 3364R (1.93939~% tol.), it flatlines.

Which seems odd to me, as Spice should be able to model with better than 1% tolerances?

So, my new rule-of-thumb is to vary similar sections of circuits by at least 5% to ensure that the model is doing what it should.

Thanks, guys! 

nop

[free_electron]

The reason that 10 ohms has no impact is that in this circuit the transistors run in saturation mode. They are on or off. 10 ohms on 3k makes no difference for saturation...

Try tweaking the transistors instead... Male a model 2n2222a and give it a beta of 100 , make a 2n2222b and give it a beta of 200 and a slightly altered set of parameters. It will oscillate like a charm.

I know that in our ic design tools ( eldo ) there is an option to include component drift and a flag that tells the simulator this is intended to be an oscillator. You can specify the percentage of parameter drift from transistor to transistor.

[codeboy2k]

Likewise, I often use the param and step statements in spice to simulate components with non-ideal values, i.e. within their 5% range for resistors and 20% range for capacitors. I do this for oscillators and amplifiers. 

I don't know if spice has a random operator, but it just occurred to me that several runs with random values within their tolerances would also be helpful.  I know there is a monte carlo method of spice simulation, but I admit I've not used it. Maybe this is what I want. I do like the monte carlo simulations in Elsie .

And as free_electon says, vary the beta on your transistors.  This can be one of the most widely varying values in your designs, they can vary from device to device by as much as %50 up to %100.

[6502nop]

Thanks, again, folks!

codeboy, I'm not new to the rodeo (electronics), just this particular event (Spice). Not a single tutorial I read through or watched mentioned anything about stepping or parameters. I finally found them in gSpiceUI, and thanks to the four of you here, I now know what they're for.

The reason that 10 ohms has no impact is that in this circuit the transistors run in saturation mode. They are on or off. 10 ohms on 3k makes no difference for saturation...

Funny you should mention that. Remember how I said things get bad when I start thinking? Well...

I plotted out how this circuit (oslo1, above) would behave with a (for want of a better term) "parameter spread". What I did was to use a stepping value for R2/R3, and plot what value of increase would get it to oscillate. So, if R2=3300, then R3=3365 to kick it in gear. So, what if R2/R3 was 10K, etc.? A good trend would be to step up using "10" and "47" values, thus:

Code: [Select]

OSLO1 Tank value analysis

 Resistor variance with C1/C2 set at 100nF

R2 R3 Delta Notes

100 100 N/A *Still wouldn't work with R3=10K
1000 1555 555 *Not quite full rails - dies out {gwave-1555.png}
3300 3365 65 <Original values
4700 4750 50 Runtime set to 100mSec
10000 10001 1
47000 47001 1
100000 100001 1 
470000 470001 1  Altered runtime to 1Sec
1000000 1000001 1 
4700000 4700001 1  Output triangle wave low level {gwave-4M7.png}

 Cap variance with R2/R3 set at 10K

C1 C2 Delta var Notes

10p 10p N/A >1nF *Runtime set to 1mSec
47p 47p N/A >1nF *Runtime set to 1mSec
100p 435p 335p *Runtime set to 1mSec
470p 470.002p .002p Runtime set to 10mSec
1n 1.000008n .008p Runtime set to 10mSec
4.7n 4.701n 1p Runtime set to 50mSec
10n 10.8n 800p Runtime set to 50mSec
47n 47.004n 4p Runtime set to 100mSec
100n 100.001n 1p  <Original values
470n 470.001n 1p Runtime set to 100mSec
1u 1.000001u 1p  Runtime set to 100mSec
4.7u 4.700001u 1p Runtime set to 1Sec
10u 10.000001u 1P Runtime set to 1Sec
47u 47.000001u 1p Runtime set to 10Sec
100u 100.000001u 1P Runtime set to 10Sec
470u 470.000001u 1p Runtime set to 20Sec
1000u 1000.000001u 1p Runtime set to 20Sec
4700u 4700.000001u 1P Runtime set to 30Sec
Which is quite interesting. The top 2 resistor values and the top three caps (*marked with asterisks) didn't work, or worked for a few uSecs and died out {gwave-1555.png}. What really surprised me was that all you needed was one ohm difference once you hit the 10K mark. I'm guessing the small value caps are more to do with the transistor model, as it has a peculiar jump in the delta around the 10-47nF ranges.

What this tells me is that Spice can, indeed, handle very low tolerance values. So, I guess those low values (and high ohms >1M) make it go crazy?

Back to the breadboard:

using 100Rs = NO oscillation.
using 1Ks = NO oscillation.
using 2K2s = It's Alive!

I then set to find that ~1K5 was the sweet spot. Spice got it right for these. Now, on to the caps...

using 10p = NO oscillation.
using 47p = NO oscillation.
(didn't have any 100/470pF or 1/4.7nFs) <--on my shopping list!
using 10n = Good.

I'm pretty sure Spice got these right, too. So, it does appear that tolerance is the problem here... maybe!

See, a funny thing happened with those high-value resistors (4.7/10M) - Spice said they wouldn't work, and would give you a really funky output {gwave-4M7.png} when they tried. They worked fine on the breadboard. Again, I'd put that down to transistor modeling or somesuch.

All in all, Spice seems to be doing the job. However, if it weren't for the four of you, and this forum, I'd probably have given up and called Spice a complete load of garbage. Documentation is sparse. Tutorials seem to assume you know how to edit or pass parameters or use advanced features, so they don't bother showing you how.

Maybe Dave can make a Spice/Sim section here, and make this THE place to go to learn the ins and outs of these programs?

With gratitude,
nop