discuss-gnuradio
[Top][All Lists]
Advanced

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

RE: [Discuss-gnuradio] Up Conversion Weirdness


From: Tom Rondeau
Subject: RE: [Discuss-gnuradio] Up Conversion Weirdness
Date: Fri, 27 Oct 2006 08:56:54 -0400

> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf
> Of Thomas Schmid
> Sent: Wednesday, October 25, 2006 10:37 AM
> To: Tom Rondeau
> Cc: gnuradio mailing list
> Subject: Re: [Discuss-gnuradio] Up Conversion Weirdness
> 
> Hi Tom
> 
> On 10/25/06, Tom Rondeau <address@hidden> 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).

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.

3. 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







reply via email to

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