It would need updating of the GUI, but not of the simulator engine. I've heard that GUI coding is actually harder than most other coding.
There is ONE other way I know of that we could get consistent simulator results. In the .lib or .inc directives you can in fact use a URL. So you can do
.inc http://spicemodels.net/goodmodels.bjt
The downside is, every time you run a simulation, it will download the file. So for instance if we dedicated a webserver to host goodmodels.bjt, and started sharing schematics with the directive on it, those schematics would multiply and soon there would be so many people using that directive on their schematic and downloading the file for each simulation, the server would be overloaded. We can't expect people to nicely comment the line as is suggested in the manual. But, if we could persuade the LTSpice coder to adjust the directive to stop redundant downloads, this would be an excellent solution to crappy modelsets.
I had an interesting idea. To collect verified models, we could make a wiki page. We would have a list of parts going down the page and we would have a Y axis with each of our names. The part numbers would link to SPICE models and anyone who tested if the model was accurate would add their name and put a pass/fail in their box for the part. This way we could keep track of all the good models and there wouldn't be much reason for anyone to use the bad ones anymore.
There is ONE other way I know of that we could get consistent simulator results. In the .lib or .inc directives you can in fact use a URL. So you can do
.inc http://spicemodels.net/goodmodels.bjt
The downside is, every time you run a simulation, it will download the file. So for instance if we dedicated a webserver to host goodmodels.bjt, and started sharing schematics with the directive on it, those schematics would multiply and soon there would be so many people using that directive on their schematic and downloading the file for each simulation, the server would be overloaded. We can't expect people to nicely comment the line as is suggested in the manual. But, if we could persuade the LTSpice coder to adjust the directive to stop redundant downloads, this would be an excellent solution to crappy modelsets.
I had an interesting idea. To collect verified models, we could make a wiki page. We would have a list of parts going down the page and we would have a Y axis with each of our names. The part numbers would link to SPICE models and anyone who tested if the model was accurate would add their name and put a pass/fail in their box for the part. This way we could keep track of all the good models and there wouldn't be much reason for anyone to use the bad ones anymore.
Very frustrating and that has happened to me countless times. Anyone putting a .asc file up really should ensure it will run on a standard install of LT without the user having to resort to chasing models or trying to select other devices that are in the library.
What will you do if the models included are misleading?? Answer: you will waste your time. What if you already know which one is right and which one is wrong?? Answer: you won't need the models attached (you have your own).
So it is probably a good idea (Keantoken's) to create a common system to validate models.
And that's often cited as a justification for pasting the models into the *.asc circuit file: The original designer's applicable models are right there in the circuit file.
Circuit files posted to the LTSpice Yahoo Group are usually pretty good about including the models in the circuit file, or providing a separate *.lib file containing models not included in the standard-install "standard.*" files. (I think Helmut might enforce this practice.)
Your idea isn't too much different from the current "Standard.*" files that come with LTSpice, except you have added some traceability information to each model's data. Mike has already "extended" the syntax for SPICE models by adding fields (e.g., "Vceo=", "Mfg=", etc) for the LTSpice Component Selector tools to sort on. Adding fields such as "Verified_By=" or "Verify_Date=" should be straightforward.
In its full implementation I don't think your idea accounts for the propensity of simulation models to proliferate. Such a Blessed File of All Known Models would quickly become unwieldy.
Start with the notion of what constitutes a "good" model. OK, I know that some published models are just plain lousy, and we all can agree on that . . . yet components with identical part numbers but produced by different manufacturers can have legitimate differences in performance. Designers may develop different models for different manufacturers' parts, each of which is equally "good" in its context but not across the whole spectrum of components with that part number.
Then there are all the occasions when it is proper to alter a "good" model to reflect some situation of particular interest. You may customize a model to reflect a component's data sheet "best case" performance, or "worst case" - of course, the definitions for "best" and "worst case" will depend on the application. You may want a model customized for a particular operating point - the recently revised MOSFET models accounting for sub-threshold conduction are examples. Simply maintaining an up-to-date catalog of all the models in the "Goodmodels" file is a challenging task, much less replicating the file every time you start a simulation session.
Dale
Yeah, unfortunately it is true. Even some knowledgeable members here have been circulating misleading models. No wonder many people think that simulation doesn't tell anything. But it is hard to define a "good" model because what we need is to understand what has been assumed in the modelling.
In my hard disk crash 2 years ago I lost many models and I couldn't find the right models any more. Especially with opamps, I had all models for opamps that I have (I have plenty). Now I couldn't find them anymore on the net
. Even when I found it (on the net) it doesn't work like in the real circuit 
If only for learning exercise, e.g. by understanding the consequence of inaccurate models, why not just replace the components with the ones in the LTSpice library. It is OUR library (the one in our harddisk) that suppose to have sufficient models.
It is possible using the AKO model syntax to get LTSpice to substitute the schematic's dumb models with your improved models even if the original models are missing. This is a way to make almost any simulation instantly usable even if the models were omitted. However you have to write up the list of substitutions, so it only works if you already have a collection of good models to go with it.
What I do is put all the extras in the directory with the asc file and zip it up. Then when you uncompress the zip file and launch the asc from the directory it automatically picks up the extras even if the person doesn't have them.
The attached zip file has various LM317 circuits in it, there is no LM317 model in the ltspice libraries (and at least one of the circuits also has a bc560C transistor model and a potentiometer also not included in the base LTspice libraries, however you should be able to unzip this and run any of the models present without issues.
Note that the LM317 model in this zip file has been modified by me to make it more accurate (I can't remember exactly but the voltage reference was off in the original model). Note also that it is limited in current output. I can't remember what the limit is but I think if you try to model more than about an amp it will become very inaccurate.
I uploaded it at the request of Bonsai in this thread http://www.diyaudio.com/forums/powe...ng-lm3x7-regulator-circuit-7.html#post3328300 there is a bit more info in that post
Great thread by the way Mooly... I've been watching it on and off, but hadn't seen any thing I thought I could add, but in this case I thought I could add something useful
Tony.
Last edited:
That is something I have never tried. I'm not quite following you actually because the error log shows the transistor currents for all the devices... you mean something else ?
Code:
.save ie(Q7)
.save ie(Q8)
.measure op ie(Q7)
.measure op ie(Q8)CTRL L :
Code:
--- Operating Point ---
Ie(Q8): -0.0139259 device_current
Ie(Q7): 0.0139787 device_currentdiagram.log :
Code:
Warning: Multiple definitions of model "z8_2" Type: Diode
Early termination of direct N-R iteration.
Direct Newton iteration failed to find .op point. (Use ".option noopiter" to skip.)
Starting Gmin stepping
Gmin = 10
vernier = 0.5
vernier = 0.25
vernier = 0.125
Gmin = 5.5165
vernier = 0.0625
vernier = 0.03125
vernier = 0.015625
vernier = 0.0078125
Gmin = 5.48432
vernier = 0.00390625
vernier = 0.00195313
vernier = 0.000976563
vernier = 0.000488281
Gmin = 5.48098
Gmin = 0
Gmin stepping failed
Starting source stepping with srcstepmethod=0
Source Step = 3.0303%
Source Step = 33.3333%
Source Step = 63.6364%
Source Step = 93.9394%
Source stepping succeeded in finding the operating point.
Semiconductor Device Operating Points:
--- Diodes ---
Name: d:u2:q2 d:u2:q1 d:u2:p d:u2:ln d:u2:lp
Model: u2:dx u2:dx u2:dx u2:dx u2:dx
Id: 1.36e-04 -6.70e-13 -6.84e-11 -2.59e-11 -2.61e-11
Vd: 6.69e-01 -6.69e-01 -6.84e+01 -2.59e+01 -2.61e+01
Req: 1.90e+02 1.00e+12 1.00e+12 1.00e+12 1.00e+12
CAP: 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00
Name: d:u2:e d:u2:c
Model: u2:dx u2:dx
Id: -2.92e-11 -2.92e-11
Vd: -2.92e+01 -2.92e+01
Req: 1.00e+12 1.00e+12
CAP: 0.00e+00 0.00e+00
--- Bipolar Transistors ---
Name: q8 q7
Model: 2n3440 2n5416
Ib: 1.40e-04 -1.92e-04
Ic: 1.38e-02 -1.38e-02
Vbe: 6.70e-01 -6.28e-01
Vbc: -3.37e+01 3.37e+01
Vce: 3.44e+01 -3.43e+01
BetaDC: 9.87e+01 7.16e+01
Gm: 4.17e-01 5.31e-01
Rpi: 1.96e+02 1.25e+02
Rx: 0.00e+00 0.00e+00
Ro: 9.70e+03 9.69e+03
Cbe: 7.62e-10 2.53e-09
Cbc: 5.78e-12 8.64e-12
Cjs: 0.00e+00 0.00e+00
BetaAC: 8.16e+01 6.61e+01
Cbx: 0.00e+00 0.00e+00
Ft: 8.64e+07 3.32e+07
--- JFET Transistors ---
Name: j:u2:2 j:u2:1
Model: u2:jx u2:jx
Id: -1.01e-04 -1.01e-04
Vgs: -7.42e-02 -7.42e-02
Vds: -3.37e+01 -3.37e+01
Gm: 1.88e-04 1.88e-04
Gds: 0.00e+00 0.00e+00
Cgs: 0.00e+00 0.00e+00
Cgd: 0.00e+00 0.00e+00
--- VDMOSFET Transistors ---
Name: m4 m2 m3 m1
Model: 2sj162c 2sj162c 2sk1056c 2sk1056c
Id: -1.53e-01 -1.53e-01 1.53e-01 1.53e-01
Vgs: -5.01e-01 -5.01e-01 5.75e-01 5.75e-01
Vds: -3.50e+01 -3.50e+01 3.50e+01 3.50e+01
Vth: -8.00e-02 -8.00e-02 2.00e-02 2.00e-02
Gm: 9.07e-01 9.07e-01 6.64e-01 6.64e-01
Gds: 3.40e-03 3.40e-03 1.80e-03 1.80e-03
Cgs: 9.00e-10 9.00e-10 6.00e-10 6.00e-10
Cgd: 1.92e-11 1.92e-11 9.28e-12 9.28e-12
Cbody: 1.80e-10 1.80e-10 1.62e-10 1.62e-10
Note: .fourier statements are only valid with a .tran command.
No Fourier analysis performed.
ie(q7)=0 FROM -0.0139259 TO -0.0139259
ie(q8)=0 FROM -0.0139259 TO -0.0139259
Date: Wed Jan 28 23:55:32 2015
Total elapsed time: 0.649 seconds.
tnom = 27
temp = 27
method = trap
totiter = 1714
traniter = 0
tranpoints = 0
accept = 0
rejected = 0
matrix size = 57
fillins = 215
solver = Normal
Matrix Compiler1: 17,9*Ko object code size
Matrix Compiler2: 8,85*Ko object code size 4.2/4.5/[1.4]Oops, I can see the error, but I'm not sure what causes it as I'm away from my computer (LTSpice). But why not use formula instead? You can label the circuit with meaningful labes to make this easier. And it would be easier for other to solve if you post the ASC file.
It looks like you are putting both values into OP in the .meas OP .... whatever, you should remove the other errors shown which may be the cause...
It looks like you are putting both values into OP in the .meas OP .... whatever, you should remove the other errors shown which may be the cause...
Last edited: