Thanks Marcus!
I took your idea and ran with it but encountered a funny
issue. I'm slightly confused about the output of the logpwrfft
(which is giving me the output of gr_fft_vcc). I've been
assuming that logpwrfft returns a vector of amplitudes in dB for
each fft bin. Lets say my fft size is 1024, I'm assuming vector
index 0 is the lowest frequency and vector index 1023 is the
maximum frequency. In plotting these values it appears to be
something different.
It goes from DC-bandwidth/2, then -bandwidth/2 to DC--standard form
of the underlying FFTW library.
I can only guess vector index 0 is the center frequency,
index 511 is the max frequency and index 512 is the min
frequency. Digging around gr_fft_vcc and I didn't see an
obvious answer. Any insight into what the fft is doing here?
Thanks!
-Phelps
On Wed, Sep 28, 2011 at 2:35 PM, Marcus
D. Leech <address@hidden>
wrote:
On 28/09/2011 4:50 PM, Phelps Williams
wrote:
I have a usrp and computer in a remote location
without much network bandwidth available to the system
and I'm using it as a spectrum analyzer. I'd like to
run the fft on the remote system and then send the
results to a connected client for display. This would
allow me to get greater fidelity than xwindows
forwarding or the ascii dft example while also using
less bandwidth. I would imagine the client side would
potentially reuse some of the existing wx or qt
interfaces for display and control.
This seems like a pretty useful / simple use of this
hardware. Does anybody know of any implementations
floating around that does this? I'd prefer not to
reinvent the wheel.
-Phelps
Because I'm such an insanely nice guy, I quickly implemented
something like what you'd need. Attached.
It uses a UHD source, computes a (default 2048-point)
10*log10-scaled FFT, then outputs the resulting float-vector
to a file-sink at a 5Hz rate.
Everything is pretty-much parameterized on the command line,
including:
frequency (100M)
gain (20)
srate (1.0e6)
fifoname ("fft_output_fifo")
devicecfg ("addr=192.168.10.2")
xmlport (6060)
I've included the ability to change parameters on-the-fly
using the XMLRPC server, which would allow you to, for
example, change
run-time parameters from some external interface, such as a
WEB gui or similar.
If this were my problem, I'd start this thing in a script
which creates the fifo file, starts some program that reads
the FIFO (left as an
exercise for the proverbial reader) in the background, then
calls the Gnu Radio program.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
|