Jerry Avins wrote:
> westocl wrote:
>> Hello all.
>>
>> Is it feasable to do an fft in 'real time' on different 'blocks' of
>> data? (i understand the nomenclature real time may be inappropriate).
>>
>>
>> Im thinking, in general usage of an FFT, some x[n] comes in one
>> sample at a time and fills up a buffer and when that buffer (lets
>> call it 128 time domain samples) is filled a FFT is taken and the
>> 'output' is 128 points of frequncy domain data.
>>
>> Now.. instad of somthing like a sliding DFT where a window evaluates
>> the previous 127 samples along with one new one, i have a situation
>> where i want to give the 'fft buffer' 128 NEW data points... so
>> every single 'time instant'...128 new x[n] data are available.
>>
>> If this were done would I get a new FFT output at every time instant?
>
> You confused me. 128 new instances of x[n] for every n? How?
>
> Jerry

Sounds like a frequency domain beamformer.  Is that possible here?

Fred 

Randy Yates <yates@ieee.org> writes:
> [...]

PS: This is for non-overlapping blocks. Getting an output out every
sample (N-1 overlap) is out of the question.
--
Randy Yates                      % "She tells me that she likes me very much,
Digital Signal Labs              %     but when I try to touch, she makes it
mailto://yates@ieee.org          %                            all too clear."
http://www.digitalsignallabs.com %        'Yours Truly, 2095', *Time*, ELO  

"westocl" <cweston_@hotmail.com> writes:
> [...]
> Im not sure what state of the art is.. but lets say i had maybe a power pc
> running at maybe 300 Mhz?? And i think would need a sample rate of maybe
> 100MHz.  
>
> FFT size of ATLEAST 64.  i would love to have 128.

According to the FFTW data here, 

  http://www.fftw.org/speed/G4-1.06GHz-macosx/

(I'm using single-precision, real-data, powers-of-two), you could
theoretically take a 128-point FFT of data at a sample rate of up to 188
MHz on a 1.06 GHz PowerPC using the VDSP library. (I used a mflops of
3300).

I didn't see any PowerPC slower than 1.06 GHz there.

I'm not sure if this is practically the case, e.g., you'd have to factor
in moving the data around, the OS overhead, and who-knows-what-else. And
that's just to get the FFT - what are you doing with the result?
Magnitudes? Youch!

Unless you've got a very unique scenario, this is the sort of thing
better-done in an FPGA, as others have already said.
--
Randy Yates                      % "And all that I can do
Digital Signal Labs              %  is say I'm sorry, 
mailto://yates@ieee.org          %  that's the way it goes..."
http://www.digitalsignallabs.com % Getting To The Point', *Balance of Power*, ELO

>westocl <cweston_@hotmail.com> wrote:
>(big snip)
>
>>>>>> It seems thats exactly the case i will have... What i want to do
is
>>>>>> analagous to having 128 antennas and a situation where i have to
>>>> take  the  FFT for each antenna. So some kind of rotary switch 
>>>> gives me the new antenna input data at every sample... 
>>>> and will keep spinning.
>
>(snip)
> 
>> I dont mean to sound allusive... I was jut saying that is how you can
look
>> at the processing i am trying to do.. constantly having differnt blocks
of
>> data in which to process.
>
>In an FPGA one should be able to do a pipelined parallel implementation,
>with one result (full FFT output) per clock cycle, maybe 3 log2(N)
>clock cycle latency.   As you don't say how but your budget is,
>it is hard to say.  FPGAs are getting larger pretty fast, though.
>
>-- glen


hmmmm...

Thanks for the info. I can stomach the latency. I think this is what im
going to have to take a look at as long as i get the thru put.

Im not exactly sure of my budget as of yet, im just looking into if what i
want to do is even possible with todays devices.

westocl <cweston_@hotmail.com> wrote:
(big snip)

>>>>> It seems thats exactly the case i will have... What i want to do is
>>>>> analagous to having 128 antennas and a situation where i have to
>>> take  the  FFT for each antenna. So some kind of rotary switch 
>>> gives me the new antenna input data at every sample... 
>>> and will keep spinning.

(snip)
 
> I dont mean to sound allusive... I was jut saying that is how you can look
> at the processing i am trying to do.. constantly having differnt blocks of
> data in which to process.

In an FPGA one should be able to do a pipelined parallel implementation,
with one result (full FFT output) per clock cycle, maybe 3 log2(N)
clock cycle latency.   As you don't say how but your budget is,
it is hard to say.  FPGAs are getting larger pretty fast, though.

-- glen

>westocl wrote:
>>> westocl wrote:
>>>>> westocl wrote:
>>>>>>> westocl wrote:
>>>>>>>> Hello all. 
>>>>>>>>
>>>>>>>> Is it feasable to do an fft in 'real time' on different 'blocks'
>> of
>>>>>> data?
>>>>>>>> (i understand the nomenclature real time may be inappropriate). 
>>>>>>>>
>>>>>>>>
>>>>>>>> Im thinking, in general usage of an FFT, some x[n] comes in one
>>>> sample
>>>>>> at
>>>>>>>> a time and fills up a buffer and when that buffer (lets call it
>> 128
>>>>>> time
>>>>>>>> domain samples) is filled a FFT is taken and the 'output' is 128
>>>> points
>>>>>> of
>>>>>>>> frequncy domain data.
>>>>>>>>
>>>>>>>> Now.. instad of somthing like a sliding DFT where a window
>> evaluates
>>>>>> the
>>>>>>>> previous 127 samples along with one new one, i have a situation
>>>> where
>>>>>> i
>>>>>>>> want to give the 'fft buffer' 128 NEW data points... so every
>> single
>>>>>> 'time
>>>>>>>> instant'...128 new x[n] data are available.
>>>>>>>>
>>>>>>>> If this were done would I get a new FFT output at every time
>>>> instant?
>>>>>>> You confused me. 128 new instances of x[n] for every n? How?
>>>>>>>
>>>>>>> Jerry
>>>>>>> -- 
>>>>>>> Engineering is the art of making what you want from things you
can
>>>> get.
>>>>>> You are right...My notation is somewhat confusing by using x[n]. 
>> But
>>>>>> imagine we had a  switch that will switch to an already full
buffer
>> at
>>>>>> every 'sample interval'. Then at the next instant we go to the
next
>>>> 128
>>>>>> buffer and we call that x[n] and so on..
>>>>> What fills these nearly full buffers? When? You seem to want 128 new

>>>>> samples per sampling instant. That can't be sustained.
>>>>>
>>>>> Jerry
>>>>> -- 
>>>>> Engineering is the art of making what you want from things you can
>> get.
>>>>
>>>> It seems thats exactly the case i will have... What i want to do is
>>>> analagous to having 128 antennas and a situation where i have to
take
>> the
>>>> FFT for each antenna. So some kind of rotary switch gives me the new
>>>> antenna input data at every sample... and will keep spinning.
>>> There's nothing unusual about simultaneously processing multiple 
>>> streams. But each stream would have it's own FT. There could be 128 
>>> samples collected at each sample interval, but probably not via a 
>>> multiplexer (rotary switch). One of us is still confused.
>>>
>>> Jerry
>>> -- 
>>> Engineering is the art of making what you want from things you can
get.
>> 
>> 
>> Lets say you wanted to take the FFT of the output of a sliding DFT...
>> heres a situation where you will have new data at every sample.
>> 
>> Could this be done?
>
>Yes. What would the FFT of a sliding DFT represent to you? The 
>objectives seem to keep changing. What are you exploring?
>
>Jerry
>-- 
>Engineering is the art of making what you want from things you can get.


I dont mean to sound allusive... I was jut saying that is how you can look
at the processing i am trying to do.. constantly having differnt blocks of
data in which to process.

westocl wrote:
>> westocl wrote:
>>>> westocl wrote:
>>>>>> westocl wrote:
>>>>>>> Hello all. 
>>>>>>>
>>>>>>> Is it feasable to do an fft in 'real time' on different 'blocks'
> of
>>>>> data?
>>>>>>> (i understand the nomenclature real time may be inappropriate). 
>>>>>>>
>>>>>>>
>>>>>>> Im thinking, in general usage of an FFT, some x[n] comes in one
>>> sample
>>>>> at
>>>>>>> a time and fills up a buffer and when that buffer (lets call it
> 128
>>>>> time
>>>>>>> domain samples) is filled a FFT is taken and the 'output' is 128
>>> points
>>>>> of
>>>>>>> frequncy domain data.
>>>>>>>
>>>>>>> Now.. instad of somthing like a sliding DFT where a window
> evaluates
>>>>> the
>>>>>>> previous 127 samples along with one new one, i have a situation
>>> where
>>>>> i
>>>>>>> want to give the 'fft buffer' 128 NEW data points... so every
> single
>>>>> 'time
>>>>>>> instant'...128 new x[n] data are available.
>>>>>>>
>>>>>>> If this were done would I get a new FFT output at every time
>>> instant?
>>>>>> You confused me. 128 new instances of x[n] for every n? How?
>>>>>>
>>>>>> Jerry
>>>>>> -- 
>>>>>> Engineering is the art of making what you want from things you can
>>> get.
>>>>> You are right...My notation is somewhat confusing by using x[n]. 
> But
>>>>> imagine we had a  switch that will switch to an already full buffer
> at
>>>>> every 'sample interval'. Then at the next instant we go to the next
>>> 128
>>>>> buffer and we call that x[n] and so on..
>>>> What fills these nearly full buffers? When? You seem to want 128 new 
>>>> samples per sampling instant. That can't be sustained.
>>>>
>>>> Jerry
>>>> -- 
>>>> Engineering is the art of making what you want from things you can
> get.
>>>
>>> It seems thats exactly the case i will have... What i want to do is
>>> analagous to having 128 antennas and a situation where i have to take
> the
>>> FFT for each antenna. So some kind of rotary switch gives me the new
>>> antenna input data at every sample... and will keep spinning.
>> There's nothing unusual about simultaneously processing multiple 
>> streams. But each stream would have it's own FT. There could be 128 
>> samples collected at each sample interval, but probably not via a 
>> multiplexer (rotary switch). One of us is still confused.
>>
>> Jerry
>> -- 
>> Engineering is the art of making what you want from things you can get.
> 
> 
> Lets say you wanted to take the FFT of the output of a sliding DFT...
> heres a situation where you will have new data at every sample.
> 
> Could this be done?

Yes. What would the FFT of a sliding DFT represent to you? The 
objectives seem to keep changing. What are you exploring?

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

westocl wrote:
>> westocl wrote:
>>>> westocl wrote:
>>>>>> westocl wrote:
>>>>>>> Hello all. 
>>>>>>>
>>>>>>> Is it feasable to do an fft in 'real time' on different 'blocks'
> of
>>>>> data?
>>>>>>> (i understand the nomenclature real time may be inappropriate). 
>>>>>>>
>>>>>>>
>>>>>>> Im thinking, in general usage of an FFT, some x[n] comes in one
>>> sample
>>>>> at
>>>>>>> a time and fills up a buffer and when that buffer (lets call it
> 128
>>>>> time
>>>>>>> domain samples) is filled a FFT is taken and the 'output' is 128
>>> points
>>>>> of
>>>>>>> frequncy domain data.
>>>>>>>
>>>>>>> Now.. instad of somthing like a sliding DFT where a window
> evaluates
>>>>> the
>>>>>>> previous 127 samples along with one new one, i have a situation
>>> where
>>>>> i
>>>>>>> want to give the 'fft buffer' 128 NEW data points... so every
> single
>>>>> 'time
>>>>>>> instant'...128 new x[n] data are available.
>>>>>>>
>>>>>>> If this were done would I get a new FFT output at every time
>>> instant?
>>>>>> You confused me. 128 new instances of x[n] for every n? How?
>>>>>>
>>>>>> Jerry
>>>>>> -- 
>>>>>> Engineering is the art of making what you want from things you can
>>> get.
>>>>> You are right...My notation is somewhat confusing by using x[n]. 
> But
>>>>> imagine we had a  switch that will switch to an already full buffer
> at
>>>>> every 'sample interval'. Then at the next instant we go to the next
>>> 128
>>>>> buffer and we call that x[n] and so on..
>>>> What fills these nearly full buffers? When? You seem to want 128 new 
>>>> samples per sampling instant. That can't be sustained.
>>>>
>>>> Jerry
>>>> -- 
>>>> Engineering is the art of making what you want from things you can
> get.
>>>
>>> It seems thats exactly the case i will have... What i want to do is
>>> analagous to having 128 antennas and a situation where i have to take
> the
>>> FFT for each antenna. So some kind of rotary switch gives me the new
>>> antenna input data at every sample... and will keep spinning.
>> There's nothing unusual about simultaneously processing multiple 
>> streams. But each stream would have it's own FT. There could be 128 
>> samples collected at each sample interval, but probably not via a 
>> multiplexer (rotary switch). One of us is still confused.
>>
>> Jerry
>> -- 
>> Engineering is the art of making what you want from things you can get.
> 
> 
> Ok, so are you saying i would need 128 different FFT blocks to do what i
> would like to do?

Of course. You can't smudge data from different sources into one grand 
transform. (Caveat: you haven't yet explained what you want to accomplish.)

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

>westocl wrote:
>>> westocl wrote:
>>>>> westocl wrote:
>>>>>> Hello all. 
>>>>>>
>>>>>> Is it feasable to do an fft in 'real time' on different 'blocks'
of
>>>> data?
>>>>>> (i understand the nomenclature real time may be inappropriate). 
>>>>>>
>>>>>>
>>>>>> Im thinking, in general usage of an FFT, some x[n] comes in one
>> sample
>>>> at
>>>>>> a time and fills up a buffer and when that buffer (lets call it
128
>>>> time
>>>>>> domain samples) is filled a FFT is taken and the 'output' is 128
>> points
>>>> of
>>>>>> frequncy domain data.
>>>>>>
>>>>>> Now.. instad of somthing like a sliding DFT where a window
evaluates
>>>> the
>>>>>> previous 127 samples along with one new one, i have a situation
>> where
>>>> i
>>>>>> want to give the 'fft buffer' 128 NEW data points... so every
single
>>>> 'time
>>>>>> instant'...128 new x[n] data are available.
>>>>>>
>>>>>> If this were done would I get a new FFT output at every time
>> instant?
>>>>> You confused me. 128 new instances of x[n] for every n? How?
>>>>>
>>>>> Jerry
>>>>> -- 
>>>>> Engineering is the art of making what you want from things you can
>> get.
>>>>
>>>> You are right...My notation is somewhat confusing by using x[n]. 
But
>>>> imagine we had a  switch that will switch to an already full buffer
at
>>>> every 'sample interval'. Then at the next instant we go to the next
>> 128
>>>> buffer and we call that x[n] and so on..
>>> What fills these nearly full buffers? When? You seem to want 128 new 
>>> samples per sampling instant. That can't be sustained.
>>>
>>> Jerry
>>> -- 
>>> Engineering is the art of making what you want from things you can
get.
>> 
>> 
>> It seems thats exactly the case i will have... What i want to do is
>> analagous to having 128 antennas and a situation where i have to take
the
>> FFT for each antenna. So some kind of rotary switch gives me the new
>> antenna input data at every sample... and will keep spinning.
>
>There's nothing unusual about simultaneously processing multiple 
>streams. But each stream would have it's own FT. There could be 128 
>samples collected at each sample interval, but probably not via a 
>multiplexer (rotary switch). One of us is still confused.
>
>Jerry
>-- 
>Engineering is the art of making what you want from things you can get.


Lets say you wanted to take the FFT of the output of a sliding DFT...
heres a situation where you will have new data at every sample.

Could this be done?

>westocl wrote:
>>> westocl wrote:
>>>>> westocl wrote:
>>>>>> Hello all. 
>>>>>>
>>>>>> Is it feasable to do an fft in 'real time' on different 'blocks'
of
>>>> data?
>>>>>> (i understand the nomenclature real time may be inappropriate). 
>>>>>>
>>>>>>
>>>>>> Im thinking, in general usage of an FFT, some x[n] comes in one
>> sample
>>>> at
>>>>>> a time and fills up a buffer and when that buffer (lets call it
128
>>>> time
>>>>>> domain samples) is filled a FFT is taken and the 'output' is 128
>> points
>>>> of
>>>>>> frequncy domain data.
>>>>>>
>>>>>> Now.. instad of somthing like a sliding DFT where a window
evaluates
>>>> the
>>>>>> previous 127 samples along with one new one, i have a situation
>> where
>>>> i
>>>>>> want to give the 'fft buffer' 128 NEW data points... so every
single
>>>> 'time
>>>>>> instant'...128 new x[n] data are available.
>>>>>>
>>>>>> If this were done would I get a new FFT output at every time
>> instant?
>>>>> You confused me. 128 new instances of x[n] for every n? How?
>>>>>
>>>>> Jerry
>>>>> -- 
>>>>> Engineering is the art of making what you want from things you can
>> get.
>>>>
>>>> You are right...My notation is somewhat confusing by using x[n]. 
But
>>>> imagine we had a  switch that will switch to an already full buffer
at
>>>> every 'sample interval'. Then at the next instant we go to the next
>> 128
>>>> buffer and we call that x[n] and so on..
>>> What fills these nearly full buffers? When? You seem to want 128 new 
>>> samples per sampling instant. That can't be sustained.
>>>
>>> Jerry
>>> -- 
>>> Engineering is the art of making what you want from things you can
get.
>> 
>> 
>> It seems thats exactly the case i will have... What i want to do is
>> analagous to having 128 antennas and a situation where i have to take
the
>> FFT for each antenna. So some kind of rotary switch gives me the new
>> antenna input data at every sample... and will keep spinning.
>
>There's nothing unusual about simultaneously processing multiple 
>streams. But each stream would have it's own FT. There could be 128 
>samples collected at each sample interval, but probably not via a 
>multiplexer (rotary switch). One of us is still confused.
>
>Jerry
>-- 
>Engineering is the art of making what you want from things you can get.


Ok, so are you saying i would need 128 different FFT blocks to do what i
would like to do?