If it's a Tina model, it might be compatible
with LTspice, but might need some tweaks.
On 2025-03-12 19:27, DerekK wrote:
Now to put it into something that LTSpice can use. Any
suggestions where to start? This looks to be an OrCAD / TINA
thing. I will peruse myself.
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
Now to put it into something that LTSpice can use. Any suggestions where to start? This looks to be an OrCAD / TINA thing. I will peruse myself.
|
|
|
I am trying to work out some old schematic and circuit issues and am looking for a model for the old LM121 opamp. Anyone have such a thing? I found the LM118, as I can use the LTSpice LT118A model. Now for the front end.
|
Re: More syntax issues with 24.1.x
On 12/03/2025 13:17, Mathias Born via
groups.io wrote:
Hi Tony,
?
The next update 24.1.6 will support this again.
?
The official syntax for loading table data from a file will
be:
?
table(x,
.include "<filename>")
?
but yours will also work as is. You will also need not change
the file contents, however the "+" line continuation at the
start of each line will be optional and can be omitted.
?
This is a good feature, and now it's official.
?
Best Regards,
Mathias
?
On Tue, Mar 4, 2025 at 12:06 PM, Tony Casey wrote:
I have many testjigs that import digitised datasheet
characteristic curves. An example of this would be:
.subckt
IB_400u 1 2 3 4
R1 3 4 1G
B1 1 2 I=table(V(3,4)
.inc BC848B_Ic_Vce_400u.inc
+)
Great! I look forward to 24.1.6.
--
Regards,
Tony
|
Re: More syntax issues with 24.1.x
Hi Tony,
?
The next update 24.1.6 will support this again.
?
The official syntax for loading table data from a file will be:
?
table(x, .include "<filename>")
?
but yours will also work as is. You will also need not change the file contents, however the "+" line continuation at the start of each line will be optional and can be omitted.
?
This is a good feature, and now it's official.
?
Best Regards,
Mathias
?
On Tue, Mar 4, 2025 at 12:06 PM, Tony Casey wrote:
I have many testjigs that import digitised datasheet characteristic curves. An example of this would be:
.subckt IB_400u 1 2 3 4
R1 3 4 1G
B1 1 2 I=table(V(3,4)
.inc BC848B_Ic_Vce_400u.inc
+)
|
Re: Brady Ridgway's Fuzz_Face (guitar "fuzz" circuit) simulations
Apologies for the mis-steps. Thank you very much for taking the time to explain everything so clearly. I will restore the standard.bjt file and follow your suggestions with regard to the circuit and simulation.?
|
Re: Issue with Nexperia BUK7S1R0-40H PET LTspice model
So I was right about two different data
sources, but both are models, not one model and one measurement
results.? The moral of that is, says the Duchess (not of
Sussex), is 'Caveat Simulator'.
On 2025-03-11 22:47, Andy I via
groups.io wrote:
On Tue, Mar 11, 2025 at 09:52 AM, John Woodgate wrote:
It's quite possible that
the data sheet Figure 13 isn't based on the Spice model,
but on measurements of actual devices? of superior, rather
than average, performance.
That is possible, but I think not likely.? By my read, the
whole purpose of that Application Note is to show you the
results of SPICE simulations.? Therefore, I think none of its
plots were from measurements.? Also, it states that "the
characteristics are always typical values and
do not represent the limits of process variation."? I think it
suggests that everything in that AppNote is average, not
superior performance.
?
I agree with MaticH that the comparison is rather poor.? It
should be much better, if not exact.
?
But read on.? I think there are reasons to explain it.
?
AppNote AN90034 was published in April 2022.? The LTspice
model used today is dated June or July 2023.? We know it is a
different model file because it lists a different number of
MOSFETs than the ones shown in Figure 1 of the AppNote.
?
AN90034 refers specifically to the LTspice model here:
? ?
But the one in MaticH's (and my) simulations is here:
? ?
?
I think there was a significant change when they went from
V1.1 to V3, even though it was only one year.
?
The older ZIP file is no longer there.??I tried retrieving it
from the Wayback Machine but they did not successfully save it.
?
So anyway, that is what I think happened.? Nexperia's model
changed significantly between 2022 and 2023 and this explains
why today's simulations differ so much from the plots in
AN90034.
?
To make things even more interesting, Nexperia has yet
another SPICE model for the same part, here:
That one is a non-encrypted generic SPICE model (Level=3
NMOS) and it should work in LTspice as well as most other SPICE
programs.? It lacks the two thermal pins.? I did not try it, but
I do not expect close agreement between that model, and the
AppNote.
?
?
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
Re: Issue with Nexperia BUK7S1R0-40H PET LTspice model
I wrote:
That one, the non-encrypted generic SPICE model, is even older, from 2019 and apparently not updated since.? Who knows what that means.
?
Andy
?
|
Re: Issue with Nexperia BUK7S1R0-40H PET LTspice model
On Tue, Mar 11, 2025 at 09:52 AM, John Woodgate wrote:
It's quite possible that the data sheet Figure 13 isn't based on the Spice model, but on measurements of actual devices? of superior, rather than average, performance.
That is possible, but I think not likely.? By my read, the whole purpose of that Application Note is to show you the results of SPICE simulations.? Therefore, I think none of its plots were from measurements.? Also, it states that "the characteristics are always typical values and do not represent the limits of process variation."? I think it suggests that everything in that AppNote is average, not superior performance.
?
I agree with MaticH that the comparison is rather poor.? It should be much better, if not exact.
?
But read on.? I think there are reasons to explain it.
?
AppNote AN90034 was published in April 2022.? The LTspice model used today is dated June or July 2023.? We know it is a different model file because it lists a different number of MOSFETs than the ones shown in Figure 1 of the AppNote.
?
AN90034 refers specifically to the LTspice model here:
? ?
But the one in MaticH's (and my) simulations is here:
? ?
?
I think there was a significant change when they went from V1.1 to V3, even though it was only one year.
?
The older ZIP file is no longer there.??I tried retrieving it from the Wayback Machine but they did not successfully save it.
?
So anyway, that is what I think happened.? Nexperia's model changed significantly between 2022 and 2023 and this explains why today's simulations differ so much from the plots in AN90034.
?
To make things even more interesting, Nexperia has yet another SPICE model for the same part, here:
That one is a non-encrypted generic SPICE model (Level=3 NMOS) and it should work in LTspice as well as most other SPICE programs.? It lacks the two thermal pins.? I did not try it, but I do not expect close agreement between that model, and the AppNote.
?
?
|
Re: Issue with Nexperia BUK7S1R0-40H PET LTspice model
This is a minor oversight (aka bug) in LTspice. It can't decrypt the file. You can clearly see this from the error messages in the log. Will be fixed in 24.1.6.
Meanwhile you can work around it: open the library in a text editor and remove the last end-of-line. Then it'll work.
?
Best Regards,
Mathias
?
On Tue, Mar 11, 2025 at 04:35 PM, eetech00 wrote:
?
There is a special model "BUK7xxxx-40H_LTspice.zip" that needs to be downloaded and used for the simulation in Fig. 13. There is a link in the app note that initiates a download. However, when the included simulation file is run, many errors are produced. Unfortunately, the library file is encrypted, so I'm unable to troubleshoot. So requires NXP support.
|
Re: Schematic drawing issues
Good point. Pixel pitch, I guess is the more proper term.
?
--
Michael Stokowski
LTspice Team
Analog Devices Inc.
|
Re: Brady Ridgway's Fuzz_Face (guitar "fuzz" circuit) simulations
One more thing to mention here:
?
Because LTspice finds the lack of a load (DC path) connected to node Vout, it "corrects" the omission by adding a small conductance (large resistance) there.? It has to do that because it can't solve for the circuit's voltages without it.? Every node must have a DC path to ground.
?
With GMIN connected there, there is a little current through the output coupling capacitor, rather than zero as it would be in theory.
?
Andy
?
|
Re: Schematic drawing issues
On Tue, Mar 11, 2025 at 12:00 PM, eetech00 wrote:
I'm sometimes use a 4K 65" sony TV as monitor.
Most modern TVs use algorithms designed to smooth imperfections in the video source material.? They help reduce the appearance of "grain" and similar noise.? Such a smoothing algorithm might completely erase 1-pixel dots.
?
I'm also assuming that you have a 1:1 correspondence between your computer's video resolution, and the TV's display.? If they don't match, it has to interpolate between adjacent pixels, which might also alter their appearance.
?
Andy
?
?
|
Re: Brady Ridgway's Fuzz_Face (guitar "fuzz" circuit) simulations
Brady,
?
Here's a better explanation for the difference you saw.
?
Plot the voltage at the top of R1, which is the supply voltage for the fuzz circuit.
?
In the "original" circuit, it stays steady at -9.000 V.? It was at -9 V already at the very start of the simulation, because V1 is a pure DC source.
?
In the "+G" circuit, the same voltage point starts at 0 V, and then ramps towards -8.5 V over the first 7 ms or so.? This has a profound effect on the voltage on the right of R2, which connects to the output coupling capacitor.
?
In the original circuit, the voltage V(N001) starts at -8.51 and pulses to -9.0 V occasionally.
?
In the modified circuit, the same voltage (now V(N002)) starts at 0 and sweeps towards -8 V as the regulator powers up.? That ramp couples through the capacitor to Vout.? That is the reason for the difference you saw.
?
If you run the simulation using ".tran 0 50m 10m", the displayed difference appears to be much smaller because the ramping portion in the first 10 ms is ignored.? However, a large DC offset remains.? That's because of the lack of any load connected to Vout.
?
Andy
?
|
Re: Issues running LTspice as a batch service
On Tue, Mar 11, 2025 at 11:11 AM, Jeff Kayzerman wrote:
Ok I tried it with a normal windows process leveraging the cli (not spicelib) and it works. So the entire problem was passing a .asc instead of a .net file.
?
?
Can you share the command parameters that you used?
|
Re: Issues running LTspice as a batch service
Ok I tried it with a normal windows process leveraging the cli (not spicelib) and it works. So the entire problem was passing a .asc instead of a .net file.
|
Re: Brady Ridgway's Fuzz_Face (guitar "fuzz" circuit) simulations
On Tue, Mar 11, 2025 at 01:56 PM, John Woodgate wrote:
I can't find the standard.bjt upload.
It's inside the .ZIP file.
?
Anyway, you don't need it.? Just copy-and-paste one of the two AC128 .MODEL statements in my previous message.
?
Brady had uploaded two schematics and his standard.bjt as three separate files.? I moved all three into one .ZIP file.? He should have done that, but I took care of it for him.? I did not think it was a good idea to leave the file "standard.bjt" out there in the open, so it is in the .ZIP file now.
?
Note to everyone:? DO NOT move Brady's standard.bjt file to LTspice's component library folder, which would replace LTspice's own standard.bjt.? That would mess up your LTspice installation.
?
?
|
Re: Schematic drawing issues
Well, no, I meant 'somehow', because I am not
sure that it's possible to actually alter pixel size.
On 2025-03-11 17:49, mstokowski via
groups.io wrote:
On Tue, Mar 11, 2025 at 09:28 AM, John Woodgate wrote:
Yes, I brought it up, and ADI have agreed that it
needs to be fixed. I guess pixels are somehow smaller now than
when Mike E wrote the code for the dots.
I think you forgot the :^).? …somewhat smaller.
?
I do like the crosses idea.
?
mike
--
Michael Stokowski
LTspice Team
Analog Devices Inc.
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
Re: Brady Ridgway's Fuzz_Face (guitar "fuzz" circuit) simulations
I can't find the standard.bjt upload.
On 2025-03-11 17:41, Andy I via
groups.io wrote:
Brady? Ridgway uploaded some files to the Temp folder, which
are now inside "Fuzz_Face_+G.zip".
?
But Brady forgot to send a message here.? Brady, please READ
the group's guidelines on its main webpage.? After
uploading something, it is crucial that you compose and send an
actual message here to this group, telling us what you did.? You
forgot to do that. ?
Everyone else, here is the file Description that Brady used
with his uploaded files:
?
I am a beginner. I have uploaded two circuits, both of the classic Fuzz Face, which differ mainly in the power supply. Apart from the LT1054 and its components, the circuits are, I believe, identical. Graphing the voltage in most of the circuit produces very similar results, with the losses in the LT1054 being the cause. However, the current through the final capacitor C1/C3 (unfortunately I haven't indexed the circuits the same way) is completely different, as is the voltage at 'Vout'. Would someone please explain what I am missing?
?
Some of us here will remember the Fuzz Face.? It is a guitar
"fuzz" circuit.? If I remember correctly, it simulates poorly in
LTspice, suggesting that the circuit works differently than
SPICE simulations suggest.
?
Andy
?
--
OOO - Own Opinions only
If something is true:
* as far as we know - it's science
*for certain - it's mathematics
*unquestionably - it's religion
|
John Woodgate
DerekK
Jay Philippbar
Tony Casey