I get different results when simulating my circuit in LTspice and Kicad. My circuit looks like this. the second op amp below is there to check its contribution to the result, but it’s totally flat up to 100G…
The Output looks like this:
also in NGspice it looks like the second derivation of the phase has a pole on the way up to 1k which it also doesn’t look like when viewing it in LTspice. I attache my setups, has anyone a clue why i get these different result? LT.asc (1.5 KB) NG.sch (6.7 KB)
I just noticed that i have switched up V+ and V- on the OpAmp…but that’s just cosmetic in this case, it doesn’t change anything.
For those without default libs i’ll also add the whole project folder as zip. SK.zip (4.3 KB)
I don’t get what you’re trying to convey. How would adding more variables to this case make it better. If anything i could change the opAmp to a BV-source but that would not noticeably change anything.
Yes both do not contribute to the result. Or at least they only contribute to a non visible amount. I checked the phase and gain of the eeschema one up to 100G to be perfectly flat as well as the LT spice one which behaves unnoticeably different from a bv-source.
The issue is that there is no spice model linked with the OpAmp! KiCad has several libraries: 3D libraries, footprint libraries, symbol libraries. You have used a symbol library so far. And you need a ngspice simulation model for the OpAmp. This is not delivered with ngspice, nor with KiCad. Please have a look at http://ngspice.sourceforge.net/ngspice-eeschema.html#OpAmp how to include a spice model for an OpAmp.
If you want to have a simple OpAmp model created of your own (e.g. a B source) and still using the OpAmp symbol, you might create a ngspice subcircuit like this (untested):
.subckt OpAmpB inp inm out
Bop out 0 V=1000*V(inp,inm)
.endc
put it into a file, and load it to your OpAmp symbol as decribed in the tutorial.
Or, even better (for his use-case), it would be nice to do what we discussed in his other thread regarding the scripting questions and put the subcircuit in a Text box. That way it can travel within the .SCH file and it doesn’t need any accompanying .LIB files. However, it seems like the multi-line directive bug is still present. If I paste into the schematic this subcircuit:
The two component lines without dots are removed in the resulting netlist and I cannot find a work around for this. Do you know why it still does it? I thought this was fixed??
No the issue here is as you said yourselfhere, that there is a bug in the “Spice_Primitive” textbox of the OpAmp which defines it as a Voltage source and prevents it from throwing an error or warning.
But regarding me, we have reached consent here so there’s no point in further arguing.
Thank you for pointing me in the right direction, the tutorial is nice although i already knew it. I also can recommend this PowerPoint if anyone is interested.
My solution to this is including a subckt that reads:
.SUBCKT idealOP in+ in- out v+ v-
Ex out 0 in+ 0 1
.ends
I could not get it to work as a text directly in the schematic either, but i did something else wrong.
This thread by the way was never meant to provide a solution to my problem. It’s sole purpose was to erode if this is something one should raise a issue for either in KiCAD or in NGspice.
Nevertheless i am grateful for your time and effort @holger@Ste, thank you.
No problem, man. Just a couple extra things I thought I should mention (if you don’t mind).
First, is that you’re using the “Level 2” of the Universal Opamp in that LTspice schematic, which sources/sinks current from/to the rails and can also saturate. There is a great example schematic provided with LTspice that describes the levels in more detail (if you’re not already familiar): Documents\LTspiceXVII\examples\Educational\UniversalOpamp2.asc
Anyway, I wanted to mention that any of the simple opamp models discussed here (either the B, G, or E source ones) are more akin to LTspice’s Level 1 model. So if you need to match up with LTspice’s Level 2, you’ll need a more sophisticated model, like the Universal one on the thread I linked to earlier. Also, there’s a reason why I used a G source in my model instead of an E source like you ended up with. This is directly pasted from LTspice’s Help under “E. Voltage Dependent Voltage Source”.
Note: It is better to use a G source shunted with a resistance to approximate an E source than to use an E source. A voltage controlled current source shunted with a resistance will compute faster and cause fewer convergence problems than a voltage controlled voltage source. Also, the resultant nonzero output impedance is more representative of a practical circuit.
Lastly, I was going to post this before but got side-tracked by the multi-line subckt bug. I also stumble upon weirdness when checking results between LTspice and ngspice, but the most effective way to compare these results is to use the same netlist between the two programs. That way you are only comparing the SPICE engine differences and not any user errors or other red-herrings like that. I do this by pushing my netlist from KiCad out to LTspice. This is very simple to do, as shown on this timestamped video: https://www.youtube.com/watch?v=90Z6ffxzDz8&t=21m40s
i am aware of that, the lvl2 is in there because it got picked by default or because of an earlier project where i might have copied it out without caring too much about it.
You’re right normally that would be a thing to watch out for.But in the example i gave and in this specific use case i don’t care. In the example i picked the rails such that they are far away from the max and min input voltage. That’s because the main focus here is to test the computed values and to verify them. All the real world problems are out of focus since they are unknown. It’s the design engineer who uses the tool to create the filter who has to take care of those thing.
I actually did wonder why you used a G shunted over 1meg now i know, thanks.
I did not know that you can do that, i’ll sure use that in the future when i compare the two, thanks!
or because of an earlier project where i might have copied it out without caring too much about it.
now i know, thanks.