Re: Weird results DC operating point for Tube amplifier
There is 26.5 V across the 12.6 V heater, but
the current is not too excessive, so, yes, the model is suspect.
But there are other issues, some related to the heater perhaps.
But it's a weird circuit anyway, including a valve/tube/ a FET
and an IC. Is it some sort of demonstration of those mixed-up
technologies?
On 2025-02-17 17:16, Andy I via
groups.io wrote:
Have you yet run simpler simulations, with just the 12AU7, to
verify that its model is good?
?
From where I stand, having done only a cursory check, it
might not be a good model.? It seems to be generating energy in
its heater that comes out of the heater pin.? How is it doing
that?
?
Andy
?
-- OOO - Own Opinions Only
John M Woodgate, Rayleigh, Essex UK
If something is true:
* as far as we know - it's science
* for certain, it's mathematics
* unquestionably, it's religion.
|
Re: LTspice 24.1 Simulation Errors
I agree, but I'd like to state the rules more
clearly:
- Code that was correct in earlier versions
must be accepted
- Code that was not correct, but tolerated,
in earlier versions should not be accepted but should create a
clear statement of the error, so that it can be corrected.
On 2025-02-17 17:37, Dave Daniel via
groups.io wrote:
Hmmm... despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see and agree
that erroneous simulation of legacy designs is not good and that,
despite the (possibly large) effort that is or would be needed to
address those errors in legacy designs that show up in a newer
simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs
correctly should be supported. But that probably has its own
complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born
via groups.io wrote:
[snip]
I think ADI should ensure that correct LTspice
syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in the
past could be counted as "correct syntax".? Unfortunately
as it may be, that is how SPICE developed and grew over
half a century.? This seems to be an important aspect
about which some of the programmers and management at
Analog Devices do not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and
ran nevertheless should not be accepted. That's where 24.1
shines.
It might be too restrictive in some areas, but we have been
making adjustments were needed.
?
Best Regards,
Mathias
-- OOO - Own Opinions Only
John M Woodgate, Rayleigh, Essex UK
If something is true:
* as far as we know - it's science
* for certain, it's mathematics
* unquestionably, it's religion.
|
Re: LTspice 24.1 Simulation Errors
Hmmm... despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see and agree
that erroneous simulation of legacy designs is not good and that,
despite the (possibly large) effort that is or would be needed to
address those errors in legacy designs that show up in a newer
simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs
correctly should be supported. But that probably has its own
complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born via
groups.io wrote:
[snip]
I think ADI should ensure that correct LTspice
syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in the past
could be counted as "correct syntax".? Unfortunately as it
may be, that is how SPICE developed and grew over half a
century.? This seems to be an important aspect about which
some of the programmers and management at Analog Devices do
not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and ran
nevertheless should not be accepted. That's where 24.1 shines.
It might be too restrictive in some areas, but we have been
making adjustments were needed.
?
Best Regards,
Mathias
|
Re: LTspice 24.1 Simulation Errors
On Mon, Feb 17, 2025 at 05:28 PM, Andy I wrote:
On Mon, Feb 17, 2025 at 03:22 AM, @HermanVos wrote:
As an example: a negative hysteresis in a Schmitt trigger which is not possible.
I have to disagree (somewhat) with what you're saying.
?
Negative hysteresis might be "not possible" in real hardware where hysteresis is designed-in.? But it was always allowable in LTspice elements where the hysteresis parameter Vh or Ih was available.? It might have been inadequately documented.? In the documentation for the controlled switches (S- and W-elements), the Help describes how a negative value for Vh or Ih makes the device transition smoothly between states:
If Vh is positive, the switch shows hysteresis .... If Vh is negative, the switch will smoothly transition between the on and off impedances.
I believe the "Schmitt" gates are made the same way, even in spite of its name which suggests positive hysteresis.? Nothing prevents you from using a negative number, and getting the same smooth transition as the controlled switches.? As they say, that's a feature, not a bug.
?
No it wasn't. Negative hysteresis went unchecked in LTspiceXVII. This was a severe bug because it occasionally lead to oscillations during Newton iteration. When it did work, it had the effect of zero hysteresis. A Schmitt trigger is a logic device, negative hysteresis make no sense there. Thus, we changed it so that 17.1 automatically corrected a negative value into a positive. However, that drastically changed the behavior of some circuits. In the end, we decided to not permit this any longer to prevent this error from sneaking in ever again.
?
These are good questions.? I can't answer them without examining the models more closely.? But if it's true that there was no parameter named "VCC", then all versions of LTspice should have / would have complained bitterly about that and refused to run.? LTspice would not ever have substituted a different parameter, whether or not it had a similar name.
?
This is simply not true. Prior versions run any circuit that uses undefined parameters inside sub-circuits. You'll get a warning in the log afterwards.
I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and accepted.? The problem is that anything that ran in the past could be counted as "correct syntax".? Unfortunately as it may be, that is how SPICE developed and grew over half a century.? This seems to be an important aspect about which some of the programmers and management at Analog Devices do not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and ran nevertheless should not be accepted. That's where 24.1 shines.
It might be too restrictive in some areas, but we have been making adjustments were needed.
?
Best Regards,
Mathias
|
Re: Weird results DC operating point for Tube amplifier
Have you yet run simpler simulations, with just the 12AU7, to verify that its model is good?
?
From where I stand, having done only a cursory check, it might not be a good model.? It seems to be generating energy in its heater that comes out of the heater pin.? How is it doing that?
?
Andy
?
|
Weird results DC operating point for Tube amplifier
Hello,
I uploaded the project "Bravo_Ocean_ampli" in Files->Temp. As you can check the .tran analysis returns a weird DC operating point (aka ITS/Initial Transient Solution). Namely the current through R4 connected to LM317 Out pin is negative -165.5mA. Of course physically it can't be the case (note that it isn't a problem related to how R4 pins are arranged in the schematic).
?
What could actually be the problem with this circuit simulation ? Thanks.
|
Re: LTspice 24.1 Simulation Errors
On Mon, Feb 17, 2025 at 03:22 AM, @HermanVos wrote:
As an example: a negative hysteresis in a Schmitt trigger which is not possible.
I have to disagree (somewhat) with what you're saying.
?
Negative hysteresis might be "not possible" in real hardware where hysteresis is designed-in.? But it was always allowable in LTspice elements where the hysteresis parameter Vh or Ih was available.? It might have been inadequately documented.? In the documentation for the controlled switches (S- and W-elements), the Help describes how a negative value for Vh or Ih makes the device transition smoothly between states:
If Vh is positive, the switch shows hysteresis .... If Vh is negative, the switch will smoothly transition between the on and off impedances.
I believe the "Schmitt" gates are made the same way, even in spite of its name which suggests positive hysteresis.? Nothing prevents you from using a negative number, and getting the same smooth transition as the controlled switches.? As they say, that's a feature, not a bug.
LTspice did set a warming, but did you realize the hysteris was set to zero in last versions so it was not acting as a Schmitt trigger?
If so, that is (yet another) unfortunate change recently added by ADI.? If I remember correctly, all older (pre-24.1) versions of LTspice had a rather small positive default value for Vh, so you got a tiny bit of hysteresis even when you forgot to specify your hysteresis.? Using a Schmitt gate that way (without hysteresis specified) was asking for trouble - in the same way that adding a gate with zero delay is.? LTspice "saved your skin", but only barely, by giving it a tiny non-zero hysteresis.? It was not enough to be really useful, but just enough to say that it was there.
?
The error which is raised by LTspice 24.1 on library 74LVC1G is simply a fault in the output driver. See the first lines:
...
The highlighted VCC should actually have been VCC3 and after this correction, LTspice 24.1 will not complain (at least not for the 2-input nand gate).
?
Do you know what previous LTspice versions have filled in? Did it assume something like: "ah there's only one parameter which comes close to VCC which is VCC3 so let's use that one?" or did it fill in just some positive value (3V3 or 5V? or zero? Were ALL simulations with this library just wrong??
These are good questions.? I can't answer them without examining the models more closely.? But if it's true that there was no parameter named "VCC", then all versions of LTspice should have / would have complained bitterly about that and refused to run.? LTspice would not ever have substituted a different parameter, whether or not it had a similar name.
?
If version 24.1 runs differently with that model, then I think it is a fault of version 24.1, not of the model.? The model might be in error too by using the wrong parameter there, but I can say with high confidence that it did use a defined parameter and LTspice version 24.1 should accept it.? We know already that Analog Devices messed up some of that in LTspice v24.1.1.? Whether or not they have fixed their code yet remains to be seen.? I think it was a big mistake allowing them the freedom to destroy functionality in this way.
?
I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and accepted.? The problem is that anything that ran in the past could be counted as "correct syntax".? Unfortunately as it may be, that is how SPICE developed and grew over half a century.? This seems to be an important aspect about which some of the programmers and management at Analog Devices do not yet understand.
?
And in all fairness, I also think there's work to be done by all those creators, maintainers, and users of incorrect LTspice libraries and designs. It is not correct to ask ADI to build in code to accept all those syntax faults and errors in designs and libraries.
I somewhat disagree.
?
Actual faults in the models, yes, they should be fixed.? Syntax that was correct for 20-50 years, no, they do not need to be "fixed" to meet newer non-standard "standards" that throw the old ones out.
?
Andy
?
|
Re: LTspice 24.1 Simulation Errors
I'm still on 24.1.2 and I agree: yes a disruptive new version is painful in the sense of having to rework things from the past.?
?
However (and that's something that also should be realized in this really great community), I see quite a number issues popup where pervious LTspice versions have made choices for you, which were not what the designers wanted LTspice to do, and where original circuits actually now show up to never ever have worked as intended.
?
As an example: a negative hysteresis in a Schmitt trigger which is not possible. LTspice did set a warming, but did you realize the hysteris was set to zero in last versions so it was not acting as a Schmitt trigger?
?
The error which is raised by LTspice 24.1 on library 74LVC1G is simply a fault in the output driver. See the first lines:
?
.subckt 74lvc_out IN OUT VCC VGND vcc3={vcc2} speed3={speed2}
.model Desd D(Vfwd=0.65 Ron=10)
.model strSW SW(Ron={Ron} Roff=1G Vt={0.48*VCC3} Vh=-100m Ilimit={Ilimit} level=2)
.model wkSW SW(Ron={Ron*10} Roff=1G Vt=500m Vh=-210m Ilimit={Ilimit/10} level=2
.param Ilimit 215m*(VCC-1.1)/(5-1.1)
.param Ron 7.5*(5/VCC)**0.5
.param Cval 1p*Speed3
?
The highlighted VCC should actually have been VCC3 and after this correction, LTspice 24.1 will not complain (at least not for the 2-input nand gate).
?
Do you know what previous LTspice versions have filled in? Did it assume something like: "ah there's only one parameter which comes close to VCC which is VCC3 so let's use that one?" or did it fill in just some positive value (3V3 or 5V? or zero? Were ALL simulations with this library just wrong??
?
I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly. Problem is of course that there is no "formal syntax" just like with most programming languages. That's in the heads of many people and hidden in some old code and text snippets.
?
And in all fairness, I also think there's work to be done by all those creators, maintainers, and users of incorrect LTspice libraries and designs. It is not correct to ask ADI to build in code to accept all those syntax faults and errors in designs and libraries. Even though this is inconvenient and frustrating for users. In the end, the result will be a better quality and predictability of designs and a simulator which is faster and better maintainable by ADI. By not starting to use 24.1, we will be stuck with being happy with old and faulty designs. I can't imagine this is want we all want, do we?
?
I'll be happy to upload later this week an updated version of the 74LVC1G library with the abovementioned faults repaired.?
|
Re: Understanding user file locations and structure.
On Mon, Feb 17, 2025 at 01:13 AM, <info@...> wrote:
I have always kept my symbols in subfolders? like TSS opamps, TSS comparators, TSS regulators, etc.? These were located in the factory SYM subfolder.? If I move them? to? the User area (...\documents\LTspice) I don't know how to make them come up in the master list when adding a component.? They show up as (sym) and then I have to click on sym to see my subdirectories of parts.? Is there a way to make my subdirectories show up with the factory subdirectories like it used to when I put them where I used to??
I think that is not how it works.? Oh, you could violate the rules and put your models where you should not be putting them, but I urge you not to do that.
?
Assuming that you have added your symbol locations to LTspice's User-defined Sym. Search Path, what you need to do is select between the "factory" symbol folder (LTspice's own symbol library) and your folders, and you make that selection in the Components menu.? With the Add Component menu open on your screen, look for the "Top Directory" choice which is at the very top of that window.? Click there to open a drop-down menu.? The choices in the drop-down menu should be LTspice's own symbol library, the current directory where the schematic you are editing is saved, and any Symbol Search Paths that you have defined.? That is how you select between LTspice's library and your library of symbols.
?
Let us know if what I described does not work.
?
Andy
?
|
Understanding user file locations and structure.
I have decided to move my customized library symbols, subcircuits, and models to the recommended location for LTspice 24.
I will place my stuff in ...\documents\LTspice.
I have created user.bjt, user.dio, user.mos,? etc? with my customized component models and put them in the above directory. LTspice has no trouble adding my components to the factory list when encountering the "pick new whatever" dialog.
?
I have always kept my symbols in subfolders? like TSS opamps, TSS comparators, TSS regulators, etc.? These were located in the factory SYM subfolder.? If I move them? to? the User area (...\documents\LTspice) I don't know how to make them come up in the master list when adding a component.? They show up as (sym) and then I have to click on sym to see my subdirectories of parts.? Is there a way to make my subdirectories show up with the factory subdirectories like it used to when I put them where I used to??
Once I get my custom symbols in the right location, I will figure out where to put the custom subcircuits and models.
I am sure this is a good plan for the long term -- no fear of my files being overwritten by updates -- but moving things and still getting it to work the same way is difficult.
?
Thanks,
?
|
Re: Can Someone Please Determine Why this Model of a 6mA Op-amp Draws 85mA
I see now that Nisshinbo requires me to login to their webpage before they let me download their SPICE model.? I do not intend to do that.
?
Andy
?
|
Re: Can Someone Please Determine Why this Model of a 6mA Op-amp Draws 85mA
Is that part (NJM4580) second-sourced?? I did a very simple web search which brought me to Nisshinbo Micro Devices Inc., which appears to not be the same company, unless it replaced the New Japan Radio Company (did it?).? I tried getting Nisshinbo's SPICE model but that just directed me around in circles and my patience was low so I abandoned that.
?
I would at least try to get someone else's SPICE model, if anyone else made it and has a model.? Alternatively, either accept the fact that this particular facet of their SPICE model is bad, or change parameter RP's value if you really need it to be right.
?
Andy
?
?
|
Re: Can Someone Please Determine Why this Model of a 6mA Op-amp Draws 85mA
On Mon, Feb 17, 2025 at 12:05 AM, eewiz wrote:
I have this model of NJM4580 op-amp.
It should draw about 6-9mA and I see a .param for IEE=5.07E-03 which looks likely to be quiescent current but I just don't know how to probe around inside a text .subckt model.
Indeed, the power pins sink/source around 85 mA in the simulation, with the output pin not doing anything.
?
The culprit appears to be this:? The model has a 375 ohm resistor connected between the + and - power pins:
? RP ? ?3 ?4 {RP}
.PARAM
+ RP = 3.75E+02
?
It is possible the value was a typo, and they never discovered it, since almost nobody bothers to check there.? With your +/- 15 V supplies, that is an extra 80 mA on top of the 5.07 mA from parameter IEE plus whatever else is in there.
?
In your simulation, if you go to Add Traces, then select I(u2:Rp), it plots the current through resistor Rp.? Rp is connected directly between the model's V+ and V- power pins (subcircuit nodes 3 and 4).
?
Andy
?
|
Can Someone Please Determine Why this Model of a 6mA Op-amp Draws 85mA
Hello All:
?
I have this model of NJM4580 op-amp.
It should draw about 6-9mA and I see a .param for IEE=5.07E-03 which looks likely to be quiescent current but I just don't know how to probe around inside a text .subckt model.
?
I uploaded a DiffAmp circuit to test with. The NJM4580 model is in the NE5532.lib file, second item from the bottom.
The NE5532.lib file it built to house multiple NE5532-similar op-amps that may be selected by triple-clicking the symbol's ModelFile attribute.
?
The NJM4580 datasheet is available .
?
Thanks in advance to any and all that may attempt to discover the answer.
?
All for now
|
Re: LTspice 24.1 Simulation Errors
I've got one too. I need to pull it out of storage. It uses composite for video and I have an old TV for it.
|
Re: LTspice 24.1 Simulation Errors
I am nostalgic of running Spice2G on a IBM XT, 16-bit (8-bit bus) back in 1987. On Sun, Feb 16, 2025 at 10:49?AM Richard Andrews via groups.io <richardandrews.ma@...> wrote:
No, I am just nostalgic to 32-bit systems and I have yet to surpass any limits of a 32-bit system, other then time.
|
Re: LTspice 24.1 Simulation Errors
No, I am just nostalgic to 32-bit systems and I have yet to surpass any limits of a 32-bit system, other then time.
|
This topic from almost two weeks ago was left somewhat hanging.? I want to add a little more, which might help close it out.
?
In Richard's schematic "heng-24v.asc",? there are two input voltage sources.? V2 is the SINE wave source.? V1 is a PULSE source but it was not connected.
?
The mere presence of the square-ish wave from V1 apparently causes the .FOUR calculation to estimate Total Harmonic Distortion = 0, even though the Partial Harmonic Distortion = 0.003792%.? (My simulation with a different version had 0.002029% for Partial.)? Removing V1 results in an unchanged Partial distortion but Total = 0.002032%, which is greater than my simulation's Partial, as one expects it should be.
?
Why it happens is less obvious, but I suspect there is a connection to the timesteps.? If you examine closely and display the Data Points, you can see that they are uniform when V1 is absent, but very non-uniform with V1.? Having V1 adds some 70 additional time points per edge of V1, and some of the timesteps are quite narrow, smaller than 1/10000 as much as they are without V1.? Now remember that each datapoint is slightly off, because SPICE iterates until error tolerances are met, then moves on to the next timepoint and starts iterating again, and again.? I guess this combination may result in errors calculating the total signal level versus the 1st Harmonic level.? The errors might be in the 50 PPM range, which is good compared to the default SPICE *TOL tolerance settings (e.g., 1000 PPM).
?
LTspice had some 700 times as many "rejected" timepoints with V1 than without it.? A rejected point is one where it could not converge in a reasonable number of iterations, so it backed up, reduced the timestep, and tried again.? Without V1, that almost never happened.? It was "smooth sailing" most of the way.
?
Although I can't conclusively say that non-uniform timesteps affect Fourier calculations making them less-than-stellar, I suspect there is a relationship.? In fact it has a profound effect (2+ orders of magnitude) on the ,FOUR components of the pure sinewave from V2.
?
Andy
?
|
Re: LTspice 24.1 Simulation Errors
On Sat, Feb 15, 2025 at 07:43 PM, Richard Andrews wrote:
Version 17 as access to more memory. With more memory, I can simulate longer run times.
Then is there a reason not to use version XVII (17) for all your simulations, whether short or long?
?
Regarding changes in version 24.1.*, be aware that some (maybe not all) of them come with new .OPTIONS settings to disable the new behavior and revert to the old behavior, or something close to it.
?
Andy
?
|
Re: LTspice 24.1 Simulation Errors
Thanks Andy,
?
Version 17 as access to more memory. With more memory, I can simulate longer run times.
|
John Woodgate
Carlo
eewiz