Hey everyone.
So I found a pdf of the presentation this guy did in 2016 (which I had no idea and wasn't in the same country probably), and I found it difficult to get just by the pdf. So I burned some tokens on Claude Opus 5.5 to make it check the math and complete the presentation.
This is what I got: (attachment)

Description:
Christophe Basso's APEC 2016 seminar on FACTs (Fast Analytical Circuit Techniques): deriving transfer functions of linear circuits by inspection instead of nodal equations and heavy algebra. It starts with a critique of high-entropy expressions, which are correct but impossible to interpret or use in design. The goal is low-entropy forms, with gain, poles and zeros kept separate, where every term has a physical meaning. The foundation is the time constant: with the excitation turned off, the resistance seen by each capacitor or inductor is enough to build the denominator. Zeros are found by inspection or with null double injection (NDI), which looks for the conditions under which the signal fails to reach the output. One example compares the method with a Thévenin analysis, and results are checked in SPICE and Mathcad. The method is then extended to second-order networks, such as the buck's LC output filter (with parasitics), with a notation that tracks the state of each reactance. In the applied part, the PWM switch model linearizes only the switching cell and makes it possible to analyze CCM buck and buck-boost converters: control-to-output and input-to-output transfer functions, input and output impedances, and the right-half-plane zero.

Hope at least someone find it interesting someday, then my effort to post here is paid.

 

It sounds somewhat like dominant-pole analysis that has been presented in textbooks for decades. Maybe it is an extension of that.

 

It sounds somewhat like dominant-pole analysis that has been presented in textbooks for decades. Maybe it is an extension of that.

It's not the dominant-pole analysis, it's a method to get the transfer function by inspection and in the form of "low entropy". So this is faster, intuitive, and useful.

 

Forgot to mention: there are few graphical errors, but it doesn't prejudice the understanding. I made it with Opus 5.5 on Ultracode (maximum effort), thus there's not much room for improvement.

 

I went thru the presentation and I am reminded very much of the three semesters of senior level courses in my engineering collecge 1969 thru 1972."Feedback Systems (1),Feedback Systems(2), and Feedback Systems(3)!
We DID learn how to accurately model a "Closed Loop Transfer Function", which in the real world we would evaluate how it ferformed in the particular application, and adjust it as required. Usually we came quite close initially. I DID need to bail out an associate one time who found that the calculated values did not work.
That education did provide useful insights on quite a few occasions but only a very few times did I need to use any of the math. That part of the education was also useful directly a few times.

 

Understanding the physical elements relation to the math parts is also quite handy. Especially inertia, friction, and free-play. (= deadband)

 

I went thru the presentation and I am reminded very much of the three semesters of senior level courses in my engineering collecge 1969 thru 1972."Feedback Systems (1),Feedback Systems(2), and Feedback Systems(3)!
We DID learn how to accurately model a "Closed Loop Transfer Function", which in the real world we would evaluate how it ferformed in the particular application, and adjust it as required. Usually we came quite close initially. I DID need to bail out an associate one time who found that the calculated values did not work.
That education did provide useful insights on quite a few occasions but only a very few times did I need to use any of the math. That part of the education was also useful directly a few times.

Sadly, it seems that they shrinked/squeezed the course, so now there's just an introduction in every topic. It misses applying the knowledge in real cases, it's different from the exercises. I'm talking about my country, but I can smell that as many subareas were created, this implied in more subjects to learn in the engineering course, so others were left out because they were "less important".
Graduates now have to be much more like a polyglot than a specialist in one area, because jobs require now that you do one thing that's completely unrelated to what you did yesterday. What I happened to see is that the vast majority of people know how to code, but lack the knowledge of how circuits work, how components work, the physics, the math... Sad technological times.

 

CERTAINLY there is no reasonable substitute for knowing AND UNDERSTANDING how things, including systems, actually function(work). As you implied, being a specialist in one area is not enough, hardly ever.
Aside from electronics, an actual ENGINEER participating in REAL WORLD projects need to understand both THERMODYNAMICS. and certainly KINEMATICS, although mastering all of the math may not be quite as important.

 

CERTAINLY there is no reasonable substitute for knowing AND UNDERSTANDING how things, including systems, actually function(work). As you implied, being a specialist in one area is not enough, hardly ever.
Aside from electronics, an actual ENGINEER participating in REAL WORLD projects need to understand both THERMODYNAMICS. and certainly KINEMATICS, although mastering all of the math may not be quite as important.

You're right. In my area of embedded systems, the engineers usually lack understanding on Linux, some variables attributes in C/C++, they usually are weak in math and doesn't know much about physics' laws. Not to mention electronics, some have no idea what a simple circuit does.
I've worked with a bunch of totally different projects and can assure you that I had to explain the math and physics on most of them to who I worked with. And it's not that I knew it all I came to do, but I had the basic knowledge because in college I had the curiosity to learn by myself, so I had a beginning to start with.
Even worse, engineers are lazy to do math, they don't want to model a circuit, some just put resistors and/or capacitors until it works. It's incredible such engineers graduated on the federal universities, I find it amazing that they don't know a thing anymore. I blame a bit on technology, because it's faster to simulate with different values than calculate the right one. It's faster to use Claude Code and test than to think about how to do/analyze the code before testing.

 

You're right. In my area of embedded systems, the engineers usually lack understanding on Linux, some variables attributes in C/C++, they usually are weak in math and doesn't know much about physics' laws. Not to mention electronics, some have no idea what a simple circuit does.
I've worked with a bunch of totally different projects and can assure you that I had to explain the math and physics on most of them to who I worked with. And it's not that I knew it all I came to do, but I had the basic knowledge because in college I had the curiosity to learn by myself, so I had a beginning to start with.
Even worse, engineers are lazy to do math, they don't want to model a circuit, some just put resistors and/or capacitors until it works. It's incredible such engineers graduated on the federal universities, I find it amazing that they don't know a thing anymore. I blame a bit on technology, because it's faster to simulate with different values than calculate the right one. It's faster to use Claude Code and test than to think about how to do/analyze the code before testing.

CERTAINLY you are not speaking about ALL of us engineers! What is correct is that I do not know C/C++ programming, nor am I handy with LINUX. BUT creating functional systems that outlive their lifetime warrenties has always been the goal and almost always the outcome. But not only the electronics and instrumentation , and those lengthly ladder lists , but also the kinematics of the mechanical portions always worked and kept on working. Of course, I did take a few M.E. courses, and also some chemistry, and ALL of the offered physics and materials courses. No, they were not easy, but it is certainly fun to be able to answer all of the questions adequately at a job interview. And it was handy to be able to spot mechanical issues in a machine long before it was built.

 

CERTAINLY you are not speaking about ALL of us engineers!

Yeah, that's why I said "in my area of embedded systems, the engineers..."

 

"Embedded Systems" always require working together between hardware design and software design/creation! If not at the same time, certainly in the creation of the detailed descriptions of exactly how the two interact, as to exactly what hardware does in response to control signals, and what software does in response to hardware inputs. Thatcan best happen when an overall concept of a system is completely defined.

 

Yeah. SW and HW is a part of the one. Just ESP32 is huge in possibilities and complexity, and STM32 is much more. But as you see me in this forum, I like more the analog part, control systems, the math behind calculating things (for example, RMS), and the physics needed to make a product.