Re: Underruns causing USRP to stop transmitting and receiving

[Marcus Müller]

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
>