Fwd: Re: summer in appalachia
Mel Chua
ECE at Cornell. Hopefully you folks can make our our conversation --
I'll move subsequent ones to list.
On Fri, Apr 13, 2012 at 9:25 AM, Mel Chua <m...@melchua.com
<mailto:m...@melchua.com>> wrote:
> (first, would you mind if I passed your note on to the craftoe
> mailing list? it's got some great thoughts.)
Go ahead
I was briefly checking out the craft of electronics material, and I was
wondering if you guys are doing anything with simulation, or if you're
focusing just on hardware? I didn't see much on simulation, and the one
thing that I didn't get from Circus with Brad, or The Brian and Gill
show with Gill and Brian (AKA Circuits and ModCon) was a solid circuit
simulation background. Both the graduate level analog course at Cornell
and Circuits at Olin focused on equation-based or (to a degree)
intuition-based analysis, which didn't really 'click' with me until I
had a chance to set fire to hundreds of simulated transistors.
> No plans yet, but we're just starting (at the moment, we don't have
> specific plans to, say, teach voltage dividers, but I'm pretty
> confident *that* will happen). I am intrigued by this, because (as
> you can guess) I do not have any circuit simulation background, and
> have a terrible, *terrible* intuition for circuits; I can grind
> through the rote analysis, but that's about all. And I would love,
> love, love to have it 'click.'
> Tell me more? How would you do this? What tools did you use, what
> resources? How would you teach it to someone else -- and does it
> vary for the "someone elses"? I literally have no picture of what
> this would look like.
All of the circuit simulation tools I know are the industry tools, which
cost in the tens of thousands of dollars for a real licence (though a
lot cheaper for an industry licence). But basically, I used the Cadence
toolflow, I learned a little bit about the tools for a class (as they
are basically the industry standard), and then fiddled around with them
until I mostly could get them to do what I want. I'm going to need to
re-teach myself the tools soon for another project, mostly because I
never actually learned how to use them. =)
For that reason (never _actually_ learned this, but instead slammed
together enough knowledge to make it work), I'm probably not the best
person to answer the below questions, but I'll try to do my best.
> 1. someone like me -- undergrad (Olin) ECE who passed the classes
> with theory in 'em but wasn't the greatest electrical engineer in the
> world
I'd show you how to use the tools, show you how a few of the circuits we
built in ModCon correspond to circuits in the simulator. Do a brief
intro into Monte Carlo simulation (where you allow all of the parameters
to vary randomly, in order to discover the worst-case behavior)
and then encourage you to play around with a few different kinds of
amplifier.
> 2. someone like Matt -- a CS professor with mature heuristics for
> Learning New Stuff but no *formal* background in ECE; learned how to
> tinker with Arduinos and such on their own / from the intarwebz
Similar to above, but start off with passive filters and single
transistor amplifiers. Show him how to reproduce a few of the plots from
Horowitz and Hill (Art of Electronics) so he has a basis for building
more knowledge. (Related note: AoE isn't exactly what I'd call a good
text book. It has a lot of specific details which are really out of
date, and it's a bit dense at times. It's good as a reference, and it
can be useful for someone teaching themselves, but I don't think I'd
recommend using it for a class. (Semi-unrelated, I think I've lost my
copy of it again...))
> 3. a typical first-year Olin student walking in; smart, curious,
> likes building stuff, but simultaneously doing calc/e&m and with no
> prior electronics experience
I'd probably want to do what Gill and Brian were planning on doing if
they had a bit more time. Introduce the concepts of circuits solving
systems of equations though Matlab simulink (it is in many ways a
circuit simulator), and then try to build a correspondence between that
simultaneous equation solving and simple circuits in real life and in
simulation. Encourage us to fiddle around with the simulators, and
maybe do a bit of design-for-test (i.e. take a circuit, break it in some
way, Can you find how it was broken?), since that's the sort of thing
that takes a pretty high level understanding about what's going on.
The reason I skipped this step for you and Matt is because I assumed you
had at least sort of an intuition on how block diagrams work, because
that paradigm actually takes a lot of getting used to -- where things
are simultaneously being solved by all parts of the system, and there
isn't really a "flow". This is particularly interesting in electronics,
where the "flow" is backwards from what we would intuit (electrons go
from negative to positive), but it doesn't matter at all. My biggest
issue with the water model of electronics is how it builds this
intuition completely incorrectly.
I know that building things and learning to build debug-friendly
circuits by building circuits is nice, but doing circuit simulations can
let you get a lot of understanding about the underlying principles
without having to worry about the complications of the real
world. Plus, it can save a lot of money by letting you push the
components to their limits without having to buy new ones each time. =)
> Aye. :) I think Gill & Brian were *trying* to get us to do this with
> MATLAB in ModCon, sort of... but that's a general simulation
> framework, not really about circuits per se, and I think most folks
> spend that semester figuring out MATLAB and programming and
> breadboarding and systems theory and math modeling and...
> stuff-that-isn't-circuits (it's really a systems dynamics course way
> more than a circuits course, but that's also its design intent --
> it's just thought of as "circuits-y" because that's the first place
> most people see them).
> I don't know about the Brad show -- I actually never took it as it
> wasn't a requirement for my class of ECEs. (I... probably should
> have, in retrospect, but hey.)
Yeah, that's sort of what I said above. I didn't know Circuits wasn't a
requirement for you. That's kind of central, even though Olin Circuits
is absolutely nothing like circuits anywhere else.
(If I had infinite free time, I'd love to join this project, but
I don't really know anything about "open-source education" or whatever
this is,
> Oh, that just means "we'll have our conversations about designing
> the curriculum and stuff online, and make sure all the course
> materials are online under an open license, so people can see what
> we're thinking and comment on how to improve it, reuse our materials
> if they like, and have the context they need to understand how our
> materials are supposed to be used." Basically, a forkable/cloneable
> class.
Ok, that's pretty cool. Are you going to videotape the lectuers, too?
I don't know if you've seen the things that Stanford's doing this
semester with the crypto classes and etc, but it's pretty interesting.
(I'm currently sort of taking their Crypto and Algorithms Courses,
since I needed a review there, and it's actually really nice.)
I'm also curious: is there anything like a community for open-source
educators? Or is the community "Mel's friends whose she's convinced to
do this"?
and my level of free time is closer to 1/infinity than infinite)
> ...yeah, I can sympathize. Let me go write my overdue paper now.
> *sigh*
Haha, and now I'm back to editing my NSF update as well as coding.
Also, this just came to me:
The most important intuition that I built was basically: When can I and
when can't I consider electronic devices to be linear. If you assume
everything is linear, then the analysis are almost trivially easy, and
will give you the correct results the majority of the time. However,
there are many times when linear analysis breaks, and it typically
breaks in very consistent ways. Discovering these breaking points, and
how to modify my mental analyses is probably what I learned most from
babbling about with simulation tools.
Good luck!
--Stephen
--
Mel Chua
m...@purdue.edu
PhD student, Open Source & Education focus
Purdue University, Dept. of Engineering Education
Jan
> between that simultaneous equation solving and simple circuits in real life and in simulation. Encourage us to fiddle around with the simulators, and maybe do a bit of design-for-test
Mel Chua
> check. Should I order it if I find we don't already have a Simulink license?
Personally, I'd save the money and try to use something like Octave --
though it's not clear yet what role like MATLAB or some other equivalent
will have in the curriculum yet, so this might be a moot point anyway.
:) But it's nice to know it might be an option!
Matt Jadud
> A note from Stephen Longfield, an Olin alumni who's now doing his PhD in ECE
> at Cornell. Hopefully you folks can make our our conversation -- I'll move
> subsequent ones to list.
I know Stephen. Is he on our list now? No. OK. Well, we can rope him
in when we can/need him. (Ninja in the wings!)
> I was briefly checking out the craft of electronics material, and I was
> wondering if you guys are doing anything with simulation, or if you're
> focusing just on hardware? I didn't see much on simulation, and the one
We're not that far along, of course, but this is a good question.
While I'm a big fan of "hands on," the reality is that it is hard to
see what is inside a circuit quickly, easily, and reliably. Too often
you need someone to come and wiggle the right thing before the scope
shows you what you need to see... a "perfect" circuit and scope
combination (simulator) could be a Very Good Thing.
> and Circuits at Olin focused on equation-based or (to a degree)
> intuition-based analysis, which didn't really 'click' with me until I
> had a chance to set fire to hundreds of simulated transistors.
Fire. Mmmm.
> All of the circuit simulation tools I know are the industry tools, which
> cost in the tens of thousands of dollars for a real licence (though a
> lot cheaper for an industry licence). But basically, I used the Cadence
> toolflow, I learned a little bit about the tools for a class (as they
I think there are a few open packages that may, or may not, get the job done.
The Quite Universal Circuit Simulator (qucs)
http://qucs.sourceforge.net/screenshots.html
Logisim
http://ozark.hendrix.edu/~burch/logisim/
These (and any others we might find) would need to be tested and
verified for specific questions... that is, either/both might work
well for Question A, but Question B might cause it to crash, while
Question C might give the wrong answer, while...
> I'd show you how to use the tools, show you how a few of the circuits we
> built in ModCon correspond to circuits in the simulator. Do a brief
> intro into Monte Carlo simulation (where you allow all of the parameters
> to vary randomly, in order to discover the worst-case behavior)
> and then encourage you to play around with a few different kinds of
> amplifier.
Interesting. I think I'd start with simulation, move to the circuits,
and then come back to Monte Carlo, and then go back to the circuit to
explore the limits, but the idea is the same.
(OP-AMPS! OP-AMPS! OP-AMPS!)
>> 2. someone like Matt -- a CS professor with mature heuristics for
>> Learning New Stuff but no *formal* background in ECE; learned how to
>> tinker with Arduinos and such on their own / from the intarwebz
Actually, I learned by writing compilers, and then virtual machines,
for Real Hardware. Finally, I learned about the hardware. It sounds
more impressive. (Revisionist history FTW.)
> Similar to above, but start off with passive filters and single
> transistor amplifiers. Show him how to reproduce a few of the plots from
> Horowitz and Hill (Art of Electronics) so he has a basis for building
Makes sense.
> more knowledge. (Related note: AoE isn't exactly what I'd call a good
> text book. It has a lot of specific details which are really out of
This is what we thought. Good.
> they had a bit more time. Introduce the concepts of circuits solving
> systems of equations though Matlab simulink (it is in many ways a
We don't have a calc-based foundation, so systems of dynamic equations
may be the wrong approach, but...
> simulation. Encourage us to fiddle around with the simulators, and
> maybe do a bit of design-for-test (i.e. take a circuit, break it in some
> way, Can you find how it was broken?), since that's the sort of thing
> that takes a pretty high level understanding about what's going on.
That I like.
> The reason I skipped this step for you and Matt is because I assumed you
> had at least sort of an intuition on how block diagrams work, because
> that paradigm actually takes a lot of getting used to -- where things
> are simultaneously being solved by all parts of the system, and there
> isn't really a "flow". This is particularly interesting in electronics,
This is absolutely right. Getting to the students that they are
functionally decomposing circuits, and understand that it's an "all at
once" proposition (and Stephen goes on to talk about the brokenness of
the water flow model) is spot on.
> without having to worry about the complications of the real
> world. Plus, it can save a lot of money by letting you push the
Yep.
> (If I had infinite free time, I'd love to join this project, but
> I don't really know anything about "open-source education" or whatever
> this is,
import infinitetime
> Ok, that's pretty cool. Are you going to videotape the lectuers, too?
> I don't know if you've seen the things that Stanford's doing this
Lectures?
Actually, if we need to produce material, yes, the revolution will be online.
> The most important intuition that I built was basically: When can I and
> when can't I consider electronic devices to be linear. If you assume
> everything is linear, then the analysis are almost trivially easy, and
> will give you the correct results the majority of the time. However,
> there are many times when linear analysis breaks, and it typically
> breaks in very consistent ways. Discovering these breaking points, and
> how to modify my mental analyses is probably what I learned most from
> babbling about with simulation tools.
Actually, this is a really interesting question to ask practicing
EEs/ECEs (I'm also thinking uberhackers extrordinaire, like Jeri
Ellsworth, Lady Ada, etc.): what are the most important things you've
learned about electronics design and construction? What are the
intuitions and lessons that have lasted beyond the details?
I don't remember much of my undergraduate degree in physics, but I
remember enough to be able to talk to physicists and follow the
conversation. Also, the methods and intellectual tools absolutely
served me unfailingly. So, the fragile knowledge went away, and the
deeper learning outcomes were 100% applicable to going on into
computing. What are those things for practicing EEs and ECEs?
I'm uploading some pictures... I'm in Berea at the moment (for just
today, really), so this might be a good time for any questions you
have about the place.
Cheers,
M