From: zlau@arrl.org (Zack Lau)
Newsgroups: rec.radio.amateur.misc
Subject: Re: QST Content Revisited
Date: 12 Aug 92 10:44:22 EDT
Organization: American Radio Relay League

Well, since Gary is looking for insights in the design process.
I've decided to brazenly reword a fundamental mathematical to get:

No set of design rules complete enough to be useful will yield
all the good designs.  There will always be designs out of the
range of the design rules.   A typical example is Lawsons's PV-4
antenna--which is an excellent 4 element yagi that violates the 
rules he developed for designing antennas.  

In fact, to get the most of a design, one of the first techniques 
I often use is to throw away the rules of thumb and look at the
underlying principles.  Those rules are often okay for typical designs,
but when you want high performance, forget them.  This poses a problem
for most people in that you actually have to understand the circuit inside
and out.  Since I often can't solve real life circuits with exact
equations, I sometimes resort to "fuzzy equations."  These abominations
often have constants that are merely educated guesses.  I am extremely
reluctant to publish such equations, since they are developed specifically
for given conditions.  Its been my experience that a surprising number
of people attempt to use equations without understanding all the underlying
assumptions and constraints used in developing them.

However, these guesses can be surprisingly accurate.  I really surprised
some people with the first 2 meter preamp I ever built.  At 0.13 dB noise 
figure and over 20 dB of gain, it came in second at the 1992 Central
States VHF conference.  Maybe one day I'll go ahead and use the data it
was suppose to generate and improve the design.  

In rec.radio.amateur.misc, gary@ke4zv.uucp (Gary Coffman) writes:
>In article <378@arrl.org> zlau@arrl.org (Zack Lau) writes:
>>In rec.radio.amateur.misc, lapin@casbah.acns.nwu.edu (Gregory Lapin) writes:
>>>
>>>With everyone who is in favor with contruction articles, I agree.  However,
>>>I have an additional request for the authors:  In addition to telling me
>>>how to make something (be it an antenna or a QRP tranceiver), how about
>>>telling me why it was done that way?
>>>
>>>True, I have gotten used to academic literature and I am not advocating
>>>pages of mathematics in QST, but I would be very interested in learning why
>>>an author chose a particular method to design something and what the
>>>alternatives were.  There is very little of this type of explanation in the
>>>construction articles that I have seen in QST.
>>>
>[deleted]
>>Of course, there are authors who do optimize their circuits, but these
>>people are in the minority.  However, trying to retrace exactly how you
>>got there is often a tenuous exercise at best, particularly considering
>>that many of the better projects really took years to evolve into their
>>final (?) form.  Perhaps one should keep in mind that designing is much
>>more of an art than a science.   Then again, maybe professional artists
>>do know how they get and develop their ideas ...
>
>Zack, I think you've just described the difference between tinkerers 
>and engineers. A good product is *engineered*, the rest just happen
>to work. The difference between art and engineering is that the artist
>rarely understands why he's doing something while the engineer usually
>does. At the very least he has rules of thumb that he follows.
>
>Now what several of us are saying is that we'd like to see articles
>that lead up *from* random tinkering to real *engineering* of circuits. 
>That doesn't have to be extremely rigorous, we are amateurs after all, 
>but it should be better than what we have been getting. At the very 
>least, a series of snapshots of the author's thought processes as he 
>makes various design choices would be illuminating. Does that make
>the author's job harder, it can if he doesn't keep an engineering 
>notebook. Perhaps an article on how to properly document work in 
>progress is needed. A "How to Design" series would be very useful.
>
>I've had 30 years experience, and yet I still sometimes feel like
>I'm poking around in the dark at the start of a new project. I've
>developed a personal systematic line of attack that I use in such
>cases. Write a specification, break the design into subsystems,
>research, document, break the subsystems into individual circuits, 
>research, document, try out individual module designs, test to see 
>that they meet specification, document, iterate, system test, 
>document, and iterate until success. Sometimes the iteration leads all 
>the way back to rethinking the project. I'd really like to see how 
>others attack the design problem. That insight could make me a better 
>designer.
>
>Gary KE4ZV
>