discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FM Receiver


From: Anoth
Subject: Re: [Discuss-gnuradio] FM Receiver
Date: Tue, 1 Mar 2011 19:03:50 -0800 (PST)

Hi again,

I resolved my problem without using the Polyphase Resampler. It was a sample
rate issue which did not match the requirements of the audio card. Anyway,
thank you a lot for your help.

Francois


Anoth wrote:
> 
> Hi,
> 
> I agree that it is a sample rate issue. The USRP sends too many data to
> the computer which becomes overrun. As you said, I put a Polyphase
> Resampler between the USRP and the WBFM receive blocks (
> http://old.nabble.com/file/p31046181/fm_receiver.py fm_receiver.py ). But,
> when I execute the flow graph, I get this message :
> 
> PCM name: hw:0,0
> Access types:
>     MMAP_INTERLEAVED     YES
>     MMAP_NONINTERLEAVED  NO
>     MMAP_COMPLEX         NO
>     RW_INTERLEAVED       YES
>     RW_NONINTERLEAVED    NO
> Formats:
>     S16_LE               YES
> Number of channels
>     min channels: 2
>     max channels: 2
>     2 channels        YES
> Sample Rates:
>     min rate:    8000 (dir = 0)
>     max rate:   48000 (dir = 0)
>       8000  YES
>      16000  YES
>      22050  YES
>      32000  YES
>      44100  YES
>      48000  YES
>      96000  NO
>     192000  NO
> audio_alsa_sink[hw:0,0]: using S16_LE
>>>> gr_fir_ccf: using SSE
> 
>>>> Done
> 
> Nothing happens and I can no longer see the FFT sink window. By the way,
> sorry for the delay of my response, but I have not worked on this project
> for a couple of days.
> 
> Francois
> 
> 
> Tom Rondeau wrote:
>> 
>> On Thu, Feb 24, 2011 at 10:28 PM, Anoth <address@hidden>
>> wrote:
>>>
>>> Yes, you must be right, I must have made a mistake when I set up the
>>> flow
>>> graph. How do you know the sample rate delivered by the UHD and how is
>>> the
>>> Polyphase Resampler implemented into the flow graph ?
>>>
>>> Francois
>> 
>> Not entirely sure how to do this in GRC... When you set the sample
>> rate of the UHD device, you can request back what it was actually set
>> to using "get_samp_rate". So if you were doing this just in Python,
>> you can have:
>> 
>> req_sr = SR
>> act_sr = uhd.get_samp_rate()
>> resamp_rate = req_sr / act_sr
>> resampler = blks2.pfb_arb_resampler(resamp_rate)
>> 
>> Unless, of course, it's "resamp_rate = act_sr/req_sr". I've been
>> working too long today to reason that out.
>> 
>> I'm sure there is a way to do this in GRC by knowing the name of the
>> UHD device and using it; I've just never done it.
>> 
>> Tom
>> 
>> 
>> 
>>> Tom Rondeau wrote:
>>>>
>>>> On Thu, Feb 24, 2011 at 7:17 PM, Anoth <address@hidden>
>>>> wrote:
>>>>>
>>>>> Hi Josh,
>>>>>
>>>>> Yes, I have already though about that and I tried to match the sample
>>>>> and
>>>>> sound card rates without success (but I might made a mistake). I have
>>>>> also
>>>>> read on the Internet that it might come from the sound card which
>>>>> cannot
>>>>> support all rates but I did not find anything more about that subject.
>>>>> Here
>>>>> the python code generated by GRC :
>>>>> http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py
>>>>>
>>>>> Francois
>>>>
>>>> I think Josh is right and it's a sampling rate error. When you set the
>>>> sampling rate of the USRP, ask the UHD driver what the current
>>>> sampling rate is. Use what it returns to you to adjust the sampling
>>>> rate properly. I ran into this same issue and solved it by using the
>>>> pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the
>>>> rates correctly.
>>>>
>>>> Tom
>>>>
>>>>
>>>>> Josh Blum-2 wrote:
>>>>>>
>>>>>>
>>>>>>>>>> gr_fir_ccc: using SSE
>>>>>>> aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU
>>>>>>>
>>>>>>
>>>>>> These characters being printed means that you have mismatched sample
>>>>>> rates between your USRP device and sound card. Could this be the
>>>>>> case?
>>>>>>
>>>>>> -josh
>>>>>>
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing list
>>>>>> address@hidden
>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://old.nabble.com/FM-Receiver-tp31009069p31009164.html
>>>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> address@hidden
>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/FM-Receiver-tp31009069p31010011.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/FM-Receiver-tp31009069p31046251.html
Sent from the GnuRadio mailing list archive at Nabble.com.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]