QPSK Receiver and Processing Power

Hello all,

I am testing a QPSK Tx/Rx I made in grc across two USRP N210’s. I can
demodulate and decode the data fine at the receiver to produce the bits
I
transmitted. The problem is, when watching the frequency sink at the
output
of the USRP source (picture attached), there is typically 4 seconds of
latency between making a change at the transmitter and seeing the change
at
the frequency sink block. I’m worried this is a bad sign of things to
come.

My sample rate is already near the lower limit of what the USRP N210
requires (200k). At his rate, I don’t see any D’s being produced in the
terminal over short run times. I haven’t left the flowgraph running for
a
long time. When I increase the sample rate to 400k, I begin seeing D’s
in
the terminal. I noticed that when I run the python script for the
receiver,
whichever core it is currently running on pegs at 100% usage.

My question is, looking at my receiver flowgraph, would you think this
design should push the limits of a good laptop? Would you believe I
could
be constrained to near the lowest sample rate limit with this design?

Laptop Specs: HP Elitebook 8570w, Core i7, 16 GB RAM, Ubuntu 14.04

I would be interested in hearing what sample rates other peoples QPSK
radios run at with a USRP N210 and similar computer.

Thanks,
Rich

On 2/18/15, 6:45 PM, Richard B. wrote:

Hello all,

I am testing a QPSK Tx/Rx I made in grc across two USRP N210’s. I can
demodulate and decode the data fine at the receiver to produce the bits
I transmitted. The problem is, when watching the frequency sink at the
output of the USRP source (picture attached), there is typically 4
seconds of latency between making a change at the transmitter and seeing
the change at the frequency sink block. I’m worried this is a bad sign
of things to come.

Richard,

The lag is not due to processing power, but instead due to buffering
latency. Every flow between blocks has a default buffer size of 64k
bytes. This means that the LOWER sample rates will take longer to
traverse the buffer.

The latest versions of GRC include a block parameter to restrict the
buffer size. This should be set to a much lower value than the default
for the portions of the flowgraph that are dealing with packed or
unpacked data bits, as these are at a MUCH lower rate than the I/Q
samples going into the demodulator.

@(^.^)@ Ed

Hello Rich,

although Ed commented on the latency issue, regarding your performance
issue my 2 pence: From my experience, using a time domain equalizer with
100 taps is a huge computational burden. Imagine: You are expecting
significant echos (to be equalized) of 100*4/250kHz=1,6 ms. I do not
know your application, but for wireless this is a whole lot.

BTW: I am about to use exactly your computer USRP setup.

Best regards

Stephan Ludwig

Robert Bosch GmbH
Corporate Sector Research & Advance Engineering, Communication
Technology (CR/AEH4)
Renningen
70465 Stuttgart
GERMANY
www.bosch.comhttp://www.bosch.com

Tel. +49(711)811-8809
Fax +49(711)811-1052
Mobile +49(172)5630639
[email protected]mailto:[email protected]

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
HRB 14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
Dr. Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr.
Dirk Hoheisel, Christoph Kübel,
Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller
Von: discuss-gnuradio-bounces+stephan.ludwig2=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+stephan.ludwig2=removed_email_address@domain.invalid]
Im Auftrag von Richard B.
Gesendet: Donnerstag, 19. Februar 2015 00:45
An: [email protected]
Betreff: [Discuss-gnuradio] QPSK Receiver and Processing Power

Hello all,
My question is, looking at my receiver flowgraph, would you think this
design should push the limits of a good laptop? Would you believe I
could be constrained to near the lowest sample rate limit with this
design?
Laptop Specs: HP Elitebook 8570w, Core i7, 16 GB RAM, Ubuntu 14.04

I would be interested in hearing what sample rates other peoples QPSK
radios run at with a USRP N210 and similar computer.
Thanks,
Rich

Thanks Stephan, that was a very good point to make. I have reduce the
number of taps in my equalizer.

Unfortunately, this hasn’t fixed the issue I spoke of (surprisingly). I
am
seeing dropped packets at sample rates of 200k, on and off, and HUGE
latency between making a change at the transmitter and seeing it at the
receiver. I am beginning to suspect an underlying network issue. My
setup
is an old cheap gigabit switch which connects two N210’s to my laptop. I
think something in that domain isn’t performing as it should. I will dig
further.

v/r,
Rich

On Thu, Feb 19, 2015 at 12:01 AM, Ludwig Stephan (CR/AEH4) <