Hello,
I am new in this forum and doing my first steps with the ngspice simulator built into Kicad 5.1.5.
Unfortunately, despite having already invested many hours, read tutorials, run examples, I couldn’t get a meaningful simulation result with a very simple LMV358 circuit.
My circuit is the the well known Sallen-Key 2nd order low-pass filter. I enclose the project: sallen_key_LMV358.zip (5.8 KB)
I obtained the LMV358 model (see enclosed LMV358.MOD) from T.I. and know that it is correct (it works with the Tina TI simulator).
Then, according to the tutorial, in EEschema I matched the pin sequence of the SPICE model with that of the schematic symbol using the “Alternate pin sequence” field in the SPICE model property dialog. The following screenshot:
shows what I did (the opamp with its pin numbers can be seen in the upper right).
Simulation runs without errors, but the simulation results (e.g. AC sweep Bode plots) are completely wrong: see here: . The amplitude frequency response (red trace) looks rather like that of a high-pass.
And very oddly, the only way to obtain a frequency response that looks more or less like a low-pass, is to leave the VSS pin of the LMV358 floating!
A few more strange things that I noticed are:
After having entered the Alternate pin sequence in the SPICE model properties of the LMV358 (which in my case would be: 1 2 3 4 5), saved and closed the dialog, the strange thing is that I find the Alternate pin sequence field empty if I return to the same dialog again at a later time.
This does however not happen if I use commas as separators in the Alternate pin sequence: 1,2,3,4,5. But according to the tutorial, the correct separator is the blank space, not the comma. Isn’t it?
Entering an Alternate pin sequence seems to have no effect at all to the simulation results. Results are always the same (wrong ones). Even if I enter explicitly wrong pin sequences.
I would be so thankful if anyone can help me getting started. At this point I’m completely lost!
Spice is a difficult subject in the open source world.
TinaTi probably has a bunch of functionality which is not published. Then there are also the encrypted models that suppliers use to “protect their ip” and those things and more make it difficult for the Open Source people to support most of the spice models available in the big outer world.
To make sure it works you need to have models that are compatible with ngSpice.
A week or so ago I was looking for a model of an lm555 or ne555 or ltc555, any form of 555 that could give me a square wave in KiCad + ngSpice, and I gave up after a few hours. Apparently there is a yahoo group somewhere with lots of (compatible?) models, but I get too annoyed by yahoo’s banners, just as I refuse to start a dropbox account for viewing your project.
With a little bit more of “experience” gained you can upload files directly to this forum, as I did with your screenshot. Unfortunately it does not mean much without the schematic and numbers near the scale.
It looks like normal output of a High pass filter, and if the maximum frequency is around or below 1MHz the bode plot may well be correct.
Are you aware there is a Sallen-Key filter among the demo’s of KiCad?
Some time ago I experimented with it and have gotten it to work.
On my PC, it’s in: /usr/share/kicad/demos/simulation/sallen_key
I’ve always used commas instead of spaces for alternate node sequence. I didn’t even know spaces worked. Haha.
Anyway, your problem is simpler than you might think. You have a design issue with your schematic. You’re attempting to pass a 1V AC signal, centered at 0V, through an opamp powered from 0V and +5V. It’s going to saturate at the negative rail. You either need to make the negative supply rail (V-) of your opamp something like -5V, or you need to add a DC bias to your input voltage source so you center your sine wave in the middle of your opamp’s operating range. Here’s an example of doing that.
If you need to learn how to handle single-supply opamp biasing in practice, take a look at this PDF from TI: single-supply-op-amp-circuits.pdf (163.1 KB)
Dear Paulvdh,
thank you very much for your reply. And sorry for the inconvenience arising from posting my attachments on Dropbox. I was forced to do so, since this forum does not allow new members to start uploading files.
This limitation has now been lifted in my case, therefore I updated my post by enclosing all the attachments and removing the links to Dropbox.
Could you confirm that the LMV358.MOD model belongs to the category of crippled models that won’t work?
However, in my opinion this would be a short sighted decision from TI, since it does certainly not help increasing the sales of their LMV358.
As Ste already posted. Your circuit does not work properly because the input voltage goes out of the range of what the opamp can handle.
If you look at the output of the simulator it also gives you an error message for this:
So I added the 2.5V DC offset to V1 and ran the simulation again.
Now I get:
This clearly a low pass filter with a corner frequency just above 1kHz
paul@dualcore:~$ python3
>>> from math import *
>>> n=1e-9
>>> k=1e3
>>> 1/(2*pi*1*k*100*n)
1591.5494309189535
Above 300kHz the opamp starts misbehaving. LMV358 is probably a slow opamp, I have not looked at it’s datasheet, but it does look realistic.
There are also no error messages anymore in the output window of the Simulator. So your model of the LMV358 seems to work correctly.
If I simply remove the 2 capacitors, so the LMV358 acts as a buffer with 2k series resistance on its input, I get a rolloff frequency of 1MHz, which also does make sense.
This does not prove that the model is correct, but I am fairly sure that these initial results do make sense for this opamp.
After some more simulations with your first circuit (and a 2.5V offset) I got the result below, and it makes perfect sense. but it did take me some time to figure out the differences with my earlier screenshot.
Can you explain the diffenrences? Simulation was done with the same parameters.
thank you so much for taking the time answering me.
And yes, you are absolutely right (it was my mistake after countless unsuccessful attempts and desperation ): I was driving the opamp into saturation with the given signal source.
And yes, I am aware of the Sallen-Key example provided by the KiCad installation. As a matter of fact, that is from where I started. After verifying that the example provides sound results, my next step was to simply swap the opamp for an LMV358. And that’s where my troubles began!
After checking everything again I noticed that the power supply concept (with +/-5V bipolar supply) provided in the example was not suitable for the LMV358, which is basically a low voltage variant of the venerable LM358, since the LMV358 is rated for an absolute maximum supply voltage of 5.5V (between the two rails). So I modified the circuit to single supply and GND (and forgot to level shift the signal source accordingly…sorry).
I have now fixed the signal source by adding a 2.5V DC offset, but the simulation result is still the same . A transient simulation seems to indicate that the opamp is still saturating towards the negative (GND) rail. @paulvdh: I am really wondering how you could obtain the frequency response that you posted and which really makes sense?
Could you please upload your project variant so that I can give it a try and learn what I did wrong?
And regarding the syntax of entering the Alternate pin sequence for the opamp, as I said, the only way to have KiCad remember the values entered is to separate them by comma. Otherwise they get lost. @Ste seems to confirm that using commas is the right syntax. But then, why does the ngspice tutorial (“Tutorial: ngspice simulation in KiCad/Eeschema”) show exactly the opposite in the last figure of section 4) :
In order to circumvent the use of the “Alternate pin sequence” and its unknowns (?!), I also tried to create a modified schematic symbol for the LMV358, so that it matches the numbering of the SPICE model. But again, same wrong results!
There are definitively too many weird things at one time for a beginner like me. Probably the devil is hidden somewhere in a detail, but where??
(by the way, I am an engineer with 25+ years of experience. I am a newbie in ngspice and in this forum, but not really that much in circuit design but things here are really weird).
About the frequency plots.
They are probably all correct, as I already mentioned.
The first plot is taken however from the “wrong side” of C1.
The “weird” jump in the green line is also normal, and easily explainable.
Spice maps phase shifts between -180 and +180 degrees, which are the same if you believe the math people.
No, it’s not that. I can duplicate the problem he’s describing, but it seems oddly specific. It has to be specifically the string “1 2 3 4 5” for it to disappear. Adding commas, adding/removing a number from the list, or switching up the order of the numbers all work fine. I was thinking it might be because if you define “1 2 3 4 5” on a 5-pin symbol, it realizes nothing is being swapped and just auto-clears it. But it doesn’t do it with commas, and if I put “1 2 3 4 5 6 7 8” on an 8-pin symbol it also doesn’t auto-clear either. It’s very bizarre…but, in the end it doesn’t seem like it’s anything to worry about since the inconsistencies don’t end up affecting actual functionality.
@paulvdh: I have tried to simulate the project that you returned to me, but the result is still wrong here (I still obtain a high pass response).
However, your screenshot gave me some clue.
First of all, in order to understand what happens with the circuit, I did a transient simulation with an AC source. The result shows that the opamp is not working at all (see screenshot below). The expectation is that the waveforms on the non-inverting input (“Vin_p”, green trace) should be more or less the same than that on the inverting input and output (“lowpass”, red trace), which are connected together (the opamp operates as a unity gain buffer).
But more importantly, it is interesting to compare the message log on the bottom of my screenshot with yours.
Mine contains plenty of errors!
And yes, I created the .spiceinit file in my home directory C:\users\xxxx\ with the correct content as described in the “ngspice tutorial for KiCad”.
Another question: I am using Kicad 5.1.0, which is not the latest version. Could this explain the problems that I encounter? If yes, then I will probably have to wait for a while, because I am in the middle of a very large project and don’t want to touch the program until finished. For the moment, I cannot take the risk of compatibility problems that could surface after an update.
And regarding the discussion thread about the “Alternate node sequence”, my observations seem to indicate that separating the numbers with commas or blank spaces makes no difference. I wonder if @holger can confirm this?
And moreover, I found that it is probably safer to enter this information directly into Kicad’s property table of the Opamp, in the field “spice_node_sequence” rather than going through the “Edit SPICE model” dialog. I think that the “Edit SPICE model” dialog only copies the entered “Alternate node sequence” into Kicad’s “spice_node_sequence” component parameter table. Is my assumption correct?
I see your simulation tracks have lots of sharp 90 degree edges. This was a bug in the earlier V5 versions of KiCad, where no linear interpolation was done. In itself it’s harmless, just visual and it does not influence the simulator results. It is likely that also other bugs have been fixed though.
All KiCad V5 versions use the same file format, and the differences are mostly small bug fixes. Almost all the KiCad effort is done in the V6 branch at the moment. Which means it’s pretty safe to update even halfway a project. But I understand your hesitation. Newer versions fix a lot of bugs, but also introduce some other bugs, and if the current version is good enough for your project, then stick with it until the project is done.
Maybe you also have another computer, maybe a laptop on which you can install the latest stable V5.1.5? ( Almost V5.1.6 now).
I do have a recollection of spice not working very well with KiCad in the time I had those jagged edges. Part of the reason was an old ngSpice version. Update instructions for ngSpice are on: http://ngspice.sourceforge.net/ngspice-eeschema.html
Edit: I see you already found that link…
Also, I did not have the “.spiceinit” file in my home directory. This may be the reason why all those 555 models I tried recently did not work…
But apparently your opamp model is not from the pspice variant.
Simple models seem to work well for me in KiCad but, everytime (99.9%) I do something a hair beyond simple, KiCad’s simulation goes nuts and if I ever do resolve ‘it’, whatever ‘it’ is, it takes hours…
I try because I like to succeed but, I stopped trying to do non-simple simulations in KiCad. I switched to LTspice and never regretted it.
Below took about 3 minutes to draw and simulate in LTspice. The results produced in KiCad are not correct, though the model and subckt are good.
I’ve discovered hidden tricks to finding equivalent parts (ie LM358 = OP07) and a host of other goodies, such as 2N222 (doesn’t immediately show in LTspice but, clicking to find replacement lists it…)
I would Pay for LTspice but wouldn’t give a penny for pSpice/ngSpice…
LM358 and OP07 are indeed both opamps, but if you consider them “equivalent” you must have missed something.
For me it’s open source software or a breadboard. Not LTspice, so I’m not interested in whether some other program “works better”. I’m only interested n making spice simulations in KiCad better.
I didn’t miss anything - I tweak the stock file to reflect the LM358 parameters of interest to me. I just didn’t say. I expect folks who strive for equivalency of parts to spend some time ensuring they get what they want. I don’t take anything for granted and there are a number of OpAmp’s in LT to choose and tweak.
I can appreciate your wanting to stick with KiCad simulator. Sometimes I use OpenSource software but, always on a computer(hardware) not made by an OpenSource org.
I always chuckle when folks decry something but quickly use that ‘something’ they decried about. Are you using a Dell, Lenova, IBM, Apple, other or an OpenSource computer (the hardware)? We all move the goalposts to suit our own needs…
My daily workhorse is a Linux box, which I got for free. Quite a sad story.
It was orignally a vista box, but after my sister in law died of leukemia my brother had a HP left over and gave it to me.
It’s an E6550 wich is now 12 years old but still chugs along nicely with Linux Mint.
Sometimes I think of upgrading Maybe an Ryzen 3600 with a brand new 107cm monitor, maybe a bit more modest such as an 3200G, but not a complete computer, just the parts I need. Mobo probably Asrock.
No one’s as big as an LTspice fanboy as me, but I try my best here to offer up solutions which don’t simply affirm my own biases and can help the broader SPICE community. If I can’t think of a practical way to implement something in KiCad, I would then propose a fallback LTspice solution (see other threads I’ve been involved in). We need to keep in perspective that KiCad’s goal for including a SPICE simulator is a noteworthy one. As I see it, this is mainly to try and prevent having separate simulation schematics and production schematics. I constantly redraw stuff between two programs, for me: LTspice and EAGLE. There are things I change in the production schematic which accidentally don’t make it back to the simulation schematic and vice-versa, so things can get confusing sometimes. I don’t think this is always possible to accomplish, but it can be done in most cases for KiCad users. If you haven’t watched my talk from KiCon 2019 about LTspice and ngspice, I suggest at least checking it out because it highlights some of these points.
@BlackCoffee: I do agree with your broader point at the end, though. I also very much enjoy black coffee.
Anyway, back to the topic at hand. @Magoo: I think @paulvdh is correct. That is a rather old version of KiCad and I believe it was prior to when PSPICE compatibility was included in the accompanying ngspice build. You can update the ngspice DLL file without messing with the rest of the KiCad build. Instructions on how to do this can be found in the same tutorial article you linked earlier. Also, the .spiceinit filename doesn’t seem to mash well on Windows systems, so I recommend using the alternate filename of spice.rc instead.
He wrote the article, so I have no reason to believe spaces would not be valid. I have only used commas, so I know that’s valid too. I also agree with your assumption at the end, or at least it matches up with my testing.
Sorry about the edits, but I didn’t realize the website didn’t save my entire post after it crashed while trying to post the first time.
Here are some KiCAD/ngspice results, if you do it right. Despite from the fact that the OpAmp shown here has a worse rail-to-rail behavior, the results are similar.
Two actions are required that LTSPICE people are not used to: find an adequate model from the net (here via Mouser and its link to TI) and install it properly (alternate node sequence has to be defined).op07.zip (4.6 KB)
. The amplitude frequency response (red trace) looks rather like that of a high-pass.
): I was driving the opamp into saturation with the given signal source.
. A transient simulation seems to indicate that the opamp is still saturating towards the negative (GND) rail.
but things here are really weird).
