On 04/20/2010 08:28 PM, Kyle Zhou wrote:
>
>
> Matt Ettus wrote:
>> On 04/20/2010 02:51 AM, Kyle Zhou wrote:
>>> 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:
>>>
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
>>
> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 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 Leech
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio