:) 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/ [2] by me, at least [3] either use pybombs, and do a "pybombs install gr-radar", or just "git clone [4]" [4] https://github.com/kit-cel/gr-radar On 01/16/2015 09:38 PM, Jon West wrote: > I'm playing with your suggestion at the moment, cause I think the > proper approach is to strip things down so that I only need to use my > "work function" without it being in a thread > > On Fri, Jan 16, 2015 at 3:10 PM, Jon West <[email protected] > <mailto:[email protected]>> 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. 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 > > > On Friday, January 16, 2015, Marcus Müller > <[email protected] <mailto:[email protected]>> wrote: > > 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]> 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]> 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] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
