Hi all,
I have a question regarding the timed packets with UHD. Basically I'm
sending packets from a burst tagger into my UHD sink with a tx_time tag,
but after a while I'm getting L's (late packet, if I'm not wrong) at the
output.
I tried changing both the packet size and the sample rate of my f
Hi Sreena,
a quick search in the subjects of the mailing list yielded this thread:
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00439.html
The problem is that the complete PDU has to fit into the buffer, and it
seems that doesn't work.
Now, with the moderate length of 64, this wo
Hi
I ran OFDM transmitter in the grc example using 1024 point fft. following error
was raised after running the grc. Please help to get out of this error..
thread[thread-per-block[7]: ]: Buffer too small
for min_noutput_items
Thanks in advance
Regards
Sreena
On Wed, 2006-07-05 at 09:39 -0700, Eric Blossom wrote:
> On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
> > I'm curious about this statement in
> > $PYTHONPATH/gnuradio/gr/flow_graph.py
> >
> > # We could scan the graph here and determine individual sizes
> > # based
On Wed, 2006-07-05 at 09:39 -0700, Eric Blossom wrote:
> On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
> >
> > Because: One of my simple test apps works 600% faster using 4k buffer
> > instead of 32k, since it doesn't have to wait for stale data to clear.
>
> Chuck, can you point
On Wed, Jul 05, 2006 at 11:25:55AM -0400, Chuck Swiger wrote:
> I'm curious about this statement in
> $PYTHONPATH/gnuradio/gr/flow_graph.py
>
> # We could scan the graph here and determine individual sizes
> # based on relative_rate, number of readers, etc.
>
>
> In the meantime,
I'm curious about this statement in
$PYTHONPATH/gnuradio/gr/flow_graph.py
# We could scan the graph here and determine individual sizes
# based on relative_rate, number of readers, etc.
In the meantime, it would be nice to be able, somehow, to tweak the
global buffer size from in
