[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Underruns causing USRP to stop transmitting and receiving
From: |
Marcus Müller |
Subject: |
Re: Underruns causing USRP to stop transmitting and receiving |
Date: |
Wed, 21 Oct 2020 21:13:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
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
>