Hi Jon, On 01/16/2015 08:19 PM, Jon West 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 > > On Friday, January 16, 2015, Marcus Müller <[email protected] > <mailto:[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 list >>> [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
