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
On Friday, January 16, 2015, Marcus Müller <[email protected]> wrote: > :) > > 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 > > On 01/16/2015 06:45 PM, Jon West wrote: > > 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> 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 >> >> On 01/16/2015 06:13 PM, Jon West wrote: >> >> 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 >> >> >> _______________________________________________ >> Discuss-gnuradio mailing [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
