# Threaded GRC blocks **URL:** \ **Category:** GNU Radio\ **Created:** [January 16, 2015, 6:14pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850 "2015-01-16T18:14:29Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 16, 2015, 6:14pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/1 "2015-01-16T18:14:29Z")
I’m new to gnu radio, but I am trying to port a thread SDR application in to a GRC block. My application buffers a bunch of data and then performs some signal processing on it that can take up to 500ms. Once processing is complete, the processing thread waits a certain amount of time before reading the buffer and then processing again, meanwhile the main trhread is consuming samples and advancing a sample counter. I was wondering what the best way to implement this as a GRC block. Currently I am creating the thread in the the block constructor and killing it in the destructor. I’ve done a search to try and find a solution to this but not finding much, or constantly be directed at the same results that don’t help ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 16, 2015, 6:28pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/2 "2015-01-16T18:28:47Z")
Hi Jon, I’ll try to structure this and reply in-text, so we can get to a mutual understanding faster 🙂 > My application buffers a bunch of data and then performs some signal > processing on it that can take up to 500ms. Does that mean it takes up to 0.5s worth of sampled signal, or does just the computation take that long? Is there something like a minimum block size of samples that your algorithm needs? Here, a bit of info on what you’re actually doing would be nice. > Once processing is complete, the processing thread waits a certain > amount of time before reading the buffer and then processing again, > meanwhile the main trhread is consuming samples and advancing a sample > counter. GNU Radio will do exactly that for you: you just write a block that transforms a set of input items to a set of output items, and GNU Radio cares about how to fill your input buffer, when to call you, how to inform you how much items there are to process, and how to notify your downstream flowgraph neighbors about new data. > I was wondering what the best way to implement this as a GRC block. Depends on what you do in that block. I have my doubts about your 500ms computation step not being split into smaller processing steps; but the feasibility of that completely depends on the actual thing you want to do… > Currently I am creating the thread in the the block constructor and > killing it in the destructor. That sounds a bit like you’re doing GNU Radio wrong. Your block is already running in a thread of its own – that’s what the thread-per-block scheduler does for you 😉 Greetings, Marcus ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 16, 2015, 6:47pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/3 "2015-01-16T18:47:24Z")
Thanks for the reply. I’m doing a ranging application, and the wake up times are related to the signal period of my ranging signal. The application can take up to 500ms to search for my reference signal in certain conditions and that can be improved with some prediction, but the first go round can take a while. I have no doubt I’m doing GNU radio wrong, but I’m a bit confused as to how to implement this otherwise, as I don’t want my processing completed on every block coming in and I don’t want samples to stop while I’m processing On Fri, Jan 16, 2015 at 12:24 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 1:22pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/4 "2015-01-17T13:22:17Z")
Thanks for the reply again, I’m still a little confused. I have a process interval of 1 second, meaning every 1 seconds I grab n samples and run my ranging algorithm which can take a while a little while, in the mean time I need to keep track of the absolute sample count so I know the sample number of the first sample in those n samples so that I ca keep track of time , everything I see says every chunk of data coming in is processed. So I’d still need my block to keep track of every sample coming in, but only use a buffer when I need to based on time so something needs to keep counting samples while something else waits, and I don’t know how to do that in two blocks ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 1:42pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/5 "2015-01-17T13:42:16Z")
Hi Jon, On 01/16/2015 08:19 PM, Jon W. wrote: > Thanks for the reply again, I’m still a little confused. I have a > process interval of 1 second, meaning every 1 seconds I grab n samples > and run my ranging algorithm which can take a while a little while, in > the mean time I need to keep track of the absolute sample count so I > know the sample number of the first sample in those n samples so that > I ca keep track of time , everything I see says every chunk of data > coming in is processed. > No, you don’t have to keep track of anything; GNU Radio does that for > you. If you’re in a block, you can call the nitems\_read (or > nitems\_written) methods, which will give you the number of consumed (or > produced) so far. > So I’d still need my block to keep track of every sample coming in, > but only use a buffer when I need to based on time so something needs > to keep counting samples while something else waits, and I don’t know > how to do that in two blocks > I think I don’t really understand your point, I’m afraid. > If I get you correctly, though, then what you want to do is not to > continously stream samples, and process every one of them, but look at > short “bursts” of n samples in regular intervals of let’s say 500ms. > You could do something RF source block (@f\_sample) → stream\_to\_vector (vectors of n) → keep\_n\_in\_m (keep 1 out of every 500ms/f\_sample/n vectors) → your block → visualization\_or\_file\_sink\_or\_something\_of\_the\_like Would that fit what you would need, somehow? Greetings, Marcus ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 12:06pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/6 "2015-01-17T12:06:08Z")
🙂 > I have no doubt I’m doing GNU radio wrong, > I might have put that a little harsh; sorry. You’re not doing it wrong, > you just weren’t aware of a few core concepts of the GNU Radio > scheduler: > but I’m a bit confused as to how to implement this otherwise, as I > don’t want my processing completed on every block coming in and I > don’t want samples to stop while I’m processing > And exactly that’s the kind of worries GNU Radio strives to take away > from you. > All blocks in your flow graph can run in parallel. So while your block > is still working, the upstream block is already processing what is going > to be the input of your block’s next iteration, while your downstream > block is busy processing what your block produced the last time. > Also, GNU Radio uses input and output buffers, which are identical to > your upstream block’s output and your downstream blocks’ input buffers, > respectively, and makes sure you know how many space there is in these > buffers (or how much samples there are for you to process). This all is done transparently in separate threads, so you don’t have to worry about it. I hope that illustrates why I think that spawning your own thread is not necessary; it’s already being done for you, and in a manner that allows you not to care about the correct transportation of data, notifying threads, ensuring data flow and proper multiprocessor scaling – this all happens behind the curtains. To the user, each block only has to care about processing its input as fast as possible to produce output; the scheduler will coordinate everything else. In fact, GNU Radio even encourages you to think about how you can further break down your algorithm, to as well avoid re-inventing the wheel, and to use optimized algorithms. Maybe you do an FFT inside? Well, then use the existing GNU Radio FFT. Are you multiplying to sample streams? Do that with a GNU radio multiply block, and you’ll profit from SIMD-optimized routines. Also, when breaking down an algorithm into existing and to-be-written blocks, you increase the level of parallelity, which generally is a good thing, because buffering necessary to avoid congestion when a step takes especially long will then be automatically distributed between a lot of blocks. Greetings, Marcus ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 2:49pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/7 "2015-01-17T14:49:00Z")
🙂 Looking forward to your application (if you plan to release it)! Since you were talking about ranging: Do you know of gr-radar [1]? It already comes with quite a set of algorithms and visualizations, and is generally considered to be awesome [2]. Installation is quite straightforward[3], and the source is available under [4]. Greetings, Marcus [1] [https://grradar.wordpress.com/](https://grradar.wordpress.com/) [2] by me, at least [3] either use pybombs, and do a “pybombs install gr-radar”, or just “git clone [4]” [4] [GitHub - kit-cel/gr-radar: GNU Radio Radar Toolbox](https://github.com/kit-cel/gr-radar) ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 2:40pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/8 "2015-01-17T14:40:52Z")
Hi Jon, On 01/16/2015 09:10 PM, Jon W. wrote: > So I think I should probably say I have a working function that I want > to port in to a Grc block, and given my time constraints, and other > existing frame work, it does not lend itself to be completely broken > down and reconstituted in Grc properly. > That’s pretty understandable 🙂 > The way our frameworkworks lends itself well to the structure of > blocks except in this case where our “work” function is processed in a > new thread that reads time and uses it to wake up and read samples > from a buffer while the function that starts the thread keeps time and > costumes samples to copy them in to the buffer the work thread uses > That is really what GNU Radio does: Wake the thread of a block when new > data is available, and makes that thread execute the block’s work > function. > So all you’d had to do is replace the logic that gets you the right > samples by just using the pointer to the input items that you get when > your work() is called. At this point, though, this all feels a bit like idle chatter, because it’s hard to discuss the concepts of two frameworks with the other not really having had a chance to get a feeling for how things work in the respective environment. I think the quickest way for you to actually get going is to write your first block (which should ideally be a bit simpler than what you want to do in the end); I really suggest doing the guided tutorials [1]; if installation is already done, after a couple of minutes you should be at the point where you can start your own block in python, and a couple minutes more and you’re in the part where C++ blocks are introduced. I recommend going through the tutorials in order, though, since the C++ stuff refers to the python stuff, which refers to the GRC stuff. Greetings, Marcus [1] [https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided\_Tutorials](https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials) ---
**Author:** ![jon\_w](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/3e96dc/32.png) [@jon\_w](https://www.ruby-forum.com/u/jon_w)\ **Post date:** [January 17, 2015, 2:55pm UTC](https://www.ruby-forum.com/t/threaded-grc-blocks/233850/9 "2015-01-17T14:55:15Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)