I've created an OOT module with a little utility I use to print peak IQ levels. This allows for precise setting of the gain to insure IQ levels are within +1/-1.

https://github.com/drmpeg/gr-iqlevels

Ron

On 07/07/2017 11:28 AM, Ron Economos via USRP-users wrote:

You can change the gain setting on the interpolating FIR filter to accomplish this.

The QT GUI Histogram Sink can be used to set a gain value that limits the IQ values to +1/-1.

Ron

On 07/07/2017 10:20 AM, Michael Carosino via USRP-users wrote:
Hi Marcus,

you are correct, reducing the magnitude did seem to fix the issue. I am wondering though, the gnuradio constellation modulator hier block also seems to suffer from the same issue and doesn't have any options for reduced magnitude output - do most people just throw in a downstream block to reduce the magnitude? Also, is there any reference that speaks a bit about the scaling issues that can happen with the USRP's or is that the just type of thing you learn on the fly?

Thanks,
Mike

    Date: Thu, 06 Jul 2017 21:43:54 -0400
    From: "Marcus D. Leech" <mle...@ripnet.com
    <mailto:mle...@ripnet.com>>
    To: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
    Subject: Re: [USRP-users] Random errors while transmitting certain
            BPSK/QPSK types on x310s
    Message-ID: <595ee75a.4070...@ripnet.com
    <mailto:595ee75a.4070...@ripnet.com>>
    Content-Type: text/plain; charset="windows-1252"; Format="flowed"

    On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
    > A quick update to this question with more info. I did some further
    > analysis by capturing the received I/Q data from the USRP
    Source block
    > when transmitting the BPSK that works without errors (symbols are
    > 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that
    gives
    > errors (symbols are +1/-1). You can see in the attached image
    there is
    > quite a bit of small magnitude anomalies for the second image (also
    > errors are probably occurring a bit more frequently than I had
    > previously estimated).
    >
    > To me this points to the issue being either something to do
    with the
    > USRP or possibly with the TX chain blocks.
    With a baseband magnitude near 1, scaling
    issues/filtering/interpolation
    issues can combine to produce distortions.
    I usually use a baseband magnitude no greater than 0.9 or so.
    >
    > On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
    <m.caros...@gmail.com <mailto:m.caros...@gmail.com>
    > <mailto:m.caros...@gmail.com <mailto:m.caros...@gmail.com>>> wrote:
    >
    >     Hi all,
    >
    >     running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest
    commit
    >     (tried earlier versions too). I've got a simple tx/rx flowgraph
    >     going on. The simple description is:
    >
    >     Random input data -> Pack 1 Bit->Chunks to
    Symbols->Interpolating
    >     FIR Filter->USRP Sink
    >
    >     USRP Source-> Polyphase Clock Sync -> Costas Loop->
    Constellation
    >     Receiver->Unpack 1 Bit
    >
    >
    >     I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
    >     system works almost perfectly, except that there are single bit
    >     errors occurring (not many, maybe every couple of seconds
    at 500k
    >     samp rate).
    >
    >     Now here's the real strange thing, these errors are ONLY
    present
    >     if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or
    rotated
    >     QPSK/QAM (+1j,-1j,+1,-1)
    >
    >     If I use a BPSK having symbols with real and complex parts like
    >     (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the
    errors
    >     are NOT present.
    >
    >     A couple more notes:
    >     Happens if using different x310s or the same for tx/rx.
    >     Happens even if I try to add a small complex value before
    sending
    >     data to the USRP.
    >     Error always happens as a single bit error (not bursty).
    >
    >     Attached are the constellation plots out of the polyphase clock
    >     sync (PFB) and the costas loop. My guess is the issue is
    either at
    >     the USRP or the Polyphase Clock Sync block.
    >
    >     Anyone seen something like this before? I'll probably start
    diving
    >     in the polyphase clock sync code to figure what's going on.
    >
    >     Thanks,
    >     Mike
    >
    >
    >
    >
    > _______________________________________________
    > USRP-users mailing list
    > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
    >
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>




_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to