Electronics > KiCad

Bland Spices

(1/2) > >>

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: ---* /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
--- End code ---

SIMULATION1:


--- Code: ---**************************************************************
*  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
--- End code ---

OUTPUT1:


--- Code: ---#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

--- End code ---

OSLO2:  (working)


--- Code: ---* /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
--- End code ---

SIMULATION2:


--- Code: ---**************************************************************
*  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
--- End code ---

OUTPUT2:


--- Code: ---#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.
--- End code ---

{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.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version