# QPSK Receiver and Processing Power **URL:** \ **Category:** GNU Radio\ **Created:** [February 19, 2015, 12:46am UTC](https://www.ruby-forum.com/t/qpsk-receiver-and-processing-power/234253 "2015-02-19T00:46:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 19, 2015, 12:46am UTC](https://www.ruby-forum.com/t/qpsk-receiver-and-processing-power/234253/1 "2015-02-19T00:46:52Z")
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 ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [February 19, 2015, 5:16am UTC](https://www.ruby-forum.com/t/qpsk-receiver-and-processing-power/234253/2 "2015-02-19T05:16:43Z")
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 ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [February 19, 2015, 9:02am UTC](https://www.ruby-forum.com/t/qpsk-receiver-and-processing-power/234253/3 "2015-02-19T09:02:30Z")
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.com](http://www.bosch.com)[http://www.bosch.com](http://www.bosch.com) Tel. +49(711)811-8809 Fax +49(711)811-1052 Mobile +49(172)5630639 removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](mailto:discuss-gnuradio-bounces+stephan.ludwig2=removed_email_address@domain.invalid)] Im Auftrag von Richard B. Gesendet: Donnerstag, 19. Februar 2015 00:45 An: removed\_email\_address@domain.invalid 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 ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [February 19, 2015, 5:19pm UTC](https://www.ruby-forum.com/t/qpsk-receiver-and-processing-power/234253/4 "2015-02-19T17:19:54Z")
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) \<