On Thu, Feb 7, 2019 at 1:36 PM Ali Dormiani via USRP-users <usrp-users@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 _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
