[USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Michael Carosino m.carosino at gmail.com
Thu Jul 6 21:36:57 EDT 2017

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.

On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino <m.carosino at gmail.com>

> Hi all,
> running Gnuradio 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170706/20e6e1c7/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_difference.png
Type: image/png
Size: 17867 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170706/20e6e1c7/attachment.png>

More information about the USRP-users mailing list