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!
|