USRP Tx Rate Conversion

Hi All,

I am new to gnuradio and the USRP board and I have a basic question.

I want to transmit a GSM signal. Once It is encoded I have a 270833.333
symbols/sec signal. Then, it is up-converted (x8) and GMSK filtered, so
I
get a 2.1666 Ms/s complex signal.

Now the question: How to adapt this rate to the DAC converter on the
USRP
board?

Thanks for your help!

On Mon, Apr 14, 2008 at 8:03 PM, Wireless Monster
[email protected] wrote:

Hi All,

I am new to gnuradio and the USRP board and I have a basic question.

I want to transmit a GSM signal. Once It is encoded I have a 270833.333
symbols/sec signal. Then, it is up-converted (x8) and GMSK filtered, so I
get a 2.1666 Ms/s complex signal.

Now the question: How to adapt this rate to the DAC converter on the USRP
board?

Well, if you don’t use your x8 upconversion, you can get away with a
rational resampling (I believe).

Taking 270833.333, and upconverting by 3x makes the sample rate
812500. If you then rationally resample this by 16/13, you get a nice
1Msps signal which you can upconvert by a nice power of 2 for the
USRP.

Try it out and let us know how it works out?

Brian

Hi Brian,
Thank you for your help. Looks good :slight_smile:

So If I understood correctly I can do the following:

I set the USRP interpolator to 64, so the USRP sink will consume samples
at
a 2MS/s. I add the resampler just before with a ratio 16/13 so I it
consumes
samples with a 1.625MS/s rate. Just before that I have the GMSK filter
with
a interpolation factor of 6 so at the input it is consuming samples at
the
desired rate 270833.333 Samples/s.

At hat point can I send the samples (for example from a file with
gr.file_source) and guarantee they will be treated as a 270.8333Ks/s
stream?
(assuming there will be enough samples to process)

Thank you again for your help!

On Tue, Apr 15, 2008 at 3:14 PM, Wireless Monster
[email protected] wrote:

At hat point can I send the samples (for example from a file with
gr.file_source) and guarantee they will be treated as a 270.8333Ks/s stream?
(assuming there will be enough samples to process)

No. They will be treated like a 2Msps stream which is what you
interpolated your 270.8333Ksps stream to. You will have interpolated
your original signal by exactly 96/13 which will give you a 2Msps
stream.

Brian

…I understand…
so… What needs to be done to assure data will be treated as a
270.833Ks/s
rate?

Thanks!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At hat point can I send the samples (for example from a file with

gr.file_source) and guarantee they will be treated as a 270.8333Ks/
s stream?
(assuming there will be enough samples to process)

No. They will be treated like a 2Msps stream which is what you
interpolated your 270.8333Ksps stream to. You will have interpolated
your original signal by exactly 96/13 which will give you a 2Msps
stream.

I think you and Brian are experiencing notational confusion with Ks/s.
If you treat the post-processed signal as a 2 Msamples/sec signal then
the output signal will be a 270.733 Ksyms/sec. I believe that the USRP
settings you describe will do just that.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgFCpoACgkQy9GYuuMoUJ5RJgCfcq8ShxoFNmhvWNLFxET0V1CC
4nMAoKb4DyL8RyBxWCCntsfMwKZssUoQ
=dC0T
-----END PGP SIGNATURE-----

Brian, Dan,
Thank you very much for your help. It is clear now!
Rgds,

On Tue, Apr 15, 2008 at 4:05 PM, Dan H.
[email protected]

On Tue, Apr 15, 2008 at 3:48 PM, Wireless Monster
[email protected] wrote:

…I understand…
so… What needs to be done to assure data will be treated as a 270.833Ks/s
rate?

I feel like we’re in an Abbott and Costello routine.

Data is nothing until it’s pumped out of a DAC at a specific rate.
Lets say it’s 64Msps is the exact rate we’re going to be feeding some
DACs. We know there is an interpolating CIC filter beforehand. We
figure we’ll do a power of 2 to ensure there is no extra gain added to
the signal - so we choose 64.

Knowing this information, the stream at the output of the
interpolating CIC filter is 64Msps, and the stream going in is
64/64Msps, or 1Msps - then we know we should generate a stream of data
that is in fact a 1Msps representation of whatever data we wish.

In your case, you wish to make a 270.8333kSps (the S here means
Symbols … also known as a baud) stream into a 1Msps sample stream.
With some quick math, I can determine that you need to interpolate by
the exact value of 48/13. This has your data (270.8333kSymbols/sec)
at a sample rate of 1Msample/sec.

The lesson here is to never mix the terminology of sample and symbol
(or baud) rate.

Is it more clear as to what you’re doing now?

Brian

Brian, Dan,

It is working now. Thanks again for your help.

One more basic “signal processing question” … knowing that the input
and
output are complex (GMSK modulated signal), should I use complex or real
coefficients for the resampler filter (rational_resampler_ccc, vs.
rational_resampler_ccf) ?

Regarding Ed, question on the LPF after the resampler, I am not sure…
it
does not seems to be needed… any clue?

Thanks!

On Tue, Apr 15, 2008 at 4:09 PM, Wireless Monster <

On Thu, Apr 17, 2008 at 11:11 AM, Wireless Monster
[email protected] wrote:

Brian, Dan,

It is working now. Thanks again for your help.

One more basic “signal processing question” … knowing that the input and
output are complex (GMSK modulated signal), should I use complex or real
coefficients for the resampler filter (rational_resampler_ccc, vs.
rational_resampler_ccf) ?

I wouldn’t use a ccf. I’d either use an fff on each the real and
imaginary portions of the signal, or I’d use a ccc on the combined
signal, but that’s just my own personal opinion.

Regarding Ed, question on the LPF after the resampler, I am not sure… it
does not seems to be needed… any clue?

Look at the spectrum coming out of your rational resampling filter and
make sure there are no spurs or images outside the intended band.
That’s probably the easiest thing to do, though I don’t think there is
a need. The source for the filter is located here:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/filter/gr_rational_resampler_base_XXX.cc.t

There is a little bit of python taking place to actually generate the
code for all the filter types, but you can get the general idea of how
it works.

On a side note, do you have a GSM modulator that you are thinking of
contributing to the project? Or is this strictly for personal
purposes?

Brian

The spectrum looks clean so probably the LPF is not requirered.

I just got my hands on a USRP board and started playing with it for fun.
If
I came to something interesting (i.e. complete GSM modulator) I will
contribute it to the project.

Thks again and Rgds,

On Thu, Apr 17, 2008 at 11:26 AM, Brian P. [email protected]

On Thu, Apr 17, 2008 at 11:26:06AM -0400, Brian P. wrote:

I wouldn’t use a ccf. I’d either use an fff on each the real and
imaginary portions of the signal, or I’d use a ccc on the combined
signal, but that’s just my own personal opinion.

ccf is equivalent to fff on each of the real and imaginary.

(a+bj) * (c+dj) = (ac - bd) + (ad + bc)j
If d is zero -> ac + bcj

Eric

Wireless Monster wrote:

At hat point can I send the samples (for example from a file with
gr.file_source) and guarantee they will be treated as a 270.8333Ks/s
stream? (assuming there will be enough samples to process)

Thank you again for your help!

Doesn’t the resampler have to be followed by a low pass filter
to remove the aliased high frequencies that are introduced?

@(^.^)@ Ed

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