[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] accumulate spectrum

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] accumulate spectrum
Date: Tue, 31 May 2016 09:38:13 +0200
User-agent: K-9 Mail for Android

This cannot be stressed enough. What GNU Radio processes is nothing but series of numbers. Just like these numbers don't have a physical unit (lest you interpret them as physically significant), the don't have a rate.
Furthermore, and this also is something very often misunderstood, throttle doesn't do anything with the samples. Really! It only copies them from in- to output. Nothing changes. And just as you can't tell the difference between a file that was downloaded with a fast internet connection and the same file downloaded through the slowest connection on earth, the sample file doesn't contain any difference whether you've used throttle or not. GNU Radio works by trying to be the fastest signal processing "pipe" possible. Throttle is really just as if someone deliberately stepped on and of a hose just to regulate the average amount of stuff going through.

This principle, GNU Radio not caring/knowing about sampling rates or any other aspect that doesn't concern the mathematical nature of these samples, is really inherent to the way GNU Radio does DSP.

For example, take the Signal Source. You'd say "that block has a sample rate parameter, so it does something different depending in the rate!", but that would actually misunderstand the fact that the sample rate parameter is, together with the frequency parameter, only used to calculate how much of a full oscillation to advance /per sample/. For example, a Signal Source with
Sample rate=100e3
Signal frequency=25
Will produce an oscillation with a period of 400 samples. That's *identical* in every aspect to what the same source does with
Sample rate=40
Signal frequency=0.01

I hope that cleared things up a bit
Best regards

Am 31. Mai 2016 04:37:12 MESZ, schrieb "Marcus D. Leech" <address@hidden>:
On 05/30/2016 09:19 PM, madengr wrote:
Try this:


The integrate with decimation is what you want. Starting at 32 ksps with a
1024 length FFT length yields 31.25 vector/sec. Then an integrate with
decimation by 32 averages down to 0.98 vector/sec.

However when I try reading those back from the file, I'm not getting the 1
ksps I should be getting. I have to set that throttle at 8000 to get the
proper update rate.

Files don't have any inherent sample-rate. Regardless of what rate they
were recorded at. Gnu Radio has no real "sense" of sample rate,
and will process samples as fast as it can. The only place where
sample rate is "real" with respect to actual real-time is at the "edges"
when the "edges" are controlled by actual hardware with an actual
real-time-relative sample-rate.

If you read data from a file, Gnu Radio will vacuum it out just as fast
as it can.

Adellain TSIAHINA wrote
Dear All,

I'm new to Gnu Radio. I looked carefully to the doc and tutorials but
not find any simple answer to my problem.
I have a radio signal from which I'm able to visualize the FFT in GNU
Now I would like to save the FFT (more exactly the magnitude squared, or
the spectrum) accumulated over a given period of time (the average over
time) into a file.

I found the following blocks in GRC that seem to be helpful:
- stream to vector
- complex to mag
- file sink

However I did not manage to save any accumulated spectrum...

Any help (eg a woking example) would be very welcome!

Thanks in advance.


Discuss-gnuradio mailing list

View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60265.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]