A nerd question, but I love using cool demos to raise interest in my EE undergrads. Is there anything more specific you can say about using PSpice methods in DIVA without revealing trade secrets? Do you mean using Runge-Kutta style methods (or stiff solvers; I don't need to know the details) to solve differential equations describing the circuitry in realtime?
Half the students will snicker (in a Beavis and Butthead voice: "he said 'stiff solvers'"), but the other half drool over seeing the algorithms they've been using for a year already in LTSpice be used in a very cool application.
Is there anything more you can say about it?
DIVA & PSpice
-
- KVRian
- 610 posts since 6 Mar, 2005 from USA
-
- KVRAF
- 1617 posts since 11 Dec, 2008 from Minneapolis
Have you been following KVR threads much? Urs has mentioned a fair bit about the tech, perhaps there's something that's relevant to what you want to know in there. The big Diva thread has a lot of suggestive information, probably some other u-he forum threads too. Also a couple I remember elsewhere -
http://www.kvraudio.com/forum/viewtopic ... highlight=
http://www.kvraudio.com/forum/viewtopic ... highlight=
(I think Urs said each of the filters took months, so I'm assuming the solvers are optimized further than PSpice could, but you'd have much better insight than me on that ... or how ...)
http://www.kvraudio.com/forum/viewtopic ... highlight=
http://www.kvraudio.com/forum/viewtopic ... highlight=
(I think Urs said each of the filters took months, so I'm assuming the solvers are optimized further than PSpice could, but you'd have much better insight than me on that ... or how ...)
-
- u-he
- 30222 posts since 8 Aug, 2002 from Berlin
Well, of course we haven't used PSpice, and we haven't found anything that would be fast enough, or even similar sounding.
I'm not an EE or anything, and people are often surprised how little I know about terminology etc. (but show me an algorithm...) - I'm currently not even sure if we solved any stiff problems or not. Maybe Clemens can chime in.
While methods explained in papers do analytical integration of circuits, we simply went the other way and did numerical integration.
Analytical methods involve a massive amount of maths to build derivates and what not of the filter equation. While that may be doable, it's not exactly something that lends itself to tweaking afterwards, e.g. swapping a transistor curve might put you back to square one. However, if you ever get them spot on, they might be rather fast, and maybe accurate enough. I don't know how the performance suffers with multiple non-linearities involved. To be honest, that stuff is over my head.
Numerical methods are easy on maths (good for me), because the filter algorithm itself literally looks the same as good old z-1 method we're used to. To get there we reduced the full blown matrix of state variables to basically two knots (or what they're called) that we bring to an equilibrium. Don't get me wrong, we're cooking with water here. 3 or 4 knots might be possible too, which we might try next year.
Apart from being able to implement any number of non-linearities, the main advantage of latter method is its simplicity. It lends itself towards tweaking, and a massive amount of tweaking was necessary to get it to sound right - or to drop things that cost more than they add to the sound. A lot of work has to be done by hand and ear.
You see, there is no Noble price for maths guys, and even if, we wouldn't get it
I'm not an EE or anything, and people are often surprised how little I know about terminology etc. (but show me an algorithm...) - I'm currently not even sure if we solved any stiff problems or not. Maybe Clemens can chime in.
While methods explained in papers do analytical integration of circuits, we simply went the other way and did numerical integration.
Analytical methods involve a massive amount of maths to build derivates and what not of the filter equation. While that may be doable, it's not exactly something that lends itself to tweaking afterwards, e.g. swapping a transistor curve might put you back to square one. However, if you ever get them spot on, they might be rather fast, and maybe accurate enough. I don't know how the performance suffers with multiple non-linearities involved. To be honest, that stuff is over my head.
Numerical methods are easy on maths (good for me), because the filter algorithm itself literally looks the same as good old z-1 method we're used to. To get there we reduced the full blown matrix of state variables to basically two knots (or what they're called) that we bring to an equilibrium. Don't get me wrong, we're cooking with water here. 3 or 4 knots might be possible too, which we might try next year.
Apart from being able to implement any number of non-linearities, the main advantage of latter method is its simplicity. It lends itself towards tweaking, and a massive amount of tweaking was necessary to get it to sound right - or to drop things that cost more than they add to the sound. A lot of work has to be done by hand and ear.
You see, there is no Noble price for maths guys, and even if, we wouldn't get it
-
- KVRian
- Topic Starter
- 610 posts since 6 Mar, 2005 from USA
Thanks for the links xh3rv, and even more thanks to Urs for re-asking my question for more elegantly: that integration methods vs. symbolic solutions were used. My students will love this as a demonstration (in the classroom, not try-before-buy, sense) of what numerical solutions to simultaneous DE equations can do!
I don't think anyone knows how performance changes with increasing numbers of nonlinearities, which is probably at least partly why so much effort is given to linearizing nonlin problems around operating points and then resolving for new operating points at each iteration.
BTW, I recognize the wisdom in your quote "A lot of work has to be done by hand and ear." I've worked in solid modeling for many years and it surprises many that good finite element analyses of new problems require that you backsolve from the result you're trying to find.
With responses like this, no wonder why you have such a rabid following. I don't know where you find the energy. Count me in too.
I don't think anyone knows how performance changes with increasing numbers of nonlinearities, which is probably at least partly why so much effort is given to linearizing nonlin problems around operating points and then resolving for new operating points at each iteration.
BTW, I recognize the wisdom in your quote "A lot of work has to be done by hand and ear." I've worked in solid modeling for many years and it surprises many that good finite element analyses of new problems require that you backsolve from the result you're trying to find.
With responses like this, no wonder why you have such a rabid following. I don't know where you find the energy. Count me in too.
-
- u-he
- 30222 posts since 8 Aug, 2002 from Berlin
Thanks man!
Actually, we did start out with the linear form for the Sallen-Key filter. We haven't seen any usable code example for it, so we started from the differential equations of the linear cases. We found as many as we got books about them. I think there's a simple reason for the lack of code examples. Sallen-Keys are not intuitively split into integrators and multipliers. However, warping, mogrifying, guessing and brooding over the (rather simple!) linear equations gave us a nice discretized model, into which we then carefully inserted non-linear elements - until it screamed.
Cheers,
Urs
Actually, we did start out with the linear form for the Sallen-Key filter. We haven't seen any usable code example for it, so we started from the differential equations of the linear cases. We found as many as we got books about them. I think there's a simple reason for the lack of code examples. Sallen-Keys are not intuitively split into integrators and multipliers. However, warping, mogrifying, guessing and brooding over the (rather simple!) linear equations gave us a nice discretized model, into which we then carefully inserted non-linear elements - until it screamed.
Cheers,
Urs-
- KVRian
- 809 posts since 24 May, 2005
That's why I like Urs stuff, mtethods are no good for my songs.Urs wrote: While methods explained in papers do analytical integration of circuits, we simply went the other way and did numerical integration.
