I posted this to the USRP users list since we’re not using GNU Radio
proper for this project, but Devin’s questions about spectrum sensing
make me think it could be useful for GNU USRP users, too. Although we
did this on the N210, it might be possible to do something similar on
the USRP2.
We’ve customized an FPGA image for the N210 that lets us grab batches of
256K complex samples (one SRAM full) at 100 Msps with no decimation,
scaling, or downconversion. It works by filling the SRAM with samples at
full rate, then dribbling them out the Ethernet in the normal fashion. I
posted the ISE project, Verilog code, and a built image at
https://public.me.com/mepard. You’ll also find some examples of
visualizing the spectrum data there. I’m particularly fond of the movie.
Some things you should know:
- It cannot be used to transmit. Transmit support used the SRAM, which I
needed to buffer the received samples.
- It works with the current UHD firmware and host code.
- When you issue_stream_cmd, request no more than 2^18 samples, the size
of the SRAM. You can issue another stream command later to get another
batch, but you can’t get more than 256K contiguous samples.
- The rx sample rate is ignored. For good measure, I set it to the usual
maximum of 25 Msps.
- Since there’s no downconversion, you’ll only get whatever center
frequencies the daughterboard supports and you can’t use LO offsets.
The uhd_streamer.cpp app, also posted, is what we’ve used to do our
testing.
Enjoy.
-Marc
On 18.03.2011 20:09, Marc E. wrote:
We’ve customized an FPGA image for the N210 that lets us grab batches of 256K
complex samples (one SRAM full) at 100 Msps with no decimation, scaling,
or downconversion. It works by filling the SRAM with samples at full rate, then
dribbling them out the Ethernet in the normal fashion. I posted the
ISE project, Verilog code, and a built image at https://public.me.com/mepard.
You’ll also find some examples of visualizing the spectrum data there.
I’m particularly fond of the movie.
Thanks for publishing. This is very impressive, using Gnuradio as a
spectrum analyzer.
A few questions:
- What about compensating the spectral shape within the measurement
bandwidth?
It does not seem too much dependent on the center frequency.
- Movie: why do you have spectral lines walking in both directions?
Is one direction caused by real frequency components and the other by
spurious sine components? Can it be predicted and compensated?
- Can half of your scan speed be achieved by using original FPGA,
taking snapshots and do all processing on the PC? Or do you need some
special processing that needs a better timing within the FPGA?
I think it’s an interesting instrument for electronics education
in schools that can’t afford expensive traditional spectrum analyzers.
I am curious if anything like this is available for the USRP version 1,
for anyone who might know.
As a random side note, it would be interesting if future versions of the
USRP contained off-board RAM chips for data buffering for just this
purpose. The reason I suggest this is for making the USRP more usable
in RADAR applications. Universal RADAR Peripheral, anyone?
On 3/18/2011 3:09 PM, Marc E. wrote:
normal fashion. I posted the ISE project, Verilog code, and a built
size of the SRAM. You can issue another stream command later to get
-Marc
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
~Jeffrey L., K1VZX
On Mar 18, 2011, at 3:58 PM, Moeller wrote:
Thanks for publishing. This is very impressive, using Gnuradio as a spectrum
analyzer.
Thanks. It’s been a fun project.
- What about compensating the spectral shape within the measurement bandwidth?
Seems doable. I’m only now learning signal processing (I’m software guy
by training and trade), so I’ll do some investigation. If someone else
wants to take it on, it’s on my list to post the MATLAB code, too, but I
need to do some polishing first.
- Movie: why do you have spectral lines walking in both directions?
Good question. They also appear in the color plots as diagonals in
opposite directions. Our hunch is that they’re related to the DBSRX2’s
frequency synthesis and a function of the center frequency.
Can it be predicted and compensated?
Seems likely. We’ve been playing with ways to isolate the components
related to the baseband the those related to the center frequency.
- Can half of your scan speed be achieved by using original FPGA,
taking snapshots and do all processing on the PC? Or do you need some
special processing that needs a better timing within the FPGA?
I’m sure that would work. The code that drives the scan and crunches the
data doesn’t really care what the sample rate is. The scan step for the
plots I posted was 100 KHz. Lately we’ve been using 100MHz/1024 to be
the same as the periodogram resolution, which makes horizontal steps and
vertical steps in the periodogram matrix the same. The movie speed is a
result of the 60 frames per second rate of the tools I used to make it.
When viewing it in MATLAB, we usually use much higher frame rates.
We didn’t really start out to do a spectrum analyzer. We’re working on a
filter that needs to operate at 100 Msps in the FPGA so we wanted to see
what the signal looks like right out of the ADCs. Then we noticed
internal noise in the system and wanted to see the big picture so we
could pick out a quiet place to do our testing and here we are.
-Marc
Marc
I am a professor of Physics at UC Santa Barbara. I have an undergraduate
research project where they need a real time integrating spectrum
analyzer with very high efficiency. I have looked at what you did and
wonder if can imagine using the N210 for such a system. We need about a
1000 channel with at least a 50 MHz bandwidth. We would like to readout
spectra every second or so. The key is we need high efficiency (near
continuous integration).
My email is [email protected]
Our website is beta.deepspace.ucsb.edu
Philip Lubin
Marc E. wrote in post #988206:
I posted this to the USRP users list since we’re not using GNU Radio
prMoper for this project, but Devin’s questions about spectrum sensing
make me think it could be useful for GNU USRP users, too. Although we
did this on the N210, it might be possible to do something similar on
the USRP2.
We’ve customized an FPGA image for the N210 that lets us grab batches of
256K complex samples (one SRAM full) at 100 Msps with no decimation,
scaling, or downconversion. It works by filling the SRAM with samples at
full rate, then dribbling them out the Ethernet in the normal fashion. I
posted the ISE project, Verilog code, and a built image at
https://public.me.com/mepard. You’ll also find some examples of
visualizing the spectrum data there. I’m particularly fond of the movie.
Some things you should know:
- It cannot be used to transmit. Transmit support used the SRAM, which I
needed to buffer the received samples.
- It works with the current UHD firmware and host code.
- When you issue_stream_cmd, request no more than 2^18 samples, the size
of the SRAM. You can issue another stream command later to get another
batch, but you can’t get more than 256K contiguous samples.
- The rx sample rate is ignored. For good measure, I set it to the usual
maximum of 25 Msps.
- Since there’s no downconversion, you’ll only get whatever center
frequencies the daughterboard supports and you can’t use LO offsets.
The uhd_streamer.cpp app, also posted, is what we’ve used to do our
testing.
Enjoy.
-Marc