discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] gr-digital and USRP sample rate


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] gr-digital and USRP sample rate
Date: Thu, 1 Mar 2012 10:30:27 -0500

On Thu, Mar 1, 2012 at 10:23 AM, Nowlan, Sean <address@hidden> wrote:

That makes sense, but what about in a case like MSK? It looks like the GMSK example in gr-digital requires an integer for samples_per_symbol due to the Gaussian pre-filter. In that case, aren’t possible data rates limited to those that will result in a USRP sample rate that is supported exactly?

 

(Also, is my understanding correct about what the possible USRP rates are? Must be an integer division of DSP clock rate?)

 

Thanks,

Sean


I tried to do the same with the GMSK, but I screwed up the filter definition and it didn't work at all. So I went back to the old way because at the time, I didn't have time to make it work correctly.

And yes, you are correct about the rates of the USRP with the UHD. I don't know the current setup with the UHD implementation, but there used to be restrictions on the filters that were used based on using different decimations/interpolations.

Tom


From: address@hidden [mailto:address@hidden] On Behalf Of Tom Rondeau
Sent: Wednesday, February 29, 2012 9:00 PM
To: Nowlan, Sean
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] gr-digital and USRP sample rate

 

On Wed, Feb 29, 2012 at 10:33 AM, Nowlan, Sean <address@hidden> wrote:

I noticed that the generic_mod_demod.py script in gr-digital uses a root-raised cosine filter taps and the polyphase filterbank arbitrary resampler block. I want to resample so that I can exactly hit a supported USRP transmit sample rate. What kind of issues will I encounter trying to do this? My understanding is that the USRP can only sample at integer divisions of the DSP rate (100MSPS for N200/210)., and that if a requested sample rate doesn’t hit a supported rate exactly, it picks the nearest faster one. Is this correct?

 

Thanks,

Sean

 

The benchmark scripts take care of this, if I understand your question. We try to set the sample rate through the UHD interface, then ask for the actual sample rate it set. This is done in benchmark_tx where we use this info to set the actual samples per symbol (a real number) based on the the difference between the asked for and actual sample rate. It's this number that is then used in the generic_mod_demod code to set the sample rate in the pfb_arb_resampler to match the sample rates.

 

Tom

 



reply via email to

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