Hi Ste, thank you, very helpful.
Did you hoover the Opamp partC over part A or is there another trick?
Here comes the simulation of both electric models.
Suspecting a logical and/or syntax error in one of the OPA1656 .libs?
TL072 blue (=ok) and OPA1656 red (with simulation issue)
HiPass2_ste #2.zip (26.4 KB)
Another trial with TL072 (yellow, simulating as expected)
and simulations (with a strange error in my -dual.lib files 1656, 1612, 1642)
1642 and 1612 curves are overlaying each other:
I don’t know what you’re doing differently than me. The project I sent you simulates like this, where the curves for each opamp type are identical (overlaying each other).
Toward your rehabilitation, fbee:
I can reproduce your results with the OPA1656 when running the simulator development version ngspice-33+. When running ngspice-32, as is distributed with KiCad 5.1.8, then I get Ste’s results. ngspice-33 is o.k. as well.
I have to look into ngspice about what is going on.
It is about selecting the appropriate ngspice compatible replacement for the vswitch model which is used in OPA1656.
In ngspice-33 I have used a code model aswitch. In ngspice-33+ I have used a new code model pswitch, which more closely resembles the original PSPICE model, but obviously is failing with OPA1656. I will have to check if I should revert this selection or improve the pswitch model.
Holger,
thanks for looking into this.
I ll standby and wait what you ll be suggesting
Frank
I have done tests with op amps I have got, and then reverted the previous commit: vswitch is now again replaced by aswitch in the ngspice git development branch pre-master.
Thank you,
found something on https://sourceforge.net/p/ngspice/ngspice/ci/pre-master/tree/
Does this pre-master version need special procedures for installation?
Currently, I run NGspice 33 in C: Spice64 folder with Windows10 operation system.
ngspice in C:\Spice64\bin has nothing to do with the ngspice shared library used by KiCad.
ngspice for KiCad is found as libngspice-0.dll (if on MS Windows) in KiCad\bin folder.
If you want using the ngspice from pre-master branch, you will need to compile it.
I am just preparing a libngspice-0.dll for replacement in KiCad.
On http://ngspice.sourceforge.net/download.html#kicad you may find a libngspice-0.dll for upgrading the existing simulator in KiCad.
Just replaced the two items in the Spice folder .
(and called the old folders …_orig33, because …_orig was already occupied when upgrading from v32 to v33)
The simulation generates no picture but this report
simulation report premaster.txt (85.6 KB)
reported version is
Circuit: KiCad schematic
** ngspice-33+ : Circuit level simulation program
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2020, The ngspice team.
** Please get your ngspice manual from http://ngspice.sourceforge.net/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
** Creation Date: Sun Nov 22 17:38:06 UTC 2020
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000
Reference value : 0.00000e+00
No. of Data Rows : 1
When I run Ste’s setup, it is o.k. in KiCad/ngspice as well as with standard ngspice, both on MS Windows or macOS.
Works here, too, now!
Thank you for the support !!
Frank
OPA1656 and TL072 model are working fine, now.
By copy/paste a third circuit branch, a third opamp model can be tested in parallel: (OPA1612)
Edit EE properties value to “OPA1612” and let spice models for all A, B and C component to be found under “OPADUAL1612.lib”
** A dual opamp ngspice model*
** file name: opadual1612.lib*
.subckt OPADUAL1612 1out 1in- 1in+ vee 2in+ 2in- 2out vcc
.include OPA1611.lib
XU1A 1in+ 1in- vcc vee 1out OPA1611
XU1B 2in+ 2in- vcc vee 2out OPA1611
.ends
OPA1612 output simulates way too low (red)
Here is the project:
HiPass2_ste #2.zip (35.5 KB) 
I m running out of further ideas: What do I need to check in the syntax of the OPADUAL1612.lib file?
I can confirm your results. ngspice is struggling with this opamp model.
When .ac is simulated, firstly the operating point is determined. Same with transient simulation (.tran). If you watch the transient simulation with this opamp, there are some oscillations until it stabilizes and then the simulation is o.k… No problem for .tran, because one always has a start-up phase (best to be ignored, except if you want to have a dedicated look at power-on). With .ac then we have a problem, op is not yet stable, and you (automatically) start doing the ac simulation.
The model developers obviously never have considered testing their models with ngspice (they use other simulators). So we have to adapt our simulator, without knowing implementation details of the non-open source simulators.
Candidates are at least the vswitch model and the limit function. I will have a look, searching for a universal solution, but this may be not a quick approach.
There is a very short term solution to get this opamp up and running:
Add the line
.options rshunt=1e12 reltol=0.01
to your netlist.
EDIT: Correction see above!
Hello Holger
.options rshunt=1e12 reltol=0.01
put into a text fiel of EEschma
leaves all three opamp types without useful output
The simulation report looks like this
Error Log.txt (63.6 KB) :
Yeah, same for me. It’s going to be difficult to reverse-engineer the model to figure out what is goofing up the op-point calculation.
These TI models are quite sophisticated. May I ask what your end application is?
Hi Ste,
the different opamps will be used in an audio filter circuit (analog line level crossover)
After doing the EEschematic, the simulation might help in discovering design errors and in estimating performance.
Generic opamp spice models might work to a certain degree.
But once you start looking at noise figures, it would be worth having the manufacturers spice model at work
Best
Frank
I agree. If you’re going to do noise analysis, you would probably want the sophisticated model.
If this is the case, then I think until Holger is able to duplicate within ngspice the exact PSPICE behavior causing the discrepancy…you need to use either different opamps or use a different simulator. Your latest project has valid outputs for all three branches when I simulate it in LTspice using the Eeschema netlist export command.
