Hi,
I’m using USRP E310 and running uhd_fft.grc to acquire FFT spectrum from
the device in network mode, and then displays that with QT FFT GUI
block.
Setting a center frequency, I can get an instantaneous bandwidth of
32MHz
around the center frequency. (for me it’s the maximum in network mode)
Now,
I want to change the center frequency programmatically in order to sweep
a
larger bandwidth and then concatenate the results into a single QT FFT
graph like this:
-IQ/2-----Cent.freq1-----+IQ/2 -IQ/2-----Cent.freq2------+IQ/2
-IQ/2-----Cent.freq2------+IQ/2 …
Is their a way I can do it?
Regards,
On Thu, Jun 11, 2015 at 9:59 AM, Hassaan A. [email protected]
wrote:
-IQ/2-----Cent.freq1-----+IQ/2 -IQ/2-----Cent.freq2------+IQ/2
-IQ/2-----Cent.freq2------+IQ/2 …
Is their a way I can do it?
Regards,
The QTGUI FFT sink has a message port that allows you to control the
center
frequency. See the Detailed Description here
http://gnuradio.org/doc/doxygen/classgr_1_1qtgui_1_1freq__sink__c.html
Tom
Thanks for the guidance.
Can I do this message passing in GRC? Also, how would the bandwidths get
concatenated together and displayed in the same FFT graph?
On Thu, Jun 11, 2015 at 10:25 AM, Hassaan A. [email protected]
wrote:
Thanks for the guidance.
Can I do this message passing in GRC? Also, how would the bandwidths get
concatenated together and displayed in the same FFT graph?
Check out our tutorials on gnuradio.org for message passing help. In the
FFT blocks, go into the Properties and in the General tab at the bottom
there’s a “Show Msg Ports” option that you’ll need to turn on.
You wouldn’t be able to concatenate the signals in the plot. The plots
are
designed for real-time use, so each time plots, it’s based on the newest
signal information in the data stream. So the old stuff would be gone.
The
message port just changes the center frequency with the same bandwidth.
What you want is very specialized, so you’ll probably have to write
something of your own for this.
Tom
What you want is very specialized, so you’ll probably have to write
something of your own for this.
Tom
I want to amplify on this point. The number of “useful things” you might
want to do with a real-time sample-stream in the context of DSP and
radio is very, very large, nearly infinite, and that “near infinity”
expands as we learn to do more useful things (because of the
standing-on-the-shoulders-of-giants effect).
So, having a finite frame (Gnu Radio) and expecting it to,
out-of-the-box, address any particular aspect of that
near-infinite-sea of possibilities is unrealistic.
Using a “proximate analogy”. When you encounter the C++ compiler for
the first time, you may notice that it doesn’t, “out of the box”
automatically know how to implement a spreadsheet, or a database, or any
particular item in the infinite-sea of applications you could write in
C++. Gnu Radio is the same. It’s a toolbox. A very rich toolbox, but
a toolbox, nonetheless. There’s no magic “make my answers come out”
button.
When one is working in one small corner of “wireless” or “DSP” or “RF
systems”, it is often tempting to think that your particular corner,
whatever it is, constitutes “the biggest class of application”, and
expect the tooling to be “born knowing” how to deal with your particular
class of application. It just isn’t realistic.
This is a general comment, not directed any anyone in particular, and
one that I’ve made in the past, and will probably make again from time
to time.
On Jun 11, 2015, at 6:59, Hassaan A. [email protected] wrote:
I’m using USRP E310 and running uhd_fft.grc to acquire FFT spectrum from the
device in network mode, and then displays that with QT FFT GUI block.
Setting a center frequency, I can get an instantaneous bandwidth of 32MHz around
the center frequency. (for me it’s the maximum in network mode) Now, I want to
change the center frequency programmatically in order to sweep a larger bandwidth
and then concatenate the results into a single QT FFT graph like this:
Balint S. posted a video on May 30 demonstrating doing exactly this
(with a USRP X310; I don’t know if the capabilities are different enough
to matter).
SDR Wideband Spectrum Monitoring for Drone FPV Frequency Management
At 2:00 “I just prototyped a GNU Radio block yesterday…”
Perhaps he should be encouraged to move it beyond prototype status!
–
Kevin R. http://switchb.org/kpreid/
Hello Hassaan,
there’s no way you get 32MHz of bandwidth over network mode – for 16
bit samples, that’s not even theoretically possible over gigabit
ethernet.
In fact, the E310’s CPU will under no circumstances push that many
samples per second in or out of the E310.
Please make sure you actually get the bandwidth you think you are
getting.
I’d like to point out that the network mode really is a narrowband
diagnostic and maybe demo tool, but can’t be used for serious sample
rates – the architecture of the network interface on the E310 just
doesn’t allow such rates when handled by the ARM.
Best regards,
Marcus
