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 >
