Is there a point to theoretical understanding?

Greetings:

I have begun to learn the subject of DSP, which started out with 
implementing a working 100-tap FIR filter in an AVR a few weeks ago. 
This is a subject that I find fascinating, particularly the applied 
mathematics aspect.  But also the hardware aspect, as there is something 
very satisfying about constructing a real machine that actualizes a 
mathematical concept.

I am planning a rigorous study of the theory of DSP, by working through
the Lyons text, and hopefully having time for some looks at Hamming's
"Digital Filters" text and some other texts on implementing
transcendental functions on computing hardware, app notes, etc.  I may
take a formal class as well.

In addition, I will be attending a series of workshops by TI as well as
Analog Devices in the next few months to familiarize myself with the 
TMS320* and particulary the F2812 DSPs, and the ADI 219x and SHARC DSPs. 
  I will hopefully begin experimenting with applying the DSP concepts to 
the evaluation kits I obtain before the end of the year.

Probably my first goal will be the DSP equivalent of the typical first
microcontroller program:  instead of a blinking LED, I'd like to manage
to sample data with an A/D, and spit it right back out to a DAC.  If I
can get that far, it's a piece of cake to start adding computational
activity in between.

But what I am getting at is this:  I have recently become aware of the 
existence of a large selection of software tools for developing DSP 
systems, which essentially make it possible for an engineer or even a 
technologist with minimal theoretical understanding of the mathematical 
guts of DSP algorithms, to produce working digital filters and other 
goodies with easy to use point-and-click interfaces.  The tools even 
give you the friggin' code!

Why then should one study the theory and learn how to calculate filter 
coefficients by hand?  (Or by one's own custom program, as I just did 
with Mathematica for my first FIR.)

I know of course, that by understanding the theory, one can apply
insight into problems that will stump another without the theoretical
grounding.  Also, one can produce higher-performing, customized,
hand-tooled solutions rather than just piecing together the canned
"modules" of functionality provided by the programs and tools that do
the thinking for you.  Finally, there is the intellectual pleasure, for
those who like that.

This seems to be rare though, as most folks would rather just produce a
result.  My being the former way is why I'm in the field of fundamental
research rather than the product industry.  But this doesn't make me a
champion of productivity.

This has me a a little bit concerned.  I could spend a few months 
designing a system, by exercising all my theoretical knowledge.  But 
this essentially amounts to reinventing the wheel, if the tools are 
available to do it for me, and there is no need for a highly optimized 
solution.  Meanwhile the guy down the hall produces a result in two 
weeks, and tells his boss "look I make a custom DSP digital filtering 
machine" when he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if 
someone like myself who really *wants* to start from scratch just 
belongs in academia or someplace where getting off on intellectual 
tangents is the point rather than an impedement.  Fortunately, Sandia is 
close enough to that that I don't get into any trouble here if I take my 
time.

Since there are such tools as these filter designers (TI also has 
automagic analog filter designer programs too, enabling someone who 
hasn't ever cracked a circuit analysis text to produce the same results 
by pointing and clicking that I could produce after considerable effort 
by working from scratch), I begin to wonder if the theoretical based 
engineers are in the minority even in production environments like 
industry?  In other words, does it further your career more to quickly 
produce results that work but you don't know why, vs. studying to 
develop the ability to know why things work, and to eventually make a 
few things which really exercise that understanding?  Things which 
couldn't be done by "cookbook engineering."

One final anecdote:  A few years ago I did a simulation of the basic
lock-in or synchronous demodulation amplifier, in Mathematica (because I 
didn't know SPICE very well yet then.)  I learned a great deal with 
this.  It started out by just asking myself one day "how does a lock-in 
work?"  I have not yet applied that learning to building a lock-in, but 
I know one day I may.

A co-worker spent almost 3 years taking a complicated system containing
two SRS lock-ins and other commercial electronic instruments, and
reducing it's size for portability by building all the electronics on
custom PCBs in a custom chassis.  When he finally got to testing the
customized lock-in, one day he was puzzled as to why the output signal
amplitude was varying all over the place as he adjusted the phase knob.
  He asked me if I had any idea what was wrong?

I pulled out my notebook from when I had looked at the basic operating
equations of a lock-in, which said of course that the output amplitude
varies with the cosine of the phase difference.

The fellow did a fine job considering his lack of theoretical
understanding, it is important to note.  But I couldn't help but to 
wonder how wise it was to have someone build the thing who didn't 
understand the very basic theory of the system they were building?  Yet 
he produced a result that met the goals.

Is this way of doing things common?


Thanks for comments.


Good day!


-- 
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

As with all things in engineering, "it depends".
In my opinion, the value of understanding the underlying theory is
invaluable. However, if the task on hand is to crank something out really
fast, clearly taking shortcuts is the best approach. If I was running an
engineering lab, I might allow the quick and dirty approach for prototypes
or proof-of-concept efforts, but anything beyond that will affect the lab in
the long term.

I'd also like to correct your interpretation of the various tools you've
seen. They are just tools - not a replacement for understanding the theory.
I'm fairly positive that people who understand the theory (for eg. Rick
Lyons) don't go about designing filters by hand just because they know how
to. They probably crank out their filters using Matlab or ScopeFIR just like
the guy who can't spell conlution (:-)). The difference is that they know
how to make the tool give the correct answer (is there such a thing?). I've
tried to use packaged tools in areas where I definitely lack the
fundamentals - I usually end up not knowing which button to click or what
parameters are appropriate. On the other hand, one might be able to achieve
quite a bit with these tools (that's the point, that some of these companies
making them, are trying to make) - but this depends on the long term vs
short term goals.

Since you didn't have a very specific question - it's easy to ramble on. So
I'll stop.

Cheers
Bhaskar



"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c27t320mkm@enews1.newsguy.com...
> Greetings:
>
> I have begun to learn the subject of DSP, which started out with
> implementing a working 100-tap FIR filter in an AVR a few weeks ago.
> This is a subject that I find fascinating, particularly the applied
> mathematics aspect.  But also the hardware aspect, as there is something
> very satisfying about constructing a real machine that actualizes a
> mathematical concept.
>
> I am planning a rigorous study of the theory of DSP, by working through
> the Lyons text, and hopefully having time for some looks at Hamming's
> "Digital Filters" text and some other texts on implementing
> transcendental functions on computing hardware, app notes, etc.  I may
> take a formal class as well.
>
> In addition, I will be attending a series of workshops by TI as well as
> Analog Devices in the next few months to familiarize myself with the
> TMS320* and particulary the F2812 DSPs, and the ADI 219x and SHARC DSPs.
>   I will hopefully begin experimenting with applying the DSP concepts to
> the evaluation kits I obtain before the end of the year.
>
> Probably my first goal will be the DSP equivalent of the typical first
> microcontroller program:  instead of a blinking LED, I'd like to manage
> to sample data with an A/D, and spit it right back out to a DAC.  If I
> can get that far, it's a piece of cake to start adding computational
> activity in between.
>
> But what I am getting at is this:  I have recently become aware of the
> existence of a large selection of software tools for developing DSP
> systems, which essentially make it possible for an engineer or even a
> technologist with minimal theoretical understanding of the mathematical
> guts of DSP algorithms, to produce working digital filters and other
> goodies with easy to use point-and-click interfaces.  The tools even
> give you the friggin' code!
>
> Why then should one study the theory and learn how to calculate filter
> coefficients by hand?  (Or by one's own custom program, as I just did
> with Mathematica for my first FIR.)
>
> I know of course, that by understanding the theory, one can apply
> insight into problems that will stump another without the theoretical
> grounding.  Also, one can produce higher-performing, customized,
> hand-tooled solutions rather than just piecing together the canned
> "modules" of functionality provided by the programs and tools that do
> the thinking for you.  Finally, there is the intellectual pleasure, for
> those who like that.
>
> This seems to be rare though, as most folks would rather just produce a
> result.  My being the former way is why I'm in the field of fundamental
> research rather than the product industry.  But this doesn't make me a
> champion of productivity.
>
> This has me a a little bit concerned.  I could spend a few months
> designing a system, by exercising all my theoretical knowledge.  But
> this essentially amounts to reinventing the wheel, if the tools are
> available to do it for me, and there is no need for a highly optimized
> solution.  Meanwhile the guy down the hall produces a result in two
> weeks, and tells his boss "look I make a custom DSP digital filtering
> machine" when he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if
> someone like myself who really *wants* to start from scratch just
> belongs in academia or someplace where getting off on intellectual
> tangents is the point rather than an impedement.  Fortunately, Sandia is
> close enough to that that I don't get into any trouble here if I take my
> time.
>
> Since there are such tools as these filter designers (TI also has
> automagic analog filter designer programs too, enabling someone who
> hasn't ever cracked a circuit analysis text to produce the same results
> by pointing and clicking that I could produce after considerable effort
> by working from scratch), I begin to wonder if the theoretical based
> engineers are in the minority even in production environments like
> industry?  In other words, does it further your career more to quickly
> produce results that work but you don't know why, vs. studying to
> develop the ability to know why things work, and to eventually make a
> few things which really exercise that understanding?  Things which
> couldn't be done by "cookbook engineering."
>
> One final anecdote:  A few years ago I did a simulation of the basic
> lock-in or synchronous demodulation amplifier, in Mathematica (because I
> didn't know SPICE very well yet then.)  I learned a great deal with
> this.  It started out by just asking myself one day "how does a lock-in
> work?"  I have not yet applied that learning to building a lock-in, but
> I know one day I may.
>
> A co-worker spent almost 3 years taking a complicated system containing
> two SRS lock-ins and other commercial electronic instruments, and
> reducing it's size for portability by building all the electronics on
> custom PCBs in a custom chassis.  When he finally got to testing the
> customized lock-in, one day he was puzzled as to why the output signal
> amplitude was varying all over the place as he adjusted the phase knob.
>   He asked me if I had any idea what was wrong?
>
> I pulled out my notebook from when I had looked at the basic operating
> equations of a lock-in, which said of course that the output amplitude
> varies with the cosine of the phase difference.
>
> The fellow did a fine job considering his lack of theoretical
> understanding, it is important to note.  But I couldn't help but to
> wonder how wise it was to have someone build the thing who didn't
> understand the very basic theory of the system they were building?  Yet
> he produced a result that met the goals.
>
> Is this way of doing things common?
>
>
> Thanks for comments.
>
>
> Good day!
>
>
> --
> ____________________________________
> Christopher R. Carlen
> Principal Laser/Optical Technologist
> Sandia National Laboratories CA USA
> crcarle@sandia.gov
>

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c27t320mkm@enews1.newsguy.com...
> Greetings:
>
>.................................
>
> But what I am getting at is this:  I have recently become aware of the
> existence of a large selection of software tools for developing DSP
> systems, which essentially make it possible for an engineer or even a
> technologist with minimal theoretical understanding of the mathematical
> guts of DSP algorithms, to produce working digital filters and other
> goodies with easy to use point-and-click interfaces.  The tools even
> give you the friggin' code!
>
> Why then should one study the theory and learn how to calculate filter
> coefficients by hand?  (Or by one's own custom program, as I just did
> with Mathematica for my first FIR.)

Chris,

You can always give a just-capable person a set of tools and turn him/her
loose on a "narrowly defined" task.  But, how narrow is narrow?

You can also have a task that suits itself to "technical / theoretical"
optimization when the task primary objective is to achieve optimization of
design efficiency.

You can also have a task that can't be addressed without technical
optimization / theory, understanding, etc.

How do you know which situation you're in?  Is it important?

Voltaire and Soviet Admiral Gorshkov are both credited with saying something
like:
"Better is the enemy of good enough".  I love to suggest that to engineers!

So, if you can design a "good enough" thingy using canned approaches and
tools that are fast, then more power to you.

The key is in "good enough".  The danger is in not knowing or considering
the worst case.

Fred

Bhaskar Thiagarajan wrote:
>[snip]
> 
> I'd also like to correct your interpretation of the various tools you've
> seen. They are just tools - not a replacement for understanding the theory.
> [snip]  The difference is that they know
> how to make the tool give the correct answer (is there such a thing?).

I think this comes *close* to an important point. With adequate 
understanding of theory, one knows whether the tool gave a reasonable 
result, or not. A correlary, you can choose appropriate tool.

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message
news:c27t320mkm@enews1.newsguy.com...
> Greetings:
[brevity clip]
Good question!.
I used Log tables and slide rules. Slow and tedious but understandable and
reinventable by a post-apocalypse individual. I now use a calculator,
extremely fast and powerful but not realistically reinventable.
Press one of the  trancendental buttons and a Cheb' polynomial is
approximated. Cheb' spent his life thinking about maths, his legacy I
thankfully use but I won't be changing career to allow understanding of the
nuances of his work.
Horses for courses. Specialists naturally turn up across the whole spectrum
of societies needs. The whole can therefore be worth more than the sum of
it's parts. Essentially it's nature's survival traits at work.
regards
john

Chris:

My wife can only drive cars with automatic transmissions.

She has never mastered a stick shift and clutch.

She lives a wonderfully full and useful life, but...

She will never win a Formula One race!

"If you want to run with the big dogs, you can't sit on the porch!"

--
Peter
Consultant - Signal Processing and Analog Electronics
Indialantic By-the-Sea, FL

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c27t320mkm@enews1.newsguy.com...
> Greetings:
>
> I have begun to learn the subject of DSP, which started out with
> implementing a working 100-tap FIR filter in an AVR a few weeks ago.
> This is a subject that I find fascinating, particularly the applied
> mathematics aspect.  But also the hardware aspect, as there is something
> very satisfying about constructing a real machine that actualizes a
> mathematical concept.
>
> I am planning a rigorous study of the theory of DSP, by working through
> the Lyons text, and hopefully having time for some looks at Hamming's
> "Digital Filters" text and some other texts on implementing
> transcendental functions on computing hardware, app notes, etc.  I may
> take a formal class as well.
>
> In addition, I will be attending a series of workshops by TI as well as
> Analog Devices in the next few months to familiarize myself with the
> TMS320* and particulary the F2812 DSPs, and the ADI 219x and SHARC DSPs.
>   I will hopefully begin experimenting with applying the DSP concepts to
> the evaluation kits I obtain before the end of the year.
>
> Probably my first goal will be the DSP equivalent of the typical first
> microcontroller program:  instead of a blinking LED, I'd like to manage
> to sample data with an A/D, and spit it right back out to a DAC.  If I
> can get that far, it's a piece of cake to start adding computational
> activity in between.
>
> But what I am getting at is this:  I have recently become aware of the
> existence of a large selection of software tools for developing DSP
> systems, which essentially make it possible for an engineer or even a
> technologist with minimal theoretical understanding of the mathematical
> guts of DSP algorithms, to produce working digital filters and other
> goodies with easy to use point-and-click interfaces.  The tools even
> give you the friggin' code!
>
> Why then should one study the theory and learn how to calculate filter
> coefficients by hand?  (Or by one's own custom program, as I just did
> with Mathematica for my first FIR.)
>
> I know of course, that by understanding the theory, one can apply
> insight into problems that will stump another without the theoretical
> grounding.  Also, one can produce higher-performing, customized,
> hand-tooled solutions rather than just piecing together the canned
> "modules" of functionality provided by the programs and tools that do
> the thinking for you.  Finally, there is the intellectual pleasure, for
> those who like that.
>
> This seems to be rare though, as most folks would rather just produce a
> result.  My being the former way is why I'm in the field of fundamental
> research rather than the product industry.  But this doesn't make me a
> champion of productivity.
>
> This has me a a little bit concerned.  I could spend a few months
> designing a system, by exercising all my theoretical knowledge.  But
> this essentially amounts to reinventing the wheel, if the tools are
> available to do it for me, and there is no need for a highly optimized
> solution.  Meanwhile the guy down the hall produces a result in two
> weeks, and tells his boss "look I make a custom DSP digital filtering
> machine" when he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if
> someone like myself who really *wants* to start from scratch just
> belongs in academia or someplace where getting off on intellectual
> tangents is the point rather than an impedement.  Fortunately, Sandia is
> close enough to that that I don't get into any trouble here if I take my
> time.
>
> Since there are such tools as these filter designers (TI also has
> automagic analog filter designer programs too, enabling someone who
> hasn't ever cracked a circuit analysis text to produce the same results
> by pointing and clicking that I could produce after considerable effort
> by working from scratch), I begin to wonder if the theoretical based
> engineers are in the minority even in production environments like
> industry?  In other words, does it further your career more to quickly
> produce results that work but you don't know why, vs. studying to
> develop the ability to know why things work, and to eventually make a
> few things which really exercise that understanding?  Things which
> couldn't be done by "cookbook engineering."
>
> One final anecdote:  A few years ago I did a simulation of the basic
> lock-in or synchronous demodulation amplifier, in Mathematica (because I
> didn't know SPICE very well yet then.)  I learned a great deal with
> this.  It started out by just asking myself one day "how does a lock-in
> work?"  I have not yet applied that learning to building a lock-in, but
> I know one day I may.
>
> A co-worker spent almost 3 years taking a complicated system containing
> two SRS lock-ins and other commercial electronic instruments, and
> reducing it's size for portability by building all the electronics on
> custom PCBs in a custom chassis.  When he finally got to testing the
> customized lock-in, one day he was puzzled as to why the output signal
> amplitude was varying all over the place as he adjusted the phase knob.
>   He asked me if I had any idea what was wrong?
>
> I pulled out my notebook from when I had looked at the basic operating
> equations of a lock-in, which said of course that the output amplitude
> varies with the cosine of the phase difference.
>
> The fellow did a fine job considering his lack of theoretical
> understanding, it is important to note.  But I couldn't help but to
> wonder how wise it was to have someone build the thing who didn't
> understand the very basic theory of the system they were building?  Yet
> he produced a result that met the goals.
>
> Is this way of doing things common?
>
>
> Thanks for comments.
>
>
> Good day!
>
>
> -- 
> ____________________________________
> Christopher R. Carlen
> Principal Laser/Optical Technologist
> Sandia National Laboratories CA USA
> crcarle@sandia.gov
>

Chris Carlen wrote:

> Greetings:
> 
> I have begun to learn the subject of DSP, which started out with 
> implementing a working 100-tap FIR filter in an AVR a few weeks ago. 
> This is a subject that I find fascinating, particularly the applied 
> mathematics aspect.  But also the hardware aspect, as there is something 
> very satisfying about constructing a real machine that actualizes a 
> mathematical concept.

   ...

You can approach most subjects from many directions, and explore them at
various depths. Good DSP tools can relieve you of much of the detail
needed to design the parts of a system, but there are no tools I know of
that can design the system. An infantryman isn't better suited to his
role for having acquired the skills of a gunsmith, but someone needs to
build the rifle, and someone (usually someone else) has to design it.

In the early days of television, every repair shop needed at least one
person who understood how TV works and what the scope trace looks like
when it didn't. That person was the "bench technician"; he could support
a number of "tube jockeys", people who tried swapping the obvious tubes
and when that didn't work, declared that the set had to "go back to the
shop", i.e. be tended to by someone competent. Many good bench
technicians had once been tube jockeys. You can probably start your DSP
career as the modern equivalent of one, but you will want to go on from
there.

Not every amateur is a theoretical ignoramus. I would be quite
apprehensive if circumstances made it necessary for a drill sergeant to
remove my appendix. With no physician available, I'd more happily settle
for a pharmacist's mate. It is said that an amateur is one who hasn't
yet made all the mistakes, while a pro has, and knows how to fix them. A
greenhorn doesn't even know what the mistakes are.

Read a good book.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Fred Marshall wrote:

> Voltaire and Soviet Admiral Gorshkov are both credited with saying something
> like:
> "Better is the enemy of good enough".  I love to suggest that to engineers!

I've seen a lot of ugly engineering that I thought I could do better. 
Having too much time available means you can do that, sacrificing the 
good to the perfect.

> The key is in "good enough".  The danger is in not knowing or considering
> the worst case.

Simpler is better. Less things to surprise you.

-- 
Scott

**********************************

DIY Piezo-Gyro, PCB Drill Bot & More Soon!

http://home.comcast.net/~scottxs/

**********************************

Chris Carlen wrote:

> The tools even 
> give you the friggin' code!
...
> Why then should one study the theory and learn how to calculate filter 
> coefficients by hand?  (Or by one's own custom program, as I just did 
> with Mathematica for my first FIR.)
> 
> I know of course, that by understanding the theory, one can apply
> insight into problems that will stump another without the theoretical
> grounding.  Also, one can produce higher-performing, customized,
> hand-tooled solutions rather than just piecing together the canned
> "modules"

You left out performance. Do you know how they are implementing the 
code? Have you ever tried Micro$oft example code, such as from their 
javascript and winscript documents? It has subtle mistakes. Perhaps to 
trip up script-kiddies?

> This has me a a little bit concerned.  I could spend a few months 
> designing a system, by exercising all my theoretical knowledge.  But 
> this essentially amounts to reinventing the wheel,

Aren't you getting paid by the feds? If I were you, I would milk it for 
all I could. I was a gentleman and a scholar once. You deserve a good 
hazing like I got.

> In other words, does it further your career more to quickly 
> produce results that work but you don't know why, vs. studying to 
> develop the ability to know why things work, and to eventually make a 
> few things which really exercise that understanding?  Things which 
> couldn't be done by "cookbook engineering."

Ask God - you don't know what you'll need to know tomorrow, or what will 
pop out of the jungle to bite your ass. The people that really get ahead 
are those that know how to get the scholars to serve them. And know how 
to usurp the boss' authority and job.

Do you want to amuse yourself with gadgets or run your department, then 
the DOE?

-- 
Scott

**********************************

DIY Piezo-Gyro, PCB Drill Bot & More Soon!

http://home.comcast.net/~scottxs/

**********************************

A short answer to a long question:

Yes!

If you don't understand what you're doing, you will end up with a bunch of
toy solutions that don't really work well. I haven't seen a tool yet that
can replace expert knowledge of filter design, fixed point math, real-time
embedded programming, etc. MATLAB has a good core engine for doing DSP, but
automatic tools I've seen are far below acceptable performance for
industrial level applications. They are mostly good for students of DSP to
learn the concepts and visualize how algorithms work and behave. They are
also good for experts since they know how to really use them and interpret
the results.

Once you have to do DSP for real, i.e. in real-time, low MIPS, low memory,
optimal performance, good quantization properties, SNR, dynamic range, etc.,
tools are handy, but will not give you good results unless you have very
good theoretical understanding of all of the above concepts (including
software engineering for more complex applications).

Based on the area of application, one may need to be rather good (theory and
practice) in at least three fields:

1. DSP
2. Software engineering (or computer architectures in case of ASIC's)
3. Core scientific discipline determined by the application (e.g.
communications, bioengineering, physics, or some other)

Most people are good in one of the above, sometimes in two, rarely in all
three. Hence, it is very hard to find engineers/scientists that can really
deal with DSP problems in efficient and reliable way... I would rather have
one engineer that is good in all three areas, than three that are experts in
each one of the fields. It's not just that you would pay such a person only
2/3 of the combined three experts, but he or she would perform twice as good
as all three combined. ;-)

Regards,
Bogdan

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c27t320mkm@enews1.newsguy.com...
> Greetings:
>
> I have begun to learn the subject of DSP, which started out with
> implementing a working 100-tap FIR filter in an AVR a few weeks ago.
> This is a subject that I find fascinating, particularly the applied
> mathematics aspect.  But also the hardware aspect, as there is something
> very satisfying about constructing a real machine that actualizes a
> mathematical concept.
>
> I am planning a rigorous study of the theory of DSP, by working through
> the Lyons text, and hopefully having time for some looks at Hamming's
> "Digital Filters" text and some other texts on implementing
> transcendental functions on computing hardware, app notes, etc.  I may
> take a formal class as well.
>
> In addition, I will be attending a series of workshops by TI as well as
> Analog Devices in the next few months to familiarize myself with the
> TMS320* and particulary the F2812 DSPs, and the ADI 219x and SHARC DSPs.
>   I will hopefully begin experimenting with applying the DSP concepts to
> the evaluation kits I obtain before the end of the year.
>
> Probably my first goal will be the DSP equivalent of the typical first
> microcontroller program:  instead of a blinking LED, I'd like to manage
> to sample data with an A/D, and spit it right back out to a DAC.  If I
> can get that far, it's a piece of cake to start adding computational
> activity in between.
>
> But what I am getting at is this:  I have recently become aware of the
> existence of a large selection of software tools for developing DSP
> systems, which essentially make it possible for an engineer or even a
> technologist with minimal theoretical understanding of the mathematical
> guts of DSP algorithms, to produce working digital filters and other
> goodies with easy to use point-and-click interfaces.  The tools even
> give you the friggin' code!
>
> Why then should one study the theory and learn how to calculate filter
> coefficients by hand?  (Or by one's own custom program, as I just did
> with Mathematica for my first FIR.)
>
> I know of course, that by understanding the theory, one can apply
> insight into problems that will stump another without the theoretical
> grounding.  Also, one can produce higher-performing, customized,
> hand-tooled solutions rather than just piecing together the canned
> "modules" of functionality provided by the programs and tools that do
> the thinking for you.  Finally, there is the intellectual pleasure, for
> those who like that.
>
> This seems to be rare though, as most folks would rather just produce a
> result.  My being the former way is why I'm in the field of fundamental
> research rather than the product industry.  But this doesn't make me a
> champion of productivity.
>
> This has me a a little bit concerned.  I could spend a few months
> designing a system, by exercising all my theoretical knowledge.  But
> this essentially amounts to reinventing the wheel, if the tools are
> available to do it for me, and there is no need for a highly optimized
> solution.  Meanwhile the guy down the hall produces a result in two
> weeks, and tells his boss "look I make a custom DSP digital filtering
> machine" when he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if
> someone like myself who really *wants* to start from scratch just
> belongs in academia or someplace where getting off on intellectual
> tangents is the point rather than an impedement.  Fortunately, Sandia is
> close enough to that that I don't get into any trouble here if I take my
> time.
>
> Since there are such tools as these filter designers (TI also has
> automagic analog filter designer programs too, enabling someone who
> hasn't ever cracked a circuit analysis text to produce the same results
> by pointing and clicking that I could produce after considerable effort
> by working from scratch), I begin to wonder if the theoretical based
> engineers are in the minority even in production environments like
> industry?  In other words, does it further your career more to quickly
> produce results that work but you don't know why, vs. studying to
> develop the ability to know why things work, and to eventually make a
> few things which really exercise that understanding?  Things which
> couldn't be done by "cookbook engineering."
>
> One final anecdote:  A few years ago I did a simulation of the basic
> lock-in or synchronous demodulation amplifier, in Mathematica (because I
> didn't know SPICE very well yet then.)  I learned a great deal with
> this.  It started out by just asking myself one day "how does a lock-in
> work?"  I have not yet applied that learning to building a lock-in, but
> I know one day I may.
>
> A co-worker spent almost 3 years taking a complicated system containing
> two SRS lock-ins and other commercial electronic instruments, and
> reducing it's size for portability by building all the electronics on
> custom PCBs in a custom chassis.  When he finally got to testing the
> customized lock-in, one day he was puzzled as to why the output signal
> amplitude was varying all over the place as he adjusted the phase knob.
>   He asked me if I had any idea what was wrong?
>
> I pulled out my notebook from when I had looked at the basic operating
> equations of a lock-in, which said of course that the output amplitude
> varies with the cosine of the phase difference.
>
> The fellow did a fine job considering his lack of theoretical
> understanding, it is important to note.  But I couldn't help but to
> wonder how wise it was to have someone build the thing who didn't
> understand the very basic theory of the system they were building?  Yet
> he produced a result that met the goals.
>
> Is this way of doing things common?
>
>
> Thanks for comments.
>
>
> Good day!
>
>
> -- 
> ____________________________________
> Christopher R. Carlen
> Principal Laser/Optical Technologist
> Sandia National Laboratories CA USA
> crcarle@sandia.gov
>