Hi Jon,
On 01/16/2015 09:10 PM, Jon West 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 framework works 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
On Friday, January 16, 2015, Marcus Müller <address@hidden>
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 <address@hidden> 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
|