Where to accurately place nonlinearities on a digital filter

[SNFK]

I think I understand what you are saying. Is IED just the current allowed through the diode? Wouldn't IB's current get mixed in and go out the emitter?

[mystran]

I think I understand what you are saying. Is IED just the current allowed through the diode? Wouldn't IB's current get mixed in and go out the emitter?

Yeah, Ied = Is*(exp((Vb-Ve)/nvt)-1).

There is (1-alpha) times that much current coming from the base and alpha times that much coming from the collector. That's how transistors work: small base current controls a larger collector current.

[DaveClark]

Now might be a good time to reiterate what I first posted about going back and forth between linear and nonlinear modelling. An approach that is widely used for real-time simulation is to create a transfer characteristic for a nonlinear stage such as a transistor stage that utilizes the model that mystran posted. One can do a quasi-static sweep of the input signal of the transistor stage (complete with biasing resistors, etc.) and create a wave-shaping curve.

In looking both downstream and upstream in the schematic, one should be able to identify Rs and Cs (and in rare cases nowadays, Ls) that form filters. These can be treated as separate blocks. You shouldn't try to stuff the results of a transistor-stage analysis into the set of equations for a filter somewhere and hope it will work. Now in SPICE and other circuit simulators, the circuit is indeed all solved in a consistent manner, but this one block at a time approach is much faster. One does need to understand how to identify these filters. For example, in the ElectroSmash analysis given in an earlier link, there is a 15.9 KHz low-pass filter. The question is, where does it go? Well the purpose of this is to limit the frequencies coming from the nonlinear action of the diodes, so it goes after the diode stuff.

There's a lot more to consider, but I thought it might be good to give at least one overall "big picture" that doesn't include just throwing everything into one big pile of math and hoping it all works out somehow.

[SNFK]

Now might be a good time to reiterate what I first posted about going back and forth between linear and nonlinear modelling. An approach that is widely used for real-time simulation is to create a transfer characteristic for a nonlinear stage such as a transistor stage that utilizes the model that mystran posted. One can do a quasi-static sweep of the input signal of the transistor stage (complete with biasing resistors, etc.) and create a wave-shaping curve.

In looking both downstream and upstream in the schematic, one should be able to identify Rs and Cs (and in rare cases nowadays, Ls) that form filters. These can be treated as separate blocks. You shouldn't try to stuff the results of a transistor-stage analysis into the set of equations for a filter somewhere and hope it will work. Now in SPICE and other circuit simulators, the circuit is indeed all solved in a consistent manner, but this one block at a time approach is much faster. One does need to understand how to identify these filters. For example, in the ElectroSmash analysis given in an earlier link, there is a 15.9 KHz low-pass filter. The question is, where does it go? Well the purpose of this is to limit the frequencies coming from the nonlinear action of the diodes, so it goes after the diode stuff.

There's a lot more to consider, but I thought it might be good to give at least one overall "big picture" that doesn't include just throwing everything into one big pile of math and hoping it all works out somehow.

I feel like I overlooked this a bit the first time, you raise a very good point. I'm still a novice in electronics compared to some of the people here. Right now my approach with analog modeling is to split a circuit into smaller chunks and work off of each chunk, understanding what each chunk does, and using nodal analysis + electric laws and theories + basic math to find a way to simulate it. I don't have any intention right away to model every single detail of a diode or transistor, as long as there's something there that I can understand that gives a result similar(ish) to the SPICE result.

[SNFK]

When modeling an analog circuit, would it be worth modeling in Johnson–Nyquist noise? Based on my research it would be absolutely pointless if you’re attempting a “perfect” model, but what about simulating poor aging?

Another question that has come up in my research- Would the only saturation come from overloading the op amp based on its Vcc input voltage?

[mystran]

When modeling an analog circuit, would it be worth modeling in Johnson–Nyquist noise? Based on my research it would be absolutely pointless if you’re attempting a “perfect” model, but what about simulating poor aging?

Noise (in general, regardless of source or spectrum) is a dividing topic, but if you choose to "model" it then I would personally not bother with anything too scientific, for two reasons:

1. generating good quality random numbers is (relatively) expensive and the problem with random numbers, yet the more random numbers you inject into a given system, the higher the quality of the source needs to be in order to avoid correlations building up into patterns, which by definition are not what you want if you're trying to inject noise

2. while noise can certainly be filtered, in most cases the effect of relatively low levels of noise is mostly just a more or less consistent "noise floor" (duh) which can certainly mask other digital artifacts (eg. quantization distortion, low levels of aliasing, low levels of interpolation "noise"), but the individual contributions of individual sources of noise in individual components probably don't matter when most of the time the end result is probably pinkish at low frequencies and whitish at higher frequencies.

I'm personally somewhat of a fan of artificially injecting a consistent noise-floor, but I'd generally just inject it somewhere early in the signal path and then be done with it. YMMV.

Another question that has come up in my research- Would the only saturation come from overloading the op amp based on its Vcc input voltage?

Opamp is just a transistor circuit like any other, so the answer really is that it depends on the opamp and how it's placed in the circuit. Theoretically the input will saturate at some voltage, but when configured in a typical circuit as an amplifier (ie. you're not using it in open-loop as a comparator or something) the opamp is trying to maintain it's own differential input voltage at 0V which effectively makes the non-linearity of the input more or less moot.

On the other hand, if you do drive the opamp into voltage rails (or however close it is actually getting and assuming it can deal with this gracefully) then this means you're almost certainly not getting enough negative feedback to actually pull the input to 0V in which case it's possible that input non-linearity might come into play. If you expect the opamp to also swing around a lot, then you might want to consider worrying about slew-rates too (eg. add an internal one-pole low-pass stage to limit the high-frequency gain or something), though this will then sometimes force you to also worry about more realistic stability conditions in terms of the additional phase-shift and so on..

That said, from what I've seen, unless you're specifically interested in details of some opamp and you just want something generic that's just realistic enough to not be able to supply infinite voltages, then modelling the output as some sort of sort-saturation (atan, tanh, etc) seems to be fairly common. Note that even if the output saturation as such might be "soft" in practice (due to high gain and insufficient negative feedback) a typical opamp circuit (with this sort of model at least) will still clip more or less as if it was hard-clipping.

Also... if you don't expect to drive the opamp anywhere near it's voltage rails (and arguably circuits that expect to clip usually don't intentionally use opamps for the purpose), then often times there's nothing wrong with just modelling the opamp as a perfectly linear ideal amplifier (depending on how it's configured; obviously this won't work for a comparator).

I was already kinda going to write this in response to what DaveClark said, but IMHO the hardest part of modelling something is really figuring out what to model and what to ignore, because there can be a steep rabbit hole where modelling some additional aspect will then force you to model other things more realistically as well.

[SNFK]

How would you go about implementing a triode model? A friend says he strongly prefers the valve saturation vs solid state, and I don’t blame him. What would be a good way to go about this?

[mystran]

Tubes are sufficiently complicated that I am not confident in giving advice on those, but there's a bunch of papers that are not hard to find with Google.

[DaveClark]

How would you go about implementing a triode model? A friend says he strongly prefers the valve saturation vs solid state, and I don’t blame him. What would be a good way to go about this?

I highly recommend:

https://www.willpirkle.com/fx-book-bonu ... -addendum/

I actually implemented something different for the basic triode model, using Norman Koren type of triode model (*), constructing tranfer characteristics with SPICE, then added Will's grid conduction modelling to make the distortion dynamic.

(*) http://www.normankoren.com/Audio/Tubemo ... ticle.html

Edited to add: The most comprehensive book I've ever seen on vacuum tubes is my physical copy of:

Karl R. Spangenberg. Vacuum Tubes. McGraw-Hill, 1948. There are copies out on the Internet, but they may be infringing.

[mystran]

There's also a few DAFX papers on the subject, eg.

https://www.dafx.de/paper-archive/2007/Papers/p169.pdf
https://www.dafx.de/paper-archive/2010/ ... 10_P12.pdf

[mystran]

Also something I want to really explicitly point out is that even SPICE is nowhere near perfect. There are circuits that work fine on breadboard, but completely fail in SPICE. There are circuits that work fine in SPICE, yet either simply don't work or even release their magic smoke if you try to build them. Sometimes the circuit "works" in both cases, but the results might be quite different.

Now, most "well designed" circuits should typically work just fine either way, but especially when modelling something that's a bit more "creative" (and there are plenty of such "creative" designs in audio circuits) it's a good idea to also try to validate your models against real hardware (eg. at least a breadboard model if you can't get access to the original; even if your home built copy is not 100% accurate, there's a good chance it's probably more accurate than SPICE).

This is basically why I personally try to stay out of the tube business, since I'm not confident enough with electronics to work with high-voltage circuits if given the choice.

[DaveClark]

It's important to differentiate between proprietary versions of SPICE and the versions that one can download from the Internet. I've known and worked with people who worked on proprietary, highly optimized versions of SPICE, although not personally on SPICE development myself. One of these developers has several times said that if SPICE (proprietary version) converges, it's probably correct. He also has several times said that SPICE is only as good as its models, referring primarily to the nonlinear models such as for transistors. He has over 35 years of experience in SPICE development. I mention this only because I feel somewhat defensive towards comments about SPICE which are based primarily on publicly available versions and by people who have no experience with industrial-strength SPICE. Not all SPICEs are equal.

[mystran]

One of these developers has several times said that if SPICE (proprietary version) converges, it's probably correct. He also has several times said that SPICE is only as good as its models, referring primarily to the nonlinear models such as for transistors.

If this is in reference to what I wrote, then I would like to clarify that these were kinda the points I was trying to address, because even when SPICE (whatever version) fails to converge, there's a good chance that it's ultimately a model limitation (or perhaps poorly chosen limits to a solver, but see below) and sometimes it converges and appears to work even if you pick a completely unrealistic model (or sink several mega-amperes worth of current).

I was definitely not trying to claim that SPICE (whatever version) is not a great tool, but rather simply that one should not automatically assume that whatever you get out of SPICE (whatever version) on the first try is automatically a great reflection of the reality.

Often it's essentially a matter of "PEBCAK" yet I recognize that when someone is asking for advice on basics of modelling on this forum, they are probably not qualified electrical engineers, they might not be using the most expensive commercial versions of SPICE (after all, Wikipedia claims that LTSpice is infact the most widely distributed and used version) with the best proprietary models in existence and (most importantly) all kinds of user errors are going to happen and sometimes these might not be obvious if your primary trade is software development.

In a sense, what I was trying to say is basically similar to a claim that "one should not assume that a C++ program that compiles is actually correct." I'm just trying to acknowledge reality, not criticize any particular proprietary SPICE-derivative product.

[DaveClark]

If you write SPICE with no qualifiers, many people here are going to assume that you are talking about SPICE in general because they don't know that proprietary verions of SPICE that go way beyond LTSpice even exist.

They may also conclude that if SPICE cannot do something, there is no hope for them to write a simulator that can do it, not realizing that there are other versions of SPICE out there that can do what they have in mind, and that there are books and articles out there that tell them how to do it.

Also, for people with little experience in SPICE, the most common cause of lack of convergence is lack of experience. It's like a city boy jumping on a bull.

[mystran]

If you write SPICE with no qualifiers, many people here are going to assume that you are talking about SPICE in general because they don't know that proprietary verions of SPICE that go way beyond LTSpice even exist.

SPICE (with no qualifications) is first and foremost the open source program sometimes refererred to as Berkley SPICE and/or the algorithms it popularized. If you want to argue about "SPICE in general" then I will argue that it is perfectly valid in this case to talk about the lowest common denominator.

If you want to talk about some proprietary product with proprietary technology, then speak about those products with the real names of those products. If you want to refer to the opinion of someone else, then name them. This is a technical forum, bring in the concrete facts and stop with the FUD that doesn't help anyone.

Yes, I am aware there are commercial circuit simulators. Yes, I'm aware that some of those commercial circuit simulators are derived from SPICE and/or carry SPICE as part of their names. In fact, even LTSpice is such a derivative. There are even commercial circuit simulators with "Spice" in their name that actually have nothing to do with Berkley Spice beyond being circuit simulators and probably sharing some core ideas.

Also, for people with little experience in SPICE, the most common cause of lack of convergence is lack of experience. It's like a city boy jumping on a bull.

Yes, and this is exactly what I was referring to when I said "SPICE is not a perfect tool."

It is a tool very similar to a programming language interpreter. It takes your model (ie. "source code") and runs some sort of a DAE solver on it. If the result converges and the version you are using is not buggy (or doesn't run into some numerical problem), then the result is "correct" in the same sense that a compiler that is not buggy will always compile your code into a "correct" program.