<div dir="ltr"><div>Hi,</div><div><br></div><div>I just realized that even one instance of TX_sample_from_file from the internal Linux is a no go.</div><div><br></div><div>In fact I think I was in a thread about this very subject a few months ago. Someone explicitly said the ARM cpu would be too weak to stream samples.</div><div><br></div><div>Even streaming one file at the lowest possible sampling rate got 100% underflow.</div><div><br></div><div>I'm trying to avoid gnuradio for this situation because that would require borrowing a bunch of laptops and finding some Ethernet to USB adapters.</div><div><br></div><div>I guess that is the best option as my FPGA knowledge is too limited to go down the custom RFNoC route.</div><div><br></div><div>Thanks for the help.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 3:12 PM Rob Kossler <<a href="mailto:rkossler@nd.edu">rkossler@nd.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Ali,<div>A few comments...</div><div>1) perhaps use gnuradio and attach four file source blocks to the usrp.  This is probably the easiest.</div><div>2) perhaps modify the tx_samples_from_file as you suggested.  If you want to go this route, I may be able to dig up some old code where we did this.</div><div>3) In either case above, is there a bandwidth limitation from the N310 CPU to the FPGA that may make these unsuitable?  </div><div>4) perhaps use custom RFNoC image with the 'replay' block.  This would work great if you don't have to control the channel-to-channel relative timing (the replay block doesn't support).  But, the drawback is you would have to be able to compile such an image and you would likely want to use gnuradio/gr-ettus to run on the CPU because it is non-trivial to control a custom RFNoC image from UHD.</div><div><br></div><div>Rob</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 5:15 PM Ali Dormiani via USRP-users <<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello everyone,</div><div><br></div><div>I'm trying to set up a few N310's in neighboring buildings. I want each N310 to be its own 4 TX transmitter. <br></div><div><br></div><div>For space and cost reasons I am putting the waveforms (in binary float32) directly on the SD card filesystem. My goal is to have each N310 send the waveform on loop indefinitely. <br></div><div><br></div><div>So I have 4 .bin files that I want to transmit, one per TX.</div><div><br></div><div>I'm not proficient in c++ but the provided tx_sample_from_file seems to only work with one file-antenna pair.</div><div><br></div><div>Could I make a script that runs 4 duplicate commands with different arguments? I suspect the MPM claiming system would not like this though.</div><div><br></div><div>Otherwise, is modifying the the example c++ (add more file and antenna arguments) the best path forward?</div><div><br></div><div>Thank you all for your time,</div><div><br></div><div>Ali<br></div></div>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div></div>
</blockquote></div>