Hi -
I’m having some trouble configuring a flowgraph. In my flowgraph, there
are two paths for data. In one path, the data goes through a gnuradio
block that is lightweight enough to process the data in real-time. In
the other path, there is a gnuradio block that is much more
computationally demanding. My goal is to maintain the real-time
operation of the first path (i.e. not have the second path block). For
my needs, the second path does not need to run in real-time, nor does it
need to operate on all of the data (just sections of it every so often).
I tried to implement this functionality by using a keep_m_in_n block on
the more demanding path. In my flowgraph, I made ‘n’ and integer
multiple of ‘m’, and it works up to a specific multiple that does not
meet my needs. In other words, the multiple is not large enough to
maintain real-time operation for the first path.
Rather than posting a rather complicated flowgraph, I was able to
re-create the error that I’m seeing with a much simpler flowgraph. A
screen cap from from grc file, and the grc file itself are attached. In
the example, there are still two data paths, coming from two sources.
In one path, the two sources are simply summed. In the other path, the
two sources go through keep_m_in_n blocks before being multiplied
together (this path mimics the more computationaly complex path). In
this example, the ‘m’ is set to 750e3, and the ‘n’ is an integer
multiple of ‘m’. ‘NBUF’ is the multiplier used in the flow graph, such
that ‘n = m*NBUF’. When I set NBUF to 2 or below, things run. When
NBUF is set to 3 (or higher) the flowgraph does not run, and I get the
following error for each keep_m_in_n block (for NBUF=3):
sched: <block keep_m_in_n (7)> is requesting more input data than we
can provide. ninput_items_required = 2250000
max_possible_items_available = 1500159 If this is a filter, consider
reducing the number of taps.
So, it seems that the max items available can accommodate just over
NBUF=2 (which would be 1.5e6 samples). As a note, I’m running GNU Radio
3.7 under Ubuntu 12.04 (64-bit). I’ve also double-checked my
sysctl.conf settings (e.g. shmmax) and they appear to be ok (I’m using a
very capable, multi-core server). Searching through some old posts, I
happened upon:
http://gnuradio.4.n7.nabble.com/sched-is-requesting-more-input-data-than-we-can-provide-td45898.html
, which shows a similar problem. The resolution was to use
set_relative_rate, but I’m not sure how I would do that within grc?
Further, when I replace the keep_m_in_n blocks with decimators
(specifically the Decimating FIR Filter), and use NBUF as the
decimation, then everything runs just fine. Am I simply doing something
very silly? Is there a better recommendation for the flowgraph
architecture?
Best,Rob
On 02/28/2014 01:17 AM, Rob M. wrote:
NBUF is set to 3 (or higher) the flowgraph does not run, and I get the
following error for each keep_m_in_n block (for NBUF=3):
You get that same error even if you just connect the keep-block to a
null sink and source.
very capable, multi-core server). Searching through some old posts, I
happened upon:
Even with a large shmmax, buffer sizes are ultimately limited.
http://gnuradio.4.n7.nabble.com/sched-is-requesting-more-input-data-than-we-can-provide-td45898.html
, which shows a similar problem. The resolution was to use
set_relative_rate, but I’m not sure how I would do that within grc?
Further, when I replace the keep_m_in_n blocks with decimators
(specifically the Decimating FIR Filter), and use NBUF as the
decimation, then everything runs just fine. Am I simply doing something
very silly? Is there a better recommendation for the flowgraph
architecture?
keep_m_in_n uses set_output_multiple() and hardcodes the relative rate
in forecast(). This makes the general_work() function very easy to
implement, since both the input and output buffer are already aligned to
the data.
The block wasn’t designed for massive buffers like you need. This would
require rewriting the block to keep states, and simply operate on as
much buffer space is available. For small n and m, that might be
inefficient.
If you want to try this, I recommend creating your own keep-block in an
OOT, copying the code, switching set_output_multiple() to
set_relative_rate() and then adding states to your work function.
I can’t see an easy way to do that with stock GR blocks right now.
M