Marcus, Ok, I have moved this discussion to the GNU Radio email list. As far as sampling rate is concerned, we are only running at a 4 MHz sampling rate. I have ran tests with the USRP x310 and the PC we are using for development, and I was able to run a sampling rate of up to the 200 MHz clock rate without issue.
Best Regards, Jerrid From: Marcus D. Leech <[email protected]> Sent: Tuesday, October 20, 2020 1:03 PM To: Jerrid Plymale <[email protected]> Cc: [email protected] Subject: Re: [USRP-users] Underruns causing USRP to stop transmitting and receiving On 10/20/2020 03:53 PM, Jerrid Plymale wrote: Marcus, The problem seems to be related to running the system with the USRP though. Someone who is working on this project with me is able to run the same embedded python block, without the USRP hardware, and gets no Underruns when doing so. We have also been unsuccessful in finding any useful information regarding potential causes and solutions from GNU Radio and USRP documentation. Best Regards, Jerrid Well, an underrun is conceptually simple. It means "you aren't supplying me with samples at the desired rate, so when I went to grab some samples, there weren't any there". That means your flow isn't supplying them at the desired rate, either due to computational starvation, or a mis-understanding/mis-configuration of things like re-samplers. Some SDRs out there DO NOT REPORT overruns/underruns, so things can "seem" great and not be. Further the computational envelope and requires of the UHD driver may be different-enough from other hardware that is operating at similar rates that you end up with underruns. When you're running at the edge of what can be accomplished with the compute hardware at hand, small differences are what makes the difference. What sample-rates are we talking about? Are you configuring your hardware for a sample-rate it can actually support, for example? Much of this discussion really does belong in the discuss-gnuradio arena, because it comes down to Gnu Radio performance tuning. Also, you mention an embedded processing block--presumably embedded Python? Such blocks CANNOT be run at high sample rates--even if you use numpy to do all your math, the marhsalling and interpreter costs will kill performance compared to a similar block written in C++. From: Marcus D Leech <[email protected]><mailto:[email protected]> Sent: Tuesday, October 20, 2020 12:35 PM To: Jerrid Plymale <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: [USRP-users] Underruns causing USRP to stop transmitting and receiving Probably better served by the discuss-gnuradio list and the chat.gnuradio.org online chat community. Sent from my iPhone On Oct 20, 2020, at 3:30 PM, Jerrid Plymale via USRP-users <[email protected]<mailto:[email protected]>> wrote: Hello All, So I am working on writing an embedded python block in GNU Radio Companion to preform some analysis of RF signals that is received by a USRP x310 and transmitted back out of the USRP after analysis has been done. I have been running into some underruns lately that I have not been able to find a solution for. If I execute some of my analysis functions in the work function of the block, the application underruns and it causes the USRP to stop transmitting or receiving. However, if I execute the functions in separate polling functions that are being used to display values in the GUI, I do not get underruns. I think this might has to do with how often the analysis function is being executed, as the poll functions are only called at a rate of 10 Hz which is controlled by a function probe. Can anyone give me suggestions on what to try to fix the underrun problem, and any resources you can point me to that might help would be appreciated. Best Regards, Jerrid _______________________________________________ USRP-users mailing list [email protected]<mailto:[email protected]> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
