That would be a case for flow graph reconfiguration, most probably :)
On 26.10.2014 06:13, Mostafa Alizadeh wrote:
> Hello Marcus,
> I checked my sliding fft works fine and the bug was somewhere else :)
>
> In fact I want to detect a known sequence within data non-coherently. After
> detection I wa
Sliding fft is fundamentally different from spectral estimation in
practice. Because in practice we never do sliding on sample by sample to
get estimate of spectrum.
The using purpose of sliding fft here is something else.
Best,
On Sat, Oct 25, 2014 at 6:08 PM, Marcus D. Leech wrote:
> On 10
Hello Marcus,
I checked my sliding fft works fine and the bug was somewhere else :)
In fact I want to detect a known sequence within data non-coherently. After
detection I want to neglect this 'work' process.
How would you prefer to stop this work process after detection? (Something
like putting t
That looks like the exact same error and will have the exact same
resolution. We'll fix it before the next release. If you don't feel
comfortable making the changes discussed in this thread then I suggest
you stick with a package manager (macports) and heed Michael Dickens'
advice: http://lists.gnu
On Oct 25, 2014, at 5:27, Jeff Long wrote:
> On 10/24/2014 09:02 PM, Kevin Reid wrote:
>> What does it mean in the GNU Radio issue tracker for an issue to have the
>> status "Feedback"?
>
> Usually "Feedback" does mean "waiting for user feedback". But in this case, I
> think it means "hmm, hav
On 10/25/2014 08:26 AM, Marcus Müller wrote:
Also, sliding FFTs do look like a computational heavy load. What is
the application for that? I ask because getting an fft_length FFT for
every item increases item/sample rate without giving you
(information-theoretically speaking) any advantage o
On 10/24/2014 09:02 PM, Kevin Reid wrote:
What does it mean in the GNU Radio issue tracker for an issue to have the status
"Feedback"?
Usually "Feedback" does mean "waiting for user feedback". But in this
case, I think it means "hmm, have to think about that". Both reports
have the same unde
Hi Mostafa,
>is there any "race" problem between these 2 threads and the work one?
I think you might be confused what the FFT multithreading means here; I hope I
can illustrate this. Let's set the FFT multithreading level to two threads:
sliding_fft_impl::work()
|
enter "
Hi all,
I have the following c++ code which gets fft by sliding on sample by sample
fo the input.
/*
* The private constructor
*/
sliding_fft_impl::sliding_fft_impl(uint fft_size)
: gr::sync_block("sliding_fft",
gr::io_signature::make(1, 1, sizeof(gr_comp
