I had a similar issue to this with 4.0.0 a couple of months ago, posted
on this group and told I would have to wait for the next release where
it would hopefully be fixed.
So maybe it's still there, I had to revert to 3.9.7.
The issue was with high rates (20M+ on my hardware) causing
rx_samples_to_file to hang, as well as uhd_fft, so it was not a
GnuRadio issue.
HTH,
Dave
On 20/10/2020 21:03, Marcus D. Leech via USRP-users wrote:
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 <patchvonbr...@gmail.com>
*Sent:* Tuesday, October 20, 2020 12:35 PM
*To:* Jerrid Plymale <jerrid.plym...@canyon-us.com>
*Cc:* usrp-users@lists.ettus.com
*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
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
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
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com