discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?


From: Steven Clark
Subject: Re: [Discuss-gnuradio] Bug in gr_quadrature_demod_cf, or scheduler?
Date: Fri, 21 Sep 2007 14:18:08 -0400

Thanks Matt, I understand the issue now and switching atan functions does indeed make the glitches go away.

Do you have a sense of how much slower the regular atan2f function is than gr_fast_atan2f?
If the performance hit isn't too bad, I might leave it in for peace of mind.

Regarding excessive oversampling: I agree that 64, 128, etc. samples per symbol is pretty ridiculous, I was just seeing how the issue scaled with sps.

What is the best strategy when you want to rx a signal at a very slow symbol rate? Max decimation (256?) on the USRP, then decimate/filter some more in software? As an arbitrary example, symbol rate 7812.5 sym/sec: have the usrp decimate by 256 and you're still at 32 samp/sym. What is the best way to partition decimation between hw and sw? Which sw blocks are ideal for this?

On 9/21/07, Matt Ettus <address@hidden> wrote:
Steven Clark wrote:
> Hi all-
> please look at this sequence of eye diagrams:
> http://picasaweb.google.com/steven.p.clark/GMSKFmdemodGlitches
>
> These are from a gmsk mod/demod pair, showing the output of the TX's
> gaussian filter (blue) overlaid with the output of the RX's fmdemod
> (red). BT = 0.35.
>
> At 8 samples per symbol, everything looks ok. Red is pretty much right
> on top of blue, as we'd expect.
> As I increase samples per symbol, however, something strange happens,
> shown in plot sequence. The RX's fmdemod output gets successively more
> "glitchy".
>

This might be because of the use of gr_fast_atan2f.  This function is an
approximation used in order to speed things up since the real atan2f is
slow.  Could you try replacing line 58 of gr_quadrature_demod_cf:

          out[i] = d_gain * gr_fast_atan2f(imag(product), real(product));


with

        out[i] = d_gain * atan2f(imag(product), real(product));

and see if the problem persists?  When doing very high oversampling like
you are, the difference in phase angles between successive samples is
very small.  If the error when doing the lookup table interpolation
changes a bit when crossing over the endpoints of the table, you could
see this sort of effect.  You'll notice that the errors are always at
the same point in the diagram, around the mid-level, which is where the
frequency is lowest.

Matt





reply via email to

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