Ikaro  <ikarosilva@hotmail.com> wrote:

>> Well, this is one interesting thing -- your ability to accurately
>> resolve frequency components is of course dependent on the input
>> length, but you can compute a PSD value at any frequency you like (up
>> to Fs/2), and all such values are meaningful.

>Yes, but ultimately the number of independent points will be related
>to the size of you input signal.
>What I am trying to say (correct me if I am wrong) is that you are
>sampling in the frequency domain, but there is also some sort of
>interpolation
>going on (similar to zero padding). So that even though you can
>evaluate the PSD at any point in the spectra, some of the points will
>be dependent (ie, a function of the neighboring points).

Sure; a PSD curve is almost by definition smooth-looking,
therefore its value is dependent on nearby values.

>> Good point. &#4294967295;Maybe filtered white noise is a better input
>> for calibration. &#4294967295;
>
>Indeed that is a better approach. However, keep in mind that the
>estimated PSD is a function of every point of the windowed PSD and the
>signals PSD. I think that the best approach is to deconvolve the
>estimated PSD with the window's PSD. If the window's PSD has closed
>analytical form, than the solution might even be good (this is similar
>to an image deblurring problem).

>As a starting point, you could  do a Monte-Carlo to get  the average
>spectra the estimated PSD deconvolved with the window's PSD. The best
>deconvolving function is the one the returns the flatest spectra on
>the Monte-Carlo simulation...

>But again, my guess is that this estimate will yield higher
>variability than the original estimated PSD.
>
>
>> I don't think the window introduces a bias, in the usual sense. &#4294967295;
>> It does have certain characeteristics, but any spectral density
>> calculation must have such characteristics. &#4294967295;It's one of these
>> "goes with the territory" things.
>
>Sorry for the confusion, by bias I do not mean a DC component but that
>on average the estimated PSD will be off from the true PSD.

Can you define "true PSD".   I think you need a window
to define any PSD.

>The method you mentioned is the Blackman-Tukey method for PSD
>estimation, and it known for being asympotically unbiased (ie, only
>unbiased as the number of points in the ACF go to infinity).

Thanks.  It's the only PSD method I have used....

Steve

> Well, this is one interesting thing -- your ability to accurately
> resolve frequency components is of course dependent on the input
> length, but you can compute a PSD value at any frequency you like (up
> to Fs/2), and all such values are meaningful.

Yes, but ultimately the number of independent points will be related
to the size of you input signal.
What I am trying to say (correct me if I am wrong) is that you are
sampling in the frequency domain, but there is also some sort of
interpolation
going on (similar to zero padding). So that even though you can
evaluate the PSD at any point in the spectra, some of the points will
be dependent (ie, a function of the neighboring points).


> Good point. �Maybe filtered white noise is a better input
> for calibration. �

Indeed that is a better approach. However, keep in mind that the
estimated PSD is a function of every point of the windowed PSD and the
signals PSD. I think that the best approach is to deconvolve the
estimated PSD with the window's PSD. If the window's PSD has closed
analytical form, than the solution might even be good (this is similar
to an image deblurring problem).

As a starting point, you could  do a Monte-Carlo to get  the average
spectra the estimated PSD deconvolved with the window's PSD. The best
deconvolving function is the one the returns the flatest spectra on
the Monte-Carlo simulation...

But again, my guess is that this estimate will yield higher
variability than the original estimated PSD.


> I don't think the window introduces a bias, in the usual sense. �
> It does have certain characeteristics, but any spectral density
> calculation must have such characteristics. �It's one of these
> "goes with the territory" things.

Sorry for the confusion, by bias I do not mean a DC component but that
on average the estimated PSD will be off from the true PSD.
The method you mentioned is the Blackman-Tukey method for PSD
estimation, and it known for being asympotically unbiased (ie, only
unbiased as the number of points in the ACF go to infinity).

Ikaro  <ikarosilva@hotmail.com> wrote:

>Hope you don't mind me jumping in... just have some curious questions

Certainly!

>> If the latter, or if freqz() is not adequate, you really want to
>> do a real PSD calculation: window the data; compute the autocorrelation
>> function; window the autocorrelation function, then perform a
>> cosine transform on it. &#4294967295;This gives you the PSD. &#4294967295;The power within a
>> range of frequencies is proportional to the PSD summed over those
>> frequencies.

>A cosine tranform because the ACF is real and even ?

Correct.

>> Note that, unlike an FFT, the number of points in this transform
>> can be whatever you like and it is not related to the size of the
>> initial dataset or even the length of the autocorrelation window.

>But the resolution, as  you later point out,  is direclty related to
>the input size, so its seems like the number of independent points in
>the transform is related to the input size.

Well, this is one interesting thing -- your ability to accurately 
resolve frequency components is of course dependent on the input 
length, but you can compute a PSD value at any frequency you like (up 
to Fs/2), and all such values are meaningful.

>> You will still have to calibrate the result with a scale
>> factor. &#4294967295;Once you have a PSD function created, feed sinusoids
>> of known power into it to determine the scale factor needed.

>I am not sure this will work. Because sinusoids will result in
>impulses in the PSD. However, the estimated PSD is related to the
>convolution of the PSD of the input signal and the PSD of the window
>(multiplication in time domain). Using a sinusoid will be accurate
>only for inputs whose spectral components are sufficiently small and
>far apart such that when they are convolved (blurred) with the
>window's PSD their "bleeding" (or cross band inteference) effect
>becomes negligible.

Good point.  Maybe filtered white noise is a better input
for calibration.  

>I wonder if there might be a way to *deconvolve* the estimated PSD
>given the window's PSD...my guess is that this in the end will yield a
>higher variance estimate, at the cost of an unbiased PSD estimation...

I don't think the window introduces a bias, in the usual sense.  
It does have certain characeteristics, but any spectral density 
calculation must have such characteristics.  It's one of these 
"goes with the territory" things.

I like using a Nuttall window, due to the excellent stopband.

Steve

Hope you don't mind me jumping in... just have some curious questions

> If the latter, or if freqz() is not adequate, you really want to
> do a real PSD calculation: window the data; compute the autocorrelation
> function; window the autocorrelation function, then perform a
> cosine transform on it. �This gives you the PSD. �The power within a
> range of frequencies is proportional to the PSD summed over those
> frequencies.

A cosine tranform because the ACF is real and even ?


> Note that, unlike an FFT, the number of points in this transform
> can be whatever you like and it is not related to the size of the
> initial dataset or even the length of the autocorrelation window.

But the resolution, as  you later point out,  is direclty related to
the input size, so its seems like the number of independent points in
the transform is related to the input size.


> You will still have to calibrate the result with a scale
> factor. �Once you have a PSD function created, feed sinusoids
> of known power into it to determine the scale factor needed.

I am not sure this will work. Because sinusoids will result in
impulses in the PSD. However, the estimated PSD is related to the
convolution of the PSD of the input signal and the PSD of the window
(multiplication in time domain). Using a sinusoid will be accurate
only for inputs whose spectral components are sufficiently small and
far apart such that when they are convolved (blurred) with the
window's PSD their "bleeding" (or cross band inteference) effect
becomes negligible.


I wonder if there might be a way to *deconvolve* the estimated PSD
given the window's PSD...my guess is that this in the end will yield a
higher variance estimate, at the cost of an unbiased PSD estimation...

lucapp <pascale.luca.it@gmail.com> wrote:

>I have a signal from a digital receiver in form of IQ samples.

>Next day I investigate about this method but.....

>the proportionality factor is not exactly the same problem that I have if
>use the FFT? So.. what is the difference into use FFT or PSD (excluding the
>goodness of the power estimation)??
>Thanks Luca

This is an important question.

The PSD is an estimation function, which takes as its input a signal 
which is a time-series of any length, and provides an estimate of how 
much power is at any frequency or within a given frequency range.  
It however does not preserve all the information in the signal.
It just gives you a spectral estimate.

Whereas the DFT (of which the FFT is a computational example) is a 
transform of a fixed-length signal.  The transformed values
are dimensionally frequencies, and correspond to frequency points,
but they are not an estimate of anything.  It does however preserve
the information in the signal, which is why it's a transform
and not an estimate.

So suppose you have a 64-point FFT whose values are at 0, 1, 2 ... 63
MHz.  The magnitude of the value at 2 MHz sort-of corresponds to
the amount of signal at 2 MHz, however the FFT is not really
designed to measure this: it is designed to give an exact,
reversible, information-preserving transform.  Signal components
at other frequencies will "bleed" into the bin at 2 MHz. Whereas the 
PSD is designed from the outset to measure the amount of signal
at each of its frequency points, and you can select the underlying
window/estimation functions to give you the desired selectivity.

Furthermore, in the above example, it is meaningless to talk
about the FFT value at 2.1 MHZ -- there are not that many points --
but the PSD can be computed at any value, over a continuum of
frequencies.  Its effective resolution is inversely related to the
length of the input, and its selectivity is determined by the
windows you use, but its value is defined for all frequencies
up to Nyquist.

So the short form answer is, the DFT / FFT is not a spectrum analyzer,
although many people treat it as though it is, and under 
some conditions and in some respects it pretty much behaves like one.

Hope this helps.

Steve

>lucapp <pascale.luca.it@gmail.com> wrote:
>
>>>Your problem as stated may not have any reasonable solution.
>>>An FFT is a transform, not a power measurement.  If you want
>>>to measure power within a frequency band, compute the power
>>>spectral density instead.
>
>>>Steve
>
>>Thanks Steve for your reply.
>>I have a clarification to do:
>>
>>I have the IQ samples of a portion of air spectrum with band B.
>>I want to compute the power of a signal that is present in a sub-band
of
>>B.
>>
>>I was thinkin to use FFT bin samples of that sub-band to compute tha
>>power.
>
>>How con be computed that power ? 
>
>Are you just researching a signal you have sampled, or do
>you need to implement this frequency analysis as part of 
>a system design?
>
>If the former, and you have Matlab, you could use freqz().
>
>If the latter, or if freqz() is not adequate, you really want to 
>do a real PSD calculation: window the data; compute the autocorrelation 
>function; window the autocorrelation function, then perform a
>cosine transform on it.  This gives you the PSD.  The power within a 
>range of frequencies is proportional to the PSD summed over those 
>frequencies.
>
>Note that, unlike an FFT, the number of points in this transform
>can be whatever you like and it is not related to the size of the
>initial dataset or even the length of the autocorrelation window.
>
>You will still have to calibrate the result with a scale
>factor.  Once you have a PSD function created, feed sinusoids
>of known power into it to determine the scale factor needed.
>
>Watch out for negative PSD values, which sometimes can happen
>with this approach.  (But not with "well behaved" signals.)
>
>Hope this helps.
>
>Steve


Hi Steve,

I have a signal from a digital receiver in form of IQ samples.

Next day I investigate about this method but.....

the proportionality factor is not exactly the same problem that I have if
use the FFT? So.. what is the difference into use FFT or PSD (excluding the
goodness of the power estimation)??
Thanks Luca

lucapp <pascale.luca.it@gmail.com> wrote:

>>Your problem as stated may not have any reasonable solution.
>>An FFT is a transform, not a power measurement.  If you want
>>to measure power within a frequency band, compute the power
>>spectral density instead.

>>Steve

>Thanks Steve for your reply.
>I have a clarification to do:
>
>I have the IQ samples of a portion of air spectrum with band B.
>I want to compute the power of a signal that is present in a sub-band of
>B.
>
>I was thinkin to use FFT bin samples of that sub-band to compute tha
>power.

>How con be computed that power ? 

Are you just researching a signal you have sampled, or do
you need to implement this frequency analysis as part of 
a system design?

If the former, and you have Matlab, you could use freqz().

If the latter, or if freqz() is not adequate, you really want to 
do a real PSD calculation: window the data; compute the autocorrelation 
function; window the autocorrelation function, then perform a
cosine transform on it.  This gives you the PSD.  The power within a 
range of frequencies is proportional to the PSD summed over those 
frequencies.

Note that, unlike an FFT, the number of points in this transform
can be whatever you like and it is not related to the size of the
initial dataset or even the length of the autocorrelation window.

You will still have to calibrate the result with a scale
factor.  Once you have a PSD function created, feed sinusoids
of known power into it to determine the scale factor needed.

Watch out for negative PSD values, which sometimes can happen
with this approach.  (But not with "well behaved" signals.)

Hope this helps.

Steve

>
>Your problem as stated may not have any reasonable solution.
>An FFT is a transform, not a power measurement.  If you want
>to measure power within a frequency band, compute the power
>spectral density instead.
>
>Steve

Thanks Steve for your reply.
I have a clarification to do:

I have the IQ samples of a portion of air spectrum with band B.
I want to compute the power of a signal that is present in a sub-band of
B.

I was thinkin to use FFT bin samples of that sub-band to compute tha
power.

How con be computed that power ? 

lucapp <pascale.luca.it@gmail.com> wrote:

>>lucapp <pascale.luca.it@gmail.com> wrote:

>>>I have already scaled the window 
>>>(i.e  I have a win with power=1, sqrt(sum(win^2)))
>>>but i dont obtain the same result again.

>>>any further suggestion ?

>>For windowed power measurements you need to scale the window by a 
>>fudge factor that may depend on the statistics of your signal.  
>>Therefore, run some simulations with the signal of interest and
>>determine which scale factor to use.

> My problem is to compute the power of a signal that is present 
> between fft bin #i and fft bin #j using a windowed FFT. 
> j-i<(=)FFT_DIMENSION.

>any solution ?

Your problem as stated may not have any reasonable solution.
An FFT is a transform, not a power measurement.  If you want
to measure power within a frequency band, compute the power
spectral density instead.

Steve
>
>Thanks
>

>lucapp <pascale.luca.it@gmail.com> wrote:
>
>>>Scale the window.
>
>>Hi John,
>>
>>I have already scaled the window 
>>(i.e  I have a win with power=1, sqrt(sum(win^2)))
>>but i dont obtain the same result again.
>
>>any further suggestion ?
>
>For windowed power measurements you need to scale the window by a 
>fudge factor that may depend on the statistics of your signal.  
>Therefore, run some simulations with the signal of interest and
>determine which scale factor to use.
>
>Steve
>


My problem is to compute the power of a signal that is present between fft
bin #i and fft bin #j using a windowed FFT. j-i<(=)FFT_DIMENSION.

any solution ?

Thanks