Re: Underruns causing USRP to stop transmitting and receiving

[Marcus D. Leech]

On 10/21/2020 03:57 PM, Marcus Müller wrote:
> But: I fully agree with you, the ability to write signal processing in 
> Python that performs somewhat well is a great boon! And I do recommend 
> that to most beginners, too: Start in Python (unless you already are 
> really more comfortable with C++) and then identify bottlenecks later 
> on. Only if Python really becomes a bottleneck, port to C++. Honestly, 
> you seem to be a good enough software developer. If your work method 
> (which is really the interesting part here) is as straightforward as 
> the other code you shared, then porting that to C++ with the help of 
> the current tutorials should not be that much of a problem. Best 
> regards, Marcus 
Something to be really aware of with Python blocks is that they suffer 
from the GIL problem.   I tripped over this when using an
 embedded Python block for doing real-time trial epoch-folding in a 
pulsar astronomy receiver chain.  You can't effectively
  have them run in parallel like C++ blocks--they'll run in separate 
threads because that's how Gnu Radio schedules blocks.
  But Python has something called the Global Interpreter Lock, and this 
will bite you if you're trying to get N times the throughput
  by having N Python block instances all running in different threads 
(as is natural with Gnu Radio).  This is not something that the
  GR framework can easily "step around", so, you have to be aware of it.

Having said that, I'm happily doing epoch folding and incoherent 
de-dispersion at audio rates (10-20Ksps) into a single embedded
  Python block and it works fine, even on my 10-year-old laptop. That's 
"fronted" by some standard Gnu Radio blocks that are
  all C++, etc.  But by the time the Python sees the stream, it has 
been reduced from at much as 25Msps down to a "trickle"
  at audio rates.   The one complaint I have about embedded Python 
blocks in GR3.7 is that having vector-input with
  the vector length determined at *run-time* doesn't work.  So, I had 
to "hack" this so that I feed a scalar stream into the Python block,
  and it vectorizes internally.  Not that huge a deal, but it would be 
sexier if this "Just Worked(tm)".   Does this work correctly in later
  GR versions--3.8 or 3.9?




> > Best Regards,
> >
> > Jerrid
> >
> > -----Original Message-----
> > From: Marcus Müller <marcus.mueller@ettus.com>
> > Sent: Wednesday, October 21, 2020 12:14 PM
> > To: Jerrid Plymale <jerrid.plymale@canyon-us.com>
> > Cc: Discuss Gnuradio <discuss-gnuradio@gnu.org>
> > Subject: Re: Underruns causing USRP to stop transmitting and receiving
> >
> > Hi Jerrid,
> >
> > thanks for the answer!
> >
> > Let me have a couple of comments, just quickly, in no particular order:
> >
> > * If in doubt, send code as code instead of as screenshot. These screenshots 
> > tell me very little about your software - and they don't really show me the 
> > parts of the code I'm interested in.
> >    I advised some students at uni. The first thing I require them to do is put 
> > their stuff on a git repository that I can access. That way, they can always 
> > tell me what to look at when they have a question. I found this is also a 
> > crucial technique for development outside of an academic setting!
> >
> > * A function probe is really a kludge in GNU Radio and probably shouldn't be 
> > used. You've got very many of these - and that kind of hints at architectural 
> > problems, e.g. you trying to replace message passing with polling. My wild 
> > guess is that you've found a tutorial that advertises the function probe. 
> > Really, that's not meant for signal processing / marshalling purposes.
> >
> > * Yeah, don't do time-critical signal processing in Python. As (the
> > other) Marcus mentioned, Python in this usage is orders of magnitude slower 
> > than just writing this in C++.
> >
> > So, recommendations:
> >
> > 1. Get rid of **all** the function probes. It's not clear why you'd want that - 
> > really, it seems to me that you want to emit a new channel power estimate e.g. 
> > every 10000 samples. That should be a very normal decimating block!
> > 2. In case you don't want to produce output regularly, you'd go with message passing, or 
> > with tagging the estimate to a sample on your estimator's output stream whenever 
> > appropriate (e.g. after receiving a message "please estimate this and that 
> > now"). Tagging would allow you to actually know which sample an estimate belongs to.
> > 3. Python -> C++ if still necessary (quite possible)
> >
> >
> > Best regards,
> > Marcus
> >
> > On 21.10.20 20:58, Jerrid Plymale wrote:
> > > Marcus,
> > >
> > > We are analyzing the average channel power of the USRP, as well as checking to 
> > > see if the signal received is a constant envelope signal, and a handful of 
> > > other functions like narrowband detection and pulsed signal detection. Here is 
> > > a screenshot of the flowgraph:
> > >
> > > [A picture containing graphical user interface  Description
> > > automatically generated]
> > >
> > > And here is a snippet of the average channel power estimator function 
> > > (disregard the function name as that needs to be changed):
> > >
> > > [Text  Description automatically generated]
> > >
> > > So when this function is executed inside the work function of an embedded 
> > > python block, the application underruns, spitting out U's into the terminal 
> > > window. If instead we execute the function outside of the work function, as 
> > > shown below, the application doesn't underrun.
> > >
> > > [Text  Description automatically generated]
> > >
> > > And so the function being used above to execute the average channel power 
> > > estimator is being polled at a 10 Hz rate by a function probe. So are the 
> > > underruns due to polling rate difference between the work function and the 
> > > function probe? Is it something else? Any ideas on how I can get to work in the 
> > > work function without underrunning?
> > >
> > > Best Regards,
> > >
> > > Jerrid