Re: Underruns causing USRP to stop transmitting and receiving

On 10/21/2020 03:13 PM, Marcus Müller wrote:
> Hi Jerrid,
>
>
>
> * 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.
This is going to be one of those occasions when the Marcii disagree with
one another.
Prior to the advent of the embedded Python blocks, there was no
convenient way
to do "procedural things outside of the main data flow" within GRC.
This naturally
emerges because of the inherent non-procedural paradigm of GRC--which is
"natural" about 90% of the time--but what of the other 10%? You'd
either need
to write "formal" blocks, or use a "hack" like Function Probes. Like
most tools
they can be used inappropriately, but they are still a useful tool.

SO. Function probes and thoughtful use of the GRC dependency-tree
evaluator let you do
powerful things, even if the "purists" would regard them as a
"hack". They let you
"escape" the rigorous data-flow model of GRC.

Certainly if you find that your probe polling rates are climbing up
above a few 10s of Hz, you
likely should be writing a block (either external OOT, or an embedded
Python block). But
I would disagree with the statement that "you should never use them".



>
> * 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
>>