New year's resolution
"Nick Gorham" wrote in message
...
Ian Iveson wrote:
How would you explain to a novice how to design a valve
amplifier?
I see two possible approaches. One way to begin is to
establish the purpose of the machine, divide that purpose
into a series of processes, and develop a block diagram
of a generic amplifier. The other is to examine various
circuit fragments in order to understand how they, and
their components, behave. These two approaches may be
termed "top down" and "bottom up", respectively. Most
books on design cover both aspects, in one order or the
other. Both can be dealt with using the common logic of
analysis.
Both are problematic. Whichever aspect the novice
encounters first, he will be bemused for lack of prior
understanding of the other. It's hard to grasp a block
diagram without knowing what might be inside the boxes
and why; and it's hard to grasp a fragment such as a
mu-follower without knowing what it might be used for and
why.
Perhaps the novice could be reassured if, in a preface,
the author were to acknowledge these problems, and
provide some logic that the novice might employ to guide
him through the process of learning to design?
This year I have resolved to write such a preface. Ideas
are welcome.
Is the process of design predictable? Can you
characterise the logic of development, from start to
finish?
The best structure, by far, I have come across is in the
late J L Hood's "Valve and Transistor Audio Amplifiers".
Typical circuits are introduced and analysed in
historical context, so the reader becomes aware of the
issues in just the same way as history did. However, the
reason for using such a narrative style is not made
explicit, and so the novice may not get the point.
New valve enthusiasts, and especially young people, are
needed or there'll be nothing left when we all die.
Which won't be this year, I hope.
Anyone else made a resolution.
Best wishes,
Ian
Well, with respect, I think you have decided to solve a
problem that you have decided exists, but in my experence
doesn't in the real world.
I'm unsure wether this is a semantic or a philisophical
difference. If you think that the process of design is not
problematic, then do you at least see it as an issue? If the
difference is philisophical, then perhaps I should make
clear that I believe that most problems still exist even
when a total solution has been found. What is left, in my
view, is problem + solution, rather than no problem. In
summary, just because I perceive the process of learning how
to design to be problematic, doesn't mean that I don't know
the answer, or failing that, have no plan to get to know it.
Otherwise I wouldn't have made my new year's resolution.
As a programmer who started in the 70's I am well aware of
the top down and bottom up design methods, and both work
just fine, the only issue is the middle out one.
My experience as an engineer in various fields, including
programming, has made made it clear that, for any but
trivial designs, both top-down and bottom-up are necessary.
Perhaps you mean that it doesn't matter with which one
starts? I would advise beginning with top-down, myself. How
one can know when to swap from one to the other is moot.
From what I have seen, Phil's answer is just about on the
money, people start wanting to build valve amps because
they want to use valve amps. They already have a goal.
Not, generally I would guess, a particular architecture.
That is, they don't begin with a top-down view of the
amplifier they wish to design. Their goal is merely
"amplifier" as an unknown entity that they hope will perform
a particular task to their satisfaction. A black box with a
set of performance criteria.
And they resolve this by either building a kit, or a
existing well documented design.
Resolve? Do you mean "achieve"? My experience here is that
those who build a kit often do so blindly. It achieves the
same goal, with respect to amplifier procurement, as picking
one from a dealer without listening. They also achieve the
goal of building an amplifier, but not of designing one.
They are unlikely to increase their understanding of
anything other than soldering, and maybe not even that. A
few may learn something from testing and adjusting their
creation.
Some never go further than this point. But some want to
know a bit more, so they read a lot of books, ask a lot of
questions on the internet, and try and follow the design
patterns that already exist, mix and match them to fit
their needs and interests.
Right, OK, this is more like what I'm looking for, thanks.
Some sense of process here. However, although the locus of
the process is interesting, it's the *logic* of the process
that I wish to uncover. What determines when it is advisable
to pursue one of your list of operations, and when another?
Can the apparent flitting from one to another, and the
character of each flit, be determined in advance? Can the
process be planned? Would it help the traveller on this
journey to understand its nature from the outset?
Some then never go past this as they have a block about
maths,
Code for "feckless", IMHO.
so they never go beyond graphical methods. Then a few more
progress to the point of trying to get to the level of
understanding of a EE in the 1950's. But from what I have
seen those that try and get to the 1950's level (I am
trying hard to get there myself) normally have a fair bit
of EE education in their background anyway, so they don't
need the basics explaining to them, and if they did, they
know what books to read to try and make up for the lacks
in the education.
There are a few on the fringes that are doing things that
were not done in the 50's, but they are not inventing new
topologies, they are just updating older ideas using
components that were not available in the 1950's
I wrote of design, not invention. Updating a design is a
form of designing. In my view, anything that requires a
decision about the value of a component, or where to put it,
is a design decision. People who have no knowledge of design
are apt to make the wrong decision, even if it is the
relatively simple matter of replacing a blown component
where no exact replica is available.
In the people I know (which I imagine is a small but
representive subset of the rest of the world) who mess
with valves, there are folk in all the groups, and there
seems to be no lack of interest in learning and building.
Tautological, surely? That is, amongst those with an
interest in valves, there seems to be no lack of interest in
valves.
Meanwhile, the rest of the world is full of people who, by
and large, have either no interest in any kind of
engineering whatsoever (because in my view they too are
feckless) or would like to pursue an interest but are lost
for a feasible point of entry. Valve engineering is not
special in that respect. The principles of my preface would
apply equally to all design engineering.
In terms of progress, in my view its simple, 1. Build a
kit, 2. Read Morgan Jones, 3. Buy a copy of RDH and read.
4. Keep reading RDH. And between 1 and 4, build, tinker
and measure a lot.
OK, good, this is a valuable insight, thanks. I note that
your plan appears to be an iterative process, being build,
read, build, read, etc. That carries with it the sense of
emerging history that I would wish to convey. It also seems
to make a distinction between modern or state-of-the-art
theory, and stock-in-trade or established theory (or perhaps
peripheral and fundamental, respectively). That would also
help to get across the fact that design is a historical
process, thanks.
It also says something about the relationship between the
pursuits of practice and theory. Is that the same as
bottom-up and top-down, or similar, or something quite
different, would you say? If on the other hand it is all
top-down, or bottom-up, then do you have an alternative plan
that would equally "work just fine"?
Anyway, as I wrote above, I am interested in the *logic* of
your plan. How does the novice designer know when to pass
from one activity to another? Can the details of each sortie
be determined in advance? How, exactly? Can the whole
sequence be summed up in a schedule that the novice can
follow? If not, then why not, exactly? If so, can that
schedule be generalised and applied to all kinds of design
work? What are its variables? Is there some formula that
relates those variables, each to the others?
cheers,
Ian
|