discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performing a USRP Packet Loopback


From: Aditya Arun Kumar
Subject: Re: Performing a USRP Packet Loopback
Date: Wed, 20 Jan 2021 14:48:20 +0530

Can you downgrade to a lower version of UHD and check it? And in the case of the loopback test, can you please check by attaching SMA cables first before attaching your antennas?
I remember having the OR, UR in my srsLTE works, one of the ways I did on fixing it was by using something that goes like small telecom Linux kernel something...
And with reference to your buffer sizes, you might have to edit and rebuild your flowgraph for new specifications given here https://wiki.gnuradio.org/index.php/Handling_Flowgraphs. Good Luck.

On Wed, Jan 20, 2021 at 10:44 AM Jada Mariano Berenguer <berenguj@uci.edu> wrote:
Hi, I realized that in my packet loopback example, I didn't connect any of the QT GUI sinks after the USRP source. The updated flow graph is attached in screenshot0. After I connected them, I ran the packet loopback example on my MacBook Air using one B210 board with TX/RX and RX2 antennas attached and got the results attached in screenshot1, but still received underruns as printed out in the terminal in the bottom left corner. I also ran the example with two B210 boards with a TX/RX antenna on one and a RX2 antenna on the other and got slightly different results. Instead, the third graph was just a straight horizontal line and still ran into underruns. I also ran the same program with a Raspberry Pi 4 with one B210 board and got similar results. So I don't think it's an issue concerning computer power. 

Also, I was wondering what you meant by "for a loopback flow at low rates you may need to alter the internal buffer sizes in your flow-graph to prevent TX starving for samples because the RX buffers are still filling. But this is not a distinctly USRP problem and has more to do with GnuRadio". How would I alter the internal buffer sizes and what would I need to change it to?

Are there any other suggestions you have for me to successfully get this loopback example running?

Thanks!

On Tue, Jan 19, 2021 at 1:36 PM Marcus D Leech <patchvonbraun@gmail.com> wrote:
Keep in mind that the Pi 3b isn’t that powerful. So running a modulate+demodulator loopback flow may be too much for it, even at low rates. 

Also for a loopback flow at low rates you may need to alter the internal buffer sizes in you flow-graph to prevent TX starving for samples because the RX buffers are still filling. But this is not a distinctly USRP problem and has more to do with GnuRadio. 

Sent from my iPhone

On Jan 19, 2021, at 3:37 PM, Jeff Long <willcode4@gmail.com> wrote:


The USRP can not operate at a rate of 5k samples/sec. Minimums are usually around 250k or 500k (can't remember for that model).

On Tue, Jan 19, 2021 at 2:57 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:
Hi, I've been trying to verify the function of my B210 Ettus board. 

The first thing I did was use the UHD benchmark, receiving samples, and transmitting samples examples found here. When running these examples, I had overruns (O's) and underruns (U's), even as I tried adjusting the sample rates. 

Next, I decided to try to find another way to verify the function of the B210. I want to create a simple flow graph that will send a text file to the B210 and have the B210 receive it, and then transmit the same file back out, like a loopback example. I came across the GNURadio digital/packet_loopback_hier.grc example from this message thread. I was able to run the packet loopback example on its own but when I replaced the Channel Model block with USRP Sink and Source blocks, I ran into overruns and underruns. I tried changing the sample rates and gains, but still got O's and U's. I was wondering what I could do to fix this? I've attached an image of the edited packet loopback example with the USRP blocks as well. 

Thanks in advance! 


--
S. Aditya Arun Kumar
+919123517465

reply via email to

[Prev in Thread] Current Thread [Next in Thread]