Hi all,
I would like to do the spectrum sensing for the whole 2.4G ISM band  (
2.4 -2.4835GHz ) to figure out where the spectrum holes are. I would
like to know if it is possible to sense the whole
band,2.4-2.4835GHz, through the USRP?  However, the ADC can only
support  64Msamples/sec. How can I scan the whole ISM band and draw the
spectrogram of the ISM band,2.4-2.4835GHz, through the USRP? Any hints?
Thank you so much for your time.
On Mon, Jul 14, 2008 at 6:26 PM, Goodman Roy
[email protected] wrote:
Hi all,
I would like to do the spectrum sensing for the whole 2.4G ISM band ( 2.4
-2.4835GHz ) to figure out where the spectrum holes are. I would like to
know if it is possible to sense the whole band,2.4-2.4835GHz, through the
USRP? However, the ADC can only support 64Msamples/sec. How can I scan the
whole ISM band and draw the spectrogram of the ISM
band,2.4-2.4835GHz, through the USRP? Any hints? Thank you so much for your
time.
Divide and conquer.
Brian
Goodman Roy wrote am 2008-07-15 00:26:
Hi all,
I would
like to know if it is possible to sense the whole
band,2.4-2.4835GHz, through the USRP? However, the ADC can only
support 64Msamples/sec. How can I scan the whole ISM band and draw the
spectrogram of the ISM band,2.4-2.4835GHz, through the USRP?
You can receive 32MHz at a time, but you are limited to 8MHz through the
USB bus. You cannot scan the whole 2.4Ghz ISM band at a time, but you
can step through it. If you want to detect unused frequencies you’d
probably just want to calculate the power over a reasonable time
interval to decide if some is using the band in question.
You may want take a look at
gnuradio-examples/python/usrp/usrp_spectrum_sense.py [1]
Patrick
Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria
On Tue, Jul 15, 2008 at 11:49:20AM +0200, Patrick S. wrote:
You can receive 32MHz at a time, but you are limited to 8MHz through the
USB bus. You cannot scan the whole 2.4Ghz ISM band at a time, but you can
step through it. If you want to detect unused frequencies you’d probably
just want to calculate the power over a reasonable time interval to decide
if some is using the band in question.
If you just want to find spectrum holes, you might be able to teach the
FPGA some kind of compressed sensing to increase your monitored
bandwidth (I guess factor 10 is feasible, if you can manage to install a
stable compression scheme on the FPGA - no idea how difficult/possible
this is).
IMHO, this is pretty funky stuff, but also quite tough math. [1] is
where you can find pretty much everything about compressed sensing, [2]
is what I’d suggest for compression. [3] and [4] are about using
compressed
sensing for wideband spectrum hole detection.
To be honest, I’ve never actually seen this outside the
pencil+paper/matlab world, and chances are high you want something
simpler than this. However, if the odd chance is you are prepared to go
through the effort, I’d be anxious to find about if you were successful
Cheers,
MB
[1] http://www.compressedsensing.com/
[2] http://www.dsp.ece.rice.edu/cs/random-filter-pub-03-web.pdf
[3] Zhi Tian; Giannakis, G.B., “Compressed Sensing for Wideband
Cognitive Radios,” Acoustics, Speech and Signal Processing, 2007. ICASSP
2007. IEEE International Conference on , vol.4, no., pp.IV-1357-IV-1360,
15-20 April 2007
[4] Zhuizhuan Yu; Hoyos, S.; Sadler, B.M., “Mixed-signal parallel
compressed sensing and reception for cognitive radio,” Acoustics, Speech
and Signal Processing, 2008. ICASSP 2008. IEEE International Conference
on , vol., no., pp.3861-3864, March 31 2008-April 4 2008
–
Martin B.
Institut fuer Nachrichtentechnik
Universitaet Karlsruhe
On Tue, Jul 15, 2008 at 7:39 AM, Martin B.
[email protected]
wrote:
IMHO, this is pretty funky stuff, but also quite tough math…
It needn’t be so difficult. There’s a lot of jargon and domain-specific
material in [1] and [2], but the principle is pretty straightforward.
There are two underlying ideas: (1) if a sequence is compressible at
all,
it’s the consequence of some redundancy in the sequence, but (2) even a
provably-optimal compression scheme must necessarily leave some residual
structure in the output (compressed) sequence.
What’s required is knowing where to look for the residual structure. In
general, such residual structure will show up as patterns in the entropy
of
the compressed output sequence measured over multiple intervals. In
other
words, you slide through the sequence looking at the estimated entropy
over
several windows of different sizes. A particular kind of data will
exhibit a
characteristic distribution of values over those several windows.
To be honest, I’ve never actually seen this outside the
pencil+paper/matlab world, and chances are high you want something
simpler than this. However, if the odd chance is you are prepared to go
through the effort, I’d be anxious to find about if you were successful
Google on “Universal Prediction.”
Frank
Martin B. wrote:
If you just want to find spectrum holes, you might be able to teach the
FPGA…
If you are going to make a custom FPGA build, one could do as follows:
Since there are two ADCs operating on quadrature downconverted samples
at 64 Msps, the spectral width is actually 64 MHz entering the FPGA.
(This is the reason the minimum decimation rate in the CIC/HB chain is
8, in order to reduce the sample rate/frequency content to 8 MHz to fit
the USB capacity.)
In practice, the anti-aliasing filters on the RFX limit the usable
passband width to approximately 50 MHz. So you can cover the whole 2.4
GHz ISM band with two different center frequencies.
As discussed in a recent thread, one could collect samples at this full
rate in the FPGA for a period of time, stream them to a FIFO, then drain
the FIFO at 1/8 the clock rate over the USB. You would be limited to
collecting something like 2-4K samples at a maximum duty cycle of 12.5%.
The host software would take these time domain “frames”, perform
windowing, FFT, and bin-over-time smoothing, resulting in a spectral
estimate across 50 MHz. This is almost identical to what the existing
usrp_fft.py script does, except now the time domain frame decimation
would be happening in the FPGA instead of in the host, to operate over
the full ADC bandwidth instead of over a maximum of 8 MHz.
After “enough” frames have been received, one would switch the center
frequency to the second one and repeat.
(Much of the above FPGA processing is already implemented in the RX
portion of the monostatic radar implementation, gr-radar-mono.)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs