Wbx usrp1 sampling spectrum distortion

Hi
I use WBX + USRP1 to capture a DAB+ digital radio broadcast signal at
frequency 204.64MHz and bandwidth 1.4MHz.
Sampling rate is 2Msps (decimation=32)
The spectrum shown by usrp_fft.py is normal and clean. However, after
capturing the data using usrp_rx_cfile.py and loading the data to Matlab
and show the spectrum, I found an unexpected portion of spectrum around
the Nyquist frequency (1MHz in this case).
The parameters I use for usrp_rx_cfile and usrp_fft are the same: -f
204.64M -d 32 -g 6.
I uploaded a snapshot of the spectrum:

I can filter out the undesired part easily but that cost computational
resource and I do want to find out the cause.
Regards
Kyle

On 04/20/2010 02:51 AM, Kyle Z. wrote:

I uploaded a snapshot of the spectrum:
http://lh4.ggpht.com/_ozkfEhDY6Mg/S81p3QihHkI/AAAAAAAAAsE/KJ8vtRo4EI4/spec_samp.jpg

I can filter out the undesired part easily but that cost computational
resource and I do want to find out the cause.
Regards
Kyle

2 MS/s complex should give a spectrum of -1 to +1 MHz. Your Matlab plot
show 0 to 2 MHz, so I think you are loading the samples as reals instead
of floats.

Matt

Matt E. wrote:

204.64M -d 32 -g 6.
2 MS/s complex should give a spectrum of -1 to +1 MHz. Your Matlab
plot show 0 to 2 MHz, so I think you are loading the samples as reals
instead of floats.

Matt

Thanks Matt.
But I can confirm that I loaded complex data into Matlab using
read_cshort_binary() provided by Gnuradio.
Then I used pwelch() function to produce the power spectrum density
estimate. According to the Matlab documentation, this function does
accept complex data. It is because the frequencies at which the PSD is
estimated is always in [0,Fsampling), the spectrum shows 0 to 2MHz, and
I think 2MHz is equivalent to -1MHz, isn’t it?
I check the usrp_fft.py spectrum today again, using a sampling rate of
4M, now I can see there are adjacent channels at both sides. So I think
the undesired spectral portion is from these neighbor channels.
Regards
Kyle

On 04/20/2010 08:28 PM, Kyle Z. wrote:

Matlab
Regards
But I can confirm that I loaded complex data into Matlab using
Kyle


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

By default usrp_rx_cfile.py outputs complex floats, and
read_cshort_binary() expects complex shorts.
Looks to me like the “-s” parameter to usrp_rx_cfile.py causes it to
output complex shorts, which would
compatible with your matlab function, read_cshort_binary().


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On 04/20/2010 08:28 PM, Kyle Z. wrote:

The spectrum shown by usrp_fft.py is normal and clean. However, after
I can filter out the undesired part easily but that cost computational
Matt
I check the usrp_fft.py spectrum today again, using a sampling rate of

By default usrp_rx_cfile.py outputs complex floats, and
read_cshort_binary() expects complex shorts.
Looks to me like the “-s” parameter to usrp_rx_cfile.py causes it to
output complex shorts, which would
compatible with your matlab function, read_cshort_binary().

Marcus L.

Thanks Marcus
I confirm that I did use the switch -s to usrp_rx_cfile.py. And I can be
almost sure now that the undesired spectrum are caused by neighbour
channels. fortunately, they are not bad enough to prevent OFDM
demodulation as I am working on for the moment. Kyle

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs