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

Ali Dormiani sdormian at eng.ucsd.edu
Fri Feb 8 17:10:10 EST 2019

The N310 stock filesystem does not have gnradio.

You are right that my focus is on the wrong thing. I just tried
benchmark_rate and tx_waveforms and they stream just fine at 1.25Ms/s.

I'm going to go back and read the documentation more carefully. We might be
saving our waveform in a form that UHD does not understand but gnuradio

On Thu, Feb 7, 2019 at 4:43 PM Rob Kossler <rkossler at nd.edu> wrote:

> 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.
> Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190208/f956b8e2/attachment.html>

More information about the USRP-users mailing list