[USRP-users] Extending 'tx_sample_from_file ' to send multiple files over multiple TX

Rob Kossler rkossler at nd.edu
Thu Feb 7 19:43:47 EST 2019

On Thu, Feb 7, 2019 at 1:36 PM Ali Dormiani via USRP-users
<usrp-users at lists.ettus.com> wrote:
> 1. 1.25 Ms/s would be nice but lower is ok. We are trying to sound some channels as a test so bandwidth is not a big deal.
This rate seems low enough that it should work streaming from the N310
CPU.  The ARM <> FPGA link should be able to handle 4 channels at 1.25
MS/s.  I know that you previously said that you got Overruns even at
the lowest rate, but this to me is an indication that something else
is wrong.

> 2. If gnuradio can run on the arm cpu then thats great! We already have python files (made by gr-companion) so all we would need to do is make a custom N310 filesystem that has gnuradio on it?
gnuradio should already be on the n310 file system.  I'm pretty sure
that the stock file system has it.

> But why would the ARM cpu be too weak to stream via UHD yet still be good enough to run gnuradio enabled python files? I'm not a computer scientist but python is a lot slower than a low level c++ api right?
You're right, it wouldn't be.  But, I don't believe that the ARM is
too weak for these sample rates.  It should work with both c++ (such
as example programs) and python.

I would focus on what is going wrong that you can't even get these
samples rates.  Perhaps try the benchmark_rate example program.  Once
you fix whatever problem exists, you should be able to use gnuradio to
stream multiple channels as you desire.


More information about the USRP-users mailing list