Re: Underruns causing USRP to stop transmitting and receiving

[Marcus Müller]

Hi Jerrid,

On 21.10.20 21:38, Jerrid Plymale wrote:
> Marcus,
> 
> Thanks for the response, but here are some of the issues with some of your 
> suggestions. First off, this is a project I am working on for the company I 
> work for, so I don't believe I can share the entire script with you in a 
> public format as this discussion list set up as, so I am limited in that 
> aspect. 

Well, that's a pity, but even so, sharing snippets as text file is still
way more useful than screenshots. It's pretty awkward for me to open
images from my email client. Code, I read right away. Also, that code
then is searchable, I can format it however I want to help me understand
it and so on... just a suggestion for the future to make helping you
easier. Generally, not being able to share code you need help with is
kind of the old "oh, and that's why keeping your code proprietary is a
bad idea" gotchas ;) (spoken as the FOSS nerd you might occasionally
expect from your beardy GNU Radio maintainer.)

> Second, I am using the function probes because I have tried to use message 
> passing before but I have never been able to get it to work, and no one has 
> been able to give me a simple tutorial on how to create message sinks that I 
> can use to display variables in the GUI in real time. Also, the available 
> instructional information that GNU Radio has put out for message passing is 
> not in depth enough for me to figure out writing my on message sink blocks.

That's a sad state. For GUI visualization purposes, generally, these
probes are still a kludge, but acceptable. But since you're CPU-strapped
and only have a single Python process... try to avoid them.

> Finally, We are developing this system using Python due to is ease of quick 
> development and our teams familiarity with it. I have very little experience 
> writing C++, as do the others working on this project with me. On top of that 
> I do not have a software background, so trying to re write all of this code 
> in C++ while having to teach myself C++ at the same time while having less 
> than two months left on this project to get the system to a functional state  
> is not really feasible.

As said, if still necessary, port to C++. Don't start with that.

> I will also add that I am irritated with this as the mentioned analysis 
> functions are the only ones having problems, we have other machine learning 
> based analysis functions using the tensorflow python library that work 
> without issue in the work function, even though the computational workload of 
> the machine learning is greater than that of a couple summation and averaging 
> functions, at least I would imagine.

Yeah, but guess what: Tensorflow's data processing is written not
written in Python. The earlier you hand of data processing from Python
to something else, the better.
That's one of the underlying principles of GNU Radio, too. TF and GR are
similar in that respect:
In both, you define data processing flowgraphs in Python, and the actual
processing then usually doesn't happen in Python, but in
native/accelerated blocks "under the hood".

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

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