usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRandom errors while transmitting certain BPSK/QPSK types on x310s
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
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@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
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.carosino@gmail.com
mailto:m.carosino@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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
FYI I've noticed a very similar issue, isolated it to non usrp gnuradio
blocks in tx chain. Specifically the constellation or *psk modulator
blocks. Certain combos produced garbage IQ data(visible as several spikes
in PSD display) at regular intervals (seemingly related to sample rate),
this is visible even with a very simple flowgraph, dumping data to a file,
no USRP involved. I actually changed the underlying data I was modulating
and the bad data appeared at the same position in time no matter how many
times I ran the flowgraph. I did try moving the symbols closer away from
unity, so used something like (-.707, .707) but that didn't change anything.
Still haven't completely eliminated user error, so I was going to try to
make an example flowgraph later today and submit to discuss-gnuradio.
On Jul 6, 2017 9:38 PM, "Michael Carosino via USRP-users" <
usrp-users@lists.ettus.com> 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.
On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino m.carosino@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
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Oh! If that is the case, yes, please do make an example FG, and if you
find the time, also open an issue on
https://github.com/gnuradio/gnuradio/issues .
Thanks!
Marcus
On 07/07/2017 07:19 PM, Anon Lister via USRP-users wrote:
FYI I've noticed a very similar issue, isolated it to non usrp
gnuradio blocks in tx chain. Specifically the constellation or *psk
modulator blocks. Certain combos produced garbage IQ data(visible as
several spikes in PSD display) at regular intervals (seemingly related
to sample rate), this is visible even with a very simple flowgraph,
dumping data to a file, no USRP involved. I actually changed the
underlying data I was modulating and the bad data appeared at the same
position in time no matter how many times I ran the flowgraph. I did
try moving the symbols closer away from unity, so used something like
(-.707, .707) but that didn't change anything.
Still haven't completely eliminated user error, so I was going to try
to make an example flowgraph later today and submit to discuss-gnuradio.
On Jul 6, 2017 9:38 PM, "Michael Carosino via USRP-users"
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> 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.
On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
<m.carosino@gmail.com <mailto:m.carosino@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