On 3/14/07, Eric Blossom <address@hidden> wrote:
On Wed, Mar 14, 2007 at 03:45:32PM -0400, Steven Clark wrote:
> Hi all-
> Two very different questions for you:
>
> 1) As a test, I am sending a GMSK signal (created by a signal generator,
> very low noise) at low symbol rates into the USRP and plotting the complex
> baseband that reaches the PC. One would expect to see a nice tight unit
> circle, and at low decimation rates (-d 16, etc) this is indeed the case.
> However, when I increase the decimation rate, the unit circle grows
> "thicker", which seems to indicate amplitude distortion. At -d 256 the
> distortion is quite bad.
Are you plotting points or drawing lines between points?
Plotting just points. They are definitely at different amplitudes. I can link plot images if that would help.
> Any idea what could be going on here? This shows up
> whether using either the TVRX daughtercard or the BasicRX. Something going
> on with the DDC in the FPGA? Filter ripple?
Where in the processing pipeline are you grabbing the data that you're
plotting? Before or after the clock recovery block?
I'm using usrp_rx_cfile.py. So hopefully I'm just looking at the raw complex baseband coming across USB. (incidentally, when you're using sending a complex stream to a file sink, is the first sample always real? I assume so...)
> 2) I am considering making a modified version of gr_quadrature_demod that
> would better handle residual carrier frequency error. The output of
> gr_quadrature_demod_cf::work should average to 0 over the long term if
> there's no residual carrier, but will be nonzero otherwise. So the basic
> idea is to average the "d_gain * gr_fast_atan2f(imag(product),
> real(product));" values and subtract them out. Is this a reasonable
> approach?
You could do this downstream of the block with an IIR filter and a subtractor.
Thanks for the tip. I will have to think about this some more.
> A lot of this depends on how many samples the work function
> receives to operate on.
I don't see how this matters...
I just meant that if I'm averaging, it's better if the averaging window is larger so that I get a good sampling of points.
> Who calls the work function of the various blocks in
> the flow graph, and what determines the size of noutput_items? Is there a
> way to set bounds on noutput_items? How do I insure that I'm averaging over
> a sufficient window?
Instead of trying to second guess how the scheduler works, you'd be
better advised to carry around any state that you need to do the
work. As pointed out above, an IIR should do a fine job of
estimating the DC offset, which can then be subtracted.
[There are ways to bound noutput_items, but I wouldn't recommend them
for this application. They tend to have unintended consequences.]
point taken.
> Thanks for any help
> -Steven
Eric