> I just realized that even one instance of TX_sample_from_file from the > internal Linux is a no go. > > 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. > > Even streaming one file at the lowest possible sampling rate got 100% > underflow. > What streaming rates are you hoping to achieve?
> 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. > I'm suggesting running gnuradio on the N310 CPU so you wouldn't need extra computers. There would be no GUI, but you don't need one. > I guess that is the best option as my FPGA knowledge is too limited to go > down the custom RFNoC route. > If you did decide to go the custom RFNoC route, it might not be too bad assuming that 1) you can tolerate random relative timing between the transmit channels so that you can use the existing 'replay' block 2) you can build an FPGA image (requiring Vivado license). Note: I'm not talking about doing any development, just a build. 3) you can modify the existing replay example c++ program which presently only works with 1 Tx channel Rob _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
