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 a
a time and fills up a buffer and when that buffer (lets call it 128 tim
domain samples) is filled a FFT is taken and the 'output' is 128 points o
frequncy domain data.
Now.. instad of somthing like a sliding DFT where a window evaluates th
previous 127 samples along with one new one, i have a situation where
want to give the 'fft buffer' 128 NEW data points... so every single 'tim
instant'...128 new x[n] data are available.
If this were done would I get a new FFT output at every time instant?
On 29 Jun, 20:24, "westocl" <cwest...@hotmail.com> wrote:
> Hello all.
>
> Is it feasable to do an fft in 'real time' on different 'blocks' of data?
You need to look at the times:
- How often do you want / need a result?
- How long does the computations take?
- What latency is acceptable?
If you have a sampling rate of 1/T, then the limitig factor
is how much work your CPU can get done in T seconds. You
need to get the job done, shuffle the result away and
be ready to start filling the buffer again by the time
the next sample is available T seconds after the buffer is
full.
>On 29 Jun, 20:24, "westocl" <cwest...@hotmail.com> wrote:
>> Hello all.
>>
>> Is it feasable to do an fft in 'real time' on different 'blocks' o
data?
>
>You need to look at the times:
>
>- How often do you want / need a result?
>- How long does the computations take?
>- What latency is acceptable?
>
>If you have a sampling rate of 1/T, then the limitig factor
>is how much work your CPU can get done in T seconds. You
>need to get the job done, shuffle the result away and
>be ready to start filling the buffer again by the time
>the next sample is available T seconds after the buffer is
>full.
>
>Rune
I need an output at every 'time' instance. Is there any 'pipelined' typ
FFT algoritms available that you know of?
I am going to have new data at every sample (im assuming i can run th
clock much faster than the sampling rate)... but at any rate, im thinkin
NlogN is still too many calculations unless i have some kind of pipeline
type structure.
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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>westocl wrote:
>> Hello all.
>>
>> Is it feasable to do an fft in 'real time' on different 'blocks' o
data?
>>
>> (i understand the nomenclature real time may be inappropriate).
>>
>>
>> Im thinking, in general usage of an FFT, some x[n] comes in one sampl
at
>> a time and fills up a buffer and when that buffer (lets call it 12
time
>> domain samples) is filled a FFT is taken and the 'output' is 128 point
of
>> frequncy domain data.
>>
>> Now.. instad of somthing like a sliding DFT where a window evaluate
the
>> previous 127 samples along with one new one, i have a situation wher
i
>> want to give the 'fft buffer' 128 NEW data points... so every singl
'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]. Bu
imagine we had a switch that will switch to an already full buffer a
every 'sample interval'. Then at the next instant we go to the next 12
buffer and we call that x[n] and so on..
"westocl" <cweston_@hotmail.com> writes:
> [...]
> Is it feasable to do an fft in 'real time' on different 'blocks' of
> data?
What processor? What sample rate? How big of an FFT?
--
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> writes:
>> [...]
>> Is it feasable to do an fft in 'real time' on different 'blocks' of
>> data?
>
>What processor? What sample rate? How big of an FFT?
>--
>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 o
Power*, ELO
>
Im not sure what state of the art is.. but lets say i had maybe a power p
running at maybe 300 Mhz?? And i think would need a sample rate of mayb
100MHz.
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.
>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 on
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 12
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 situatio
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 tim
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 ca
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 nex
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 i
analagous to having 128 antennas and a situation where i have to take th
FFT for each antenna. So some kind of rotary switch gives me the ne
antenna input data at every sample... and will keep spinning.
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.
>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 i
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 windo
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 ever
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 buffe
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 ca
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 tak
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
would like to do?
>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 i
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 windo
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 ever
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 buffe
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 ca
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 tak
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.
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:
>>>>>> 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 yo
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 ful
buffer
>> at
>>>>>> every 'sample interval'. Then at the next instant we go to th
next
>>>> 128
>>>>>> buffer and we call that x[n] and so on..
>>>>> What fills these nearly full buffers? When? You seem to want 128 ne
>>>>> 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 t
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 ca
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 loo
at the processing i am trying to do.. constantly having differnt blocks o
data in which to process.
>>>>> 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.
>westocl <cweston_@hotmail.com> wrote:
>(big snip)
>
>>>>>> It seems thats exactly the case i will have... What i want to d
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 ca
look
>> at the processing i am trying to do.. constantly having differnt block
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 i
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
want to do is even possible with todays devices.
"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.
(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
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
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?