I must be doing something really stupid, but I keep overlooking the problem, so maybe someone can help me out.
I am trying to run the simulator on this temperature compensated current source schematic:
I have included the MPSA56 Spice model from onsemi.com and included it. I am not getting warnings about the model not being found, so that is ok.
The Voltage at point C should be 4V and at point A about 35.8V. The simulation agrees about the voltage at A, 35.83V, but it keeps telling me C is at only 1.72V.
I simulated the same schematic with LTspice. LTspice told me the voltage at C was 4V, as expected.
Why do I see such a difference between the Spice lib used by KiCAD and LTspice?
I would appreciate some help, because I want the simulations via KiCAD to be reliable. I must be doing something wrong… no doubt…
Thanks
m
My version of KiCAd is the nightly build:
Application: kicad
Version: no-vcs-found-33e05ae~59~ubuntu16.04.1, release build
Libraries: wxWidgets 3.0.2
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-89-generic x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.58.0
Curl: 7.47.0
KiCad - Compiler: GCC 5.4.0 with C++ ABI 1009
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
This is getting even weirder…
The collector current of Q1, Icq1, is -3.5mA but the current through R6 is +1.75mA!
Interesting, there are no other connections between them, so where is my current going?
LTSpiceXVII, using similar 2SA1579 gives a sensible 4.19V for node C
I have never used the KiCad simulator as model compatibility and accuracy is a nightmare. LTSpice is simply better tested than any true opensource solution
I am sorry. Where was I? I must have been dreaming. I did not use Pspice, but LTspice. I corrected the original post.
You are right, LTspice does give the correct answer.
That is why I am raising the issue here. If KiCAD users can confirm the spice library used by KiCAD gives the wrong output, I could issue a bug report.
But first I want to verify that I did not make a stupid mistake somewhere.
The point with LTspice is that it does not run on Linux and that it is not integrated with KiCAD. It could save me a lot of work if the KiCAD->Spice route would work reliably.
By the way, I tried ngspice as well on the same problem with similar results as the KiCAD route. As far as I know, KiCAD is using the ngspice library, so that would be as expected.
I don’t think the problem is in ngspice. Looking at the transistor symbols on your schematic, the pin numbering is 1-E 2-B 3-C. All kinds of Spice expect different pin order (C-1 B-2 E-3). Open the properties of the transistor (dbl-click or E), choose ‘Edit Spice Model’, then check ‘Use alternate node sequence’ and type ‘3 2 1’ next to it. Hope this will fix your simulation.
Actually, now that I think about it: I have seen some SPICE models implement a different pin order. When the model is implemented as a subckt call, it can implement any order.
The cases I’ve seen were when the subckt model included within it a call to the actual ‘M’ element within SPICE.
So depending on the exact problem, it may be with KiCad writing out the ‘M’ element correctly or it may be that your symbol does not match your subckt model. In the first case, KiCad and/or libraries may indeed need to be fixed. In the second case, I don’t think that it can be fixed within KiCad.
If KiCad needs to be fixed, then the libraries need to include standard pin names for all parts that may themselves be SPICE elements. More likely, each symbol placed in eeschema will need SPICE information on it, modifiable by the user (similar to LTSpice) that can be interpreted by the netlister.
I tried flipping the transistor C-E using Simetrix and got about 1mA, so this pin mapping could well be the problem.
As KiCad symbols offer every permutation of BCE and DGS, there should be some translation to the Berkeley standard order
This is exactly the problem. Thank you so much I changed the pin orientation in a new version and got my 4mA instantly.
Obviously, now the pin numbering for PCBNEW is wrong, so back to the first version, as posted above.
And it can be fixed!
Actually, in the ‘Edit Spice Model’ option, there is a field called ‘Alternate node sequence’ that fixes it. I just had not interpreted ‘Alternate node sequence’ as ‘Alternate pin sequence’ yet.
I filled this field, after some experimentation, with 3,2,1 and now the simulation works like expected with my original schematic.
Like so:
I have never seen any documentation in the simulation feature apart from the youtube material at the introduction. Have you?
At least this should be documented well, very well. Most users (including myself) might not even know that Spice assumes CBE always. That is too subtle…
If one is not wary of the simulation results, one may not even notice that something is wrong… (this proves once more that designing with spice instead of brains may lead to unpredictable outcomes )
I am not completely convinced the field name ‘Alternate node sequence’ is self-explanatory…
Thanks for all your help. I guess we have learned that this problem was foreseen by the designers of the KiCAD interface and they fixed it.
Nighly is not an official release. So documenting it is not a priority. (As soon as the feature freeze for v5 is announced the documentation guys can start with documenting stuff that will be in v5.)
And remember the documentation is also written by volunteers.
Be the change you want to see.
At the bottom of the KiCad website documentation page, you can find information on the 3D plugin, not supported in 4.0.x https://kicad.org/help/documentation/
What would be nice when it is implemented in stable is to have some simple tutorials that would mimic or follow an electronics class. Perhaps one of the free online offerings to start. For me co-learning things and putting them together was always fun. I think this would be a channel for getting new blood involved.
I haven’t tried a nightly yet. Perhaps this could be incentive.
It is a very nice feature that saves having to draw schematics twice, once in LTspice and then in EEschema.
But you need to be careful. Mistakes creep in easily…
)