Up Conversion Weirdness

GNU Radio
1

Hi Everyone,

I have some strange behavior of gnuradio while trying to do an
upconversion and multi-channel transmitter. I am currently trying to
have two packet transmitters send packets simultaniously on two
different radio channels. For this, I upconvert one of the
transmitters and add the two signals together. Following is the code
to connect the different blocks:

interpolate the two transmitters

self.connect(self.packet_transmitter1, self.interpolator1)
self.connect(self.packet_transmitter2, self.interpolator2)

upconvert the first transmitter)

self.connect(self.interpolator1, (self.multiplicator, 0))
self.connect(self.sin, (self.multiplicator, 1))

add the two signals

self.connect(self.multiplicator, (self.adder, 0))
self.connect(self.interpolator2, (self.adder, 1))

send the signal to the USRP

self.connect(self.adder, self.amp, self.u)
#self.connect(self.adder, self.filesink)

The code compiles, but I don’t receive the messages on the other side.
Therefore, I did some tests to check the different parts. The
following connection works, i.e., the packet transmitter and its
interpolation can be received at the other side:

self.connect(self.packet_transmitter1, self.interpolator1)
self.connect(self.interpolator1, self.amp, self.u)

Now, if I add the following, it suddenly doesn’t work anymore, even
though the added connections should not affect the path to the USRP:

self.connect(self.packet_transmitter1, self.interpolator1)
self.connect(self.interpolator1, (self.multiplicator, 0))
self.connect(self.sin, (self.multiplicator, 1))
self.connect(self.interpolator1, self.amp, self.u)
self.connect(self.multiplicator, self.filesink)

Does anyone know why this could happen?

Thanks a lot,

Thomas

2

upconversion and multi-channel transmitter. I am currently trying to
self.connect(self.sin, (self.multiplicator, 1))
interpolation can be received at the other side:
self.connect(self.interpolator1, self.amp, self.u)
self.connect(self.multiplicator, self.filesink)

First, I assume you meant the second to last line to read:

self.connect(self.multiplicator, self.amp, self.u)

What is the sampling rate at this point in the flow graph, and what is
the
frequency of the sine wave? I’m just trying to make sure you’re not
upconverting beyond the first Nyquist zone. For this app, you’re still
looking at the upconverted signal as baseband, so your sampling rate
must be
at least 2x(f_sin + signal BW). I assume that’s what the interpolator is
doing, but just making sure.

What’s the file look like when you plot it locally?

Tom

3

Hi Tom

On 10/25/06, Tom R. [email protected] wrote:

First, I assume you meant the second to last line to read:

self.connect(self.multiplicator, self.amp, self.u)

No, this is exactly the problem. Even if I directly hook up the
interpolator1 to the USRP, it doesn’t work. So, hooking up something
to a different path in the flow graph results in the problem. But I
also tried it this way with the same effect.

What is the sampling rate at this point in the flow graph, and what is the
frequency of the sine wave? I’m just trying to make sure you’re not
upconverting beyond the first Nyquist zone. For this app, you’re still
looking at the upconverted signal as baseband, so your sampling rate must be
at least 2x(f_sin + signal BW). I assume that’s what the interpolator is
doing, but just making sure.

Sorry, I forgot to mention that.

The frequency of the sine wave is around 500kHz. The Sampling rate of
the sine wave is 4MS/s and the signal bandwidth is around 300kHz. So
yes, the interpolator interpolates the signal to the required 4MS/s.

What’s the file look like when you plot it locally?

After doing some more tests, I found out the following. Instead of
sending it to the USRP, i sent the data to a second file sink. The
data looks fine, but it is way too short. In the case where it works,
the filesize is around 80MBi for 100 sent packets. In the second case,
the file is only about 4MBi and contains only the first 9 packets
instead of 100 (tested by running it through the decoder).

Thomas

4

On 10/25/06, Tom R. [email protected] wrote:

the file is only about 4MBi and contains only the first 9 packets
instead of 100 (tested by running it through the decoder).

Ok, I just hacked up a quick test to recreate what you’re doing. It
seems to
work for the most part (there are a lot of underruns, but having proved,
I
think, what I wanted, I didn’t get into debug it more).

There are a few parts that could be causing the problem:

  1. The definition of the Interpolators. I created an FIR interpolating
    filter as:
    taps = gr.firdes.low_pass(1, I, 0.5, 0.5)
    interp1 = gr.interp_fir_filter_ccf(I, taps)
    interp2 = gr.interp_fir_filter_ccf(I, taps)
    This creates it as an all-pass filter with an interpolating factor of I.

  2. The sine wave needs the same sampling rate as the output of the
    samples
    after the interpolator.

I’m assuming you’ve done both of these correctly. It’s the third one
here
that’s most likely the problem.

  1. The sample rates are not matched with the USRP. We set the USRP to
    have
    an interpolation factor derived from the pick_tx_bitrate() function that
    is
    based on the pre-interpolated sample rates. Say you have a 100 kbps GMSK
    signal with 4 samples per symbol, you have an sample rate of 400 ksps,
    which
    means you need an interpolation rate in the FPGA of 320 to match the 128
    Msps output.

If you are interpolating in the GR flowgraph, say by a factor of 10 to
give
you a 4 Msps sample rate, then you have to reset the USRP interpolation
rate
to 32.

I tested it out without resetting the USRP interp rate and I got the
same
truncated transmitted stream. Hopefully, this is where your problem is.
If
not, I can post my flow graph for doing this (it’s a bit crude so I
didn’t
want to post it and propagate bad code).

Tom