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 From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Wednesday, February 29, 2012 9:00 PM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gr-digital and USRP sample rate On Wed, Feb 29, 2012 at 10:33 AM, Nowlan, Sean <sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
