Question about DSP in Matlab (beginner)

On Sat, 23 May 2015 12:10:22 -0500, "JCO_DSP" <105989@DSPRelated>
wrote:

>Hi,
>
>I'm starting to learn DSP (Matlab )and I have two questions about it,
>maybe someone can help me out?
>
>I'm trying to measure a frequency from an Audio Device and I'm using FFT
>to transform it from the time domain to the frequency domain. But I am
>doing a downsample before the FFT. But you can also do it after the FFT.
>Do you know what would be the most efficient (before or after)? And why?

What do you mean by "efficient"?   If you mean efficient in a
complexity sense, then it is usually best to try to keep the FFT small
since it is often the most complex operation in that sort of process.
If you mean "efficient" in the sense of getting the most out of the
signal, then that's a different question.

If you downsample before the FFT you need to make sure that you're not
creating any aliasing artifacts.    This is usually done by low-pass
filtering at the same time of downsampling.   If your *know* there is
no energy in the spectrum above the new, downsampled sample rate, then
there's no need to filter, but that's usually hard to guarantee unless
the signal is synthetically generated.

Regardless, downsampling before the FFT will allow the use of a
smaller FFT, which will reduce the computational or implementation
complexity of the process.

If you're trying to reduce the bin spacing of the FFT to get more
resolution on the output spectrum, then performing the FFT at the
LOWER sample rate will achieve that.   So if that's what you mean by
efficiency, then definitely decrease the sample rate before the FFT.

>Another question, I am using zero padding to increase my system resolution
>(up to 50Hz). My frame length is N=256 and sample frequency fs= 44100 Hz.
>So 44100/50 = 882, so I need to add 626 zeroes (to 256 frame length) to
>get 50 Hz resolution, I hope this is correct? I believe this is done for
>FFT. But is this the same for the DFT?

An FFT is just an efficient way to compute a DFT with power-of-two
lengths.   The output will be exactly the same regardless of whether
you use a DFT or FFT.   The Matlab "fft" routine doesn't always do an
FFT, because it will accept a vector of any length at the input, and
it chooses among a variety of algorithms to compute the equivalent of
the DFT.    Whatever it does will be equivalent to computing a DFT, it
just may get there via a different, shorter, route.

Be very careful about what you mean by "resolution" when it comes to
zero padding.   I'm not quite sure what you mean by "resolution" in
this case, either.   I'm also not sure what you mean by frame length,
or how you want an FFT of length of 882.

If by "resolution" you mean the bin spacing on the FFT, that's just
fs/N, and you've correctly set N at 882 for your sample rate.
However, the way most people use the term "resolution" in this context
does not equate to the bin spacing, but to the ability to "resolve"
details in the DFT output, and is often defined as the 3dB width of
the DFT of the window function.   In your case the window function is
the DFT of a rectangle of length 256, not 882, since the rest is
zeros.    So you cannot get the "resolution" of an 882-point DFT with
only 256 input samples.   You can get a 50-Hz bin spacing, but the
output of the 882-pt DFT will be the equivalent of interpolating the
output of a 256-pt DFT.   The "resolution" will not be increased, just
the number of samples in the DFT output.

To get a true DFT "resolution" of 50Hz, you either need an input
vector with 886 data samples (i.e., not zero padded), or decrease the
sample rate via downsampling to 50*256 = 12.8 kHz and use a 256-pt
DFT.    If there is any signal energy above 6.4 kHz that has to be
filtered out, and this may result in some loss of information about
the signal of interest.   Sometimes there's no free lunch. 

The decimation rate needed to reduce from 44.1kHz to 12.8kHz is
44.1/12.8 = 3.44, which is not an integer downsample rate.   This can
be done with a multi-rate filter, which is a little trickier to do,
but there are Matlab routines that will do this for you. 

Matlab is a fine tool for learning DSP, but it's kinda like learning
to swim in the deep end of the pool.   If you don't know what's going
on inside the routines, or what they actually do, there are many
potential pitfalls.  Doing stuff like what you're doing can be a good
way to learn the routines, though, and many of them are very powerful
tools.

>Thank you and regards,
>
>
>
>---------------------------------------
>Posted through http://www.DSPRelated.com

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

[...snip...]

>If you teach DSP using Matlab as a learning tool, it should work.

This alludes to what I am about to say.

[...snip...]

>
>But Tim is right that you do have to understand what you are doing.
>

This I disagree with strongly and is in direct opposition to the notion of
exploring.

>
>If you understand what the tool is doing, it is a great way to learn.
>
>If you want a magic box, where you don't have to do any thinking,
>just put in numbers and get results, it isn't.
>
>So, for the "tool to use after you understand the math", it could
>be an hour or a day after you understand, but it isn't a substitute
>for the understanding.
>
>-- glen

When talking about numerical patterns, there are really two levels of
understanding:  behavioral and mathematical.

Having a behavioral understanding makes learning the mathematical
understanding easier.  Having a mathematical understanding allows a
behavioral understanding to be inferred.

Playing with a tool, observing its behavior, can lead to a behavioral
understanding.  This may be sufficient motivation to seek a mathematical
understanding.  Trying to teach the mathematical understanding without
presenting at least a little of the behavioral understanding leads to the
perennial questions asked by students:  "What is this good for?" or "When
am I ever going to need this?"

Take "leakage", for example.  Most of you would claim to understand
leakage.  If you truly understood leakage, you wouldn't call it leakage
and you wouldn't prattle on about an "uncertainty principle" in the DFT. 
Unless you can derive the equations in my blog article titled "DFT Bin
Value Formulas for Pure Real Tones" (at dsprelated dot com), you don't
understand leakage mathematically.  Sorry, you don't.

So, I say, even if you don't understand what the tool is doing, it is a
great way to learn.  A behavioral understanding can still get you a long
way.

Ced

---------------------------------------
Posted through http://www.DSPRelated.com

Cedron <103185@DSPRelated> wrote:

>When talking about numerical patterns, there are really two levels of
>understanding:  behavioral and mathematical.
>
>Having a behavioral understanding makes learning the mathematical
>understanding easier.  Having a mathematical understanding allows a
>behavioral understanding to be inferred.
>
>Playing with a tool, observing its behavior, can lead to a behavioral
>understanding.  This may be sufficient motivation to seek a mathematical
>understanding.  Trying to teach the mathematical understanding without
>presenting at least a little of the behavioral understanding leads to the
>perennial questions asked by students:  "What is this good for?" or "When
>am I ever going to need this?"

>Take "leakage", for example.  Most of you would claim to understand
>leakage.  If you truly understood leakage, you wouldn't call it leakage
>and you wouldn't prattle on about an "uncertainty principle" in the DFT. 
>Unless you can derive the equations in my blog article titled "DFT Bin
>Value Formulas for Pure Real Tones" (at dsprelated dot com), you don't
>understand leakage mathematically.  Sorry, you don't.

I suspect some professor or textbook somewhere introduced the
expression "uncertainty principle" to describe the frequency characteristics
of time-limited signals, and vice-versa, because this keeps popping up
in conversation.

Perhaps the same is true for "leakage".   I thought capacitors had
leakage, not transforms.  (Although maybe, transformers.)


Steve

[...snip...]
>
>Yes, and most people who claim this can kick most other folks' ass when
>it
>comes to hard work (my father included). 
>

I won't argue that, but it is still not a necessary prerequisite. 
Sometimes slogging is productive, sometimes it is just digging holes and
filling them in.

>> Assuming what worked for you is what would work best for someone else
>> is a bit tenuous in my opinion.
>
>It's not "what worked for me" - it's what can't possibly work. 
>
Not sure what you mean by this.

>> [...]
>> Whether this is best done with paper and pencil or with a computer,
>I'm
>> not going to commit to.
>
>"A computer is an amplifier for the mind."
>
>How many computers have submitted papers to the IEEE or made
>presentations at the AES conventions? 
>
>I fail to understand why this concept is difficult to grasp. 
>-- 
>Randy Yates
>Digital Signal Labs
>http://www.digitalsignallabs.com

Straw man argument.  The issue is not whether a human or a computer can do
a better job at something, the issue is whether computer software or
pencil and paper figuring is the better learning method.  I believe this
is personality and subject matter dependent.

Ced
---------------------------------------
Posted through http://www.DSPRelated.com

On 5/25/15 1:16 PM, Steve Pope wrote:
> "kaz"<37480@DSPRelated>  writes:
>
>> Without programming our little
>> brains can hardly have got anywhere. Matlab or any such tools are very
>> intuitive, far more than any books or fora clutter and impulsive partial
>> replies. It looks like we get dsp insight using tools then claim we know
>> it by heart and don't want others to learn the way we did. Matlab is
>> designed by many experts in their fields, refined and tested over years.
>> DSP is the product of tools refined or messed up by human statements.
>
> This, um, ignores the decades of DSP research that preceded the introduction
> of MATLAB.  Which, by the way, was not actually aimed at DSP in
> particular,

yeah, but a decade ago, the *only* other product sold by TMW besides 
MATLAB was the Signal Processing Toolbox (other toolboxes came shortly 
after).  i think its niche with DSP was quite apparent despite (sadly) 
the stupid hard-wired indexing origin.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Sun, 24 May 2015 07:47:47 -0500, "Cedron" <103185@DSPRelated>
wrote:

>[...snip...]
>
>>>As long as the frequencies are below the Nyquist limit, you do not get
>>>any better frequency resolution, meaning being able to discern
>>(resolve)
>>two
>>>different tones, by increasing the number of samples.
>>>
>>
>>On this one, I have been scratching me head since last night.
>>Doesn't everybody say fft frequency resolution = Fs/N (= bin width)???
>>Or
>>is your concept of resolution something else?
>>
>>That is what I meant by accuracy, may be not best wording but should be
>>ok
>>for a practical DSP beginner.
>>
>>
>>Kaz
>>
>>
>>---------------------------------------
>>Posted through http://www.DSPRelated.com
>
>I am more of a Mathematician and a Scientist than an Engineer, so I
>apologize if my terminology isn't what you are used to.  This is why I
>tried to explain what I meant with examples.
>
>There are three words that are often used synonymously which actually have
>distinct technical meanings.  They are "resolution", "accuracy", and
>"precision".
>
>I use resolution from its root meaning being "to resolve", as in this
>sentence I found on the net:
>
>"The resolution of an optical microscope is defined as the shortest
>distance between two points on a specimen that can still be distinguished
>as separate entities."
>
>If I have a thermometer that can measure to the nearest thousandth of a
>degree, but is off by five degrees (miscalibrated), it is precise, but not
>accurate.
>
>If I have a thermometer that reads the correct temperature, but I can only
>measure to the nearest degree, it is accurate, but not precise.
>
>I was using the term "accuracy" in the vernacular to mean both accurate
>and precise.
>
>In mathematics, "exact" means accurate with infinite precision.  In
>engineering, "exact" means matching in value to the limit of the
>measurement resolution.
>
>When I say my frequency formula is exact, I mean in the mathematical way.
>
>In the time domain, "sampling density" and "sampling rate" mean the same
>thing.  Fourier series are not limited to only time series data.
>
>Let me explain why increasing the number of samples within an interval
>does not increase the frequency precision.  Suppose you have a 60 +/- 3 Hz
>clean pure signal measured in a tenth of a second time frame at the CD
>quality rate of 44100 samples per second.  Now starting at time zero, you
>take your first sample, then take nine more every hundredth of second
>(441) samples.  You do a ten sample DFT and calculate the frequency and
>get an exact answer.  Instead, if you use every sample point, and do a
>44100 bin DFT, and calculate the frequency, you will still get an exact
>answer.  The two answers will be the same, no improvement.  In both DFTs,
>the peak value will be at bin six.

The usual definition of DFT "resolution" is the ability to resolve two
closely-spaced tones, and the usual definition of that is that their
3dB point can be be resolved.   This boils down to the resolution
being the 3dB width of the DFT data window.    Zero padding does not
increase the length of the data observation window, just the DFT
length.

One way this is often stated is that higher frequency resolution
requires a longer observation time.   This is consistent with the FT
uncertainty principle.   Because you've kept the length of the
observation time the same in both cases, the "resolution" won't
change.    Since there are six cycles of the 60Hz tone within the
length of the window, any DFT length fitted to the window by
increasing the sample rate will have the peak at bin 6.

>One final thing, just because everybody says so, doesn't necessarily make
>it true.

And if only one guy is wrong, he's still wrong.

>Hope this helps.
>
>Ced
>---------------------------------------
>Posted through http://www.DSPRelated.com

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

On Mon, 25 May 2015 14:36:41 -0400, robert bristow-johnson
<rbj@audioimagination.com> wrote:

>On 5/25/15 1:16 PM, Steve Pope wrote:
>> "kaz"<37480@DSPRelated>  writes:
>>
>>> Without programming our little
>>> brains can hardly have got anywhere. Matlab or any such tools are very
>>> intuitive, far more than any books or fora clutter and impulsive partial
>>> replies. It looks like we get dsp insight using tools then claim we know
>>> it by heart and don't want others to learn the way we did. Matlab is
>>> designed by many experts in their fields, refined and tested over years.
>>> DSP is the product of tools refined or messed up by human statements.
>>
>> This, um, ignores the decades of DSP research that preceded the introduction
>> of MATLAB.  Which, by the way, was not actually aimed at DSP in
>> particular,
>
>yeah, but a decade ago, the *only* other product sold by TMW besides 
>MATLAB was the Signal Processing Toolbox (other toolboxes came shortly 
>after).  i think its niche with DSP was quite apparent despite (sadly) 
>the stupid hard-wired indexing origin.

It's been a hell of a lot longer than a decade.  

>
>-- 
>
>r b-j                  rbj@audioimagination.com
>
>"Imagination is more important than knowledge."
>
>

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

On 5/25/15 2:23 PM, Steve Pope wrote:
>

>
> Perhaps the same is true for "leakage".   I thought capacitors had
> leakage, not transforms.  (Although maybe, transformers.)


just the transforms of windows have (or cause) leakage.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On 5/25/15 2:39 PM, Eric Jacobsen wrote:
> On Mon, 25 May 2015 14:36:41 -0400, robert bristow-johnson
> <rbj@audioimagination.com>  wrote:
>
>> On 5/25/15 1:16 PM, Steve Pope wrote:
>>> "kaz"<37480@DSPRelated>   writes:
>>>
>>>> Without programming our little
>>>> brains can hardly have got anywhere. Matlab or any such tools are very
>>>> intuitive, far more than any books or fora clutter and impulsive partial
>>>> replies. It looks like we get dsp insight using tools then claim we know
>>>> it by heart and don't want others to learn the way we did. Matlab is
>>>> designed by many experts in their fields, refined and tested over years.
>>>> DSP is the product of tools refined or messed up by human statements.
>>>
>>> This, um, ignores the decades of DSP research that preceded the introduction
>>> of MATLAB.  Which, by the way, was not actually aimed at DSP in
>>> particular,
>>
>> yeah, but a decade ago, the *only* other product sold by TMW besides
>> MATLAB was the Signal Processing Toolbox (other toolboxes came shortly
>> after).  i think its niche with DSP was quite apparent despite (sadly)
>> the stupid hard-wired indexing origin.
>
> It's been a hell of a lot longer than a decade.
>

yeah, i was thinking two.  (1995).

neural misfiring going on here.

i remember Loren Shure and Thomas Krause were the authors.  i actually 
had a short face chat with the former and an email chat with the latter 
and the two have very different spins on the 1-origin complaint.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Mon, 25 May 2015 13:10:52 -0500, "Cedron" <103185@DSPRelated>
wrote:

>[...snip...]
>
>>If you teach DSP using Matlab as a learning tool, it should work.
>
>This alludes to what I am about to say.
>
>[...snip...]
>
>>
>>But Tim is right that you do have to understand what you are doing.
>>
>
>This I disagree with strongly and is in direct opposition to the notion of
>exploring.
>
>>
>>If you understand what the tool is doing, it is a great way to learn.
>>
>>If you want a magic box, where you don't have to do any thinking,
>>just put in numbers and get results, it isn't.
>>
>>So, for the "tool to use after you understand the math", it could
>>be an hour or a day after you understand, but it isn't a substitute
>>for the understanding.
>>
>>-- glen
>
>When talking about numerical patterns, there are really two levels of
>understanding:  behavioral and mathematical.
>
>Having a behavioral understanding makes learning the mathematical
>understanding easier.  Having a mathematical understanding allows a
>behavioral understanding to be inferred.
>
>Playing with a tool, observing its behavior, can lead to a behavioral
>understanding.  This may be sufficient motivation to seek a mathematical
>understanding.  Trying to teach the mathematical understanding without
>presenting at least a little of the behavioral understanding leads to the
>perennial questions asked by students:  "What is this good for?" or "When
>am I ever going to need this?"
>
>Take "leakage", for example.  Most of you would claim to understand
>leakage.  If you truly understood leakage, you wouldn't call it leakage
>and you wouldn't prattle on about an "uncertainty principle" in the DFT. 
>Unless you can derive the equations in my blog article titled "DFT Bin
>Value Formulas for Pure Real Tones" (at dsprelated dot com), you don't
>understand leakage mathematically.  Sorry, you don't.

I don't think using a particular word to communicate something doesn't
have any indication about how well one might or might not understand a
topic.   Your examples are good cases in point.   I think most people
that I've worked with, and the vast majority of people who've been
contributors to comp.dsp, use the term "leakage" because everybody
knows what they mean by it.   It doesn't mean that they think
something is "leaking" out of something else, it's just how it's
described.

Likewise for the uncertainty principle.   It's the same for most cases
where there is an "uncertainty principle".   It's really just a way to
describe a limitation in the math, and many people understand this.

Semantics is a big problem in many industries, and also in DSP.
There are a lot of overloaded terms and a lot of terms, like
"leakage", that people know what they mean despite it being an
imperfect word for the concept.

If you think everyone who uses those terms doesn't understand the
underlying principles you're wrong.   Sorry, you just are.

Repeating:
>Unless you can derive the equations in my blog article titled "DFT Bin
>Value Formulas for Pure Real Tones" (at dsprelated dot com), you don't
>understand leakage mathematically.  Sorry, you don't.

I think that's an incredibly arrogant statement.

And, btw, other people have done derivations to the same purpose as
your article and come up with cleaner results.

>So, I say, even if you don't understand what the tool is doing, it is a
>great way to learn.  A behavioral understanding can still get you a long
>way.
>
>Ced
>
>---------------------------------------
>Posted through http://www.DSPRelated.com

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com