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 <patchvonbraun@gmail.com>
Sent: Tuesday, October 20, 2020 1:03 PM
To: Jerrid Plymale <jerrid.plymale@canyon-us.com>
Cc: usrp-users@lists.ettus.com
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++.
Probably better served by the discuss-gnuradio list and the chat.gnuradio.org online chat community.
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
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
|