What is the minimal transmission time for gnuradio


#1

I am doing some experiment using benchmark_tx. The purpose is to let the
gnuradio to send small packages lasting for about 0.1 ms every 0.1
second.
However, even the payload is set to be " ", the burst time is still
around 0.2
ms. Is there any method will allow to control or detect the transmission
time
accurately? And is that possible to reduce this the minimal burst time?

Thanks a lot,
Ying

Quoting removed_email_address@domain.invalid:

  1. Question on fir filter implementation(gr_fir_ccf_generic) (isulsz)
  2. Changes from 3.1 to 3.2? (Mikael Olofsson)
    Content-Type: text/plain; charset=us-ascii
    src = gr.vector_source_b(cadena,False)
    File “./prueba2.py”, line 13, in init
    src = gr.vector_source_b(cadena,False)
    File

“/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_gengen.py”,

char,std::allocator > const &)

To: removed_email_address@domain.invalid
includes boost 1.37) since there are a
I had the same issue
consider this, if you don’t want to wait Fed11.

etc. It is impossible to give a proper answer to your question, but I
individual application and system. More gain is not always better.
transmit and benchmark_rx.py on another USRP to receive, with pretty
Message: 4
I understand that the output of a FIR filter is the sum of the
acc1 += d_taps[i+1] * input[i+1];

http://www.nabble.com/Question-on-fir-filter-implementation(gr_fir_ccf_generic)-tp23841646p23841646.html

From: Eric B. removed_email_address@domain.invalid
wrote.

On Tue, Jun 02, 2009 at 08:26:55PM +0200, Alberto T. wrote:
it should work.

Subject: Re: [Discuss-gnuradio] About the RFX 2400 daughterboard
daughterboards, both communicating with an antenna, to ensure proper
maximize this distance, but I can only go as far as a few feet apart. Is

Yes, quite a bit of work has been done on this, and I believe at least
Eric
implementation(gr_fir_ccf_generic)
speaking, a convolution, y[n] = \sum_{k from 0 to L-1} h[k] * x[n-k].
acc0 += d_taps[i+0] * input[i+0];
See the .h file:
virtual gr_complex filter (const gr_complex input[]);

I found some API Docu about the analysis filterbank, but still
I hope some developer can insert it to the documentation for the

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a4c57877/analysis-band1.bin

-------------- next part --------------
A non-text attachment was scrubbed…
Name: analysis-band2.eps
Type: image/x-eps
Size: 26371 bytes
Desc: not available
Url :

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a4c57877/analysis-band2.bin

-------------- next part --------------
A non-text attachment was scrubbed…
Name: analysis-cband1.eps
Type: image/x-eps
Size: 25251 bytes
Desc: not available
Url :

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a4c57877/analysis-cband1.bin

-------------- next part --------------
A non-text attachment was scrubbed…
Name: analysis-cband2.eps
Type: image/x-eps
Size: 26687 bytes
Desc: not available
Url :

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a4c57877/analysis-cband2.bin

-------------- next part --------------
A non-text attachment was scrubbed…
Name: analysis-cband3.eps
Type: image/x-eps
Size: 27047 bytes
Desc: not available
Url :

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a4c57877/analysis-cband3.bin


Hi,
Liang


Messenger°²È«±£»¤ÖÐÐÄ£¬Ãâ·ÑÐÞ¸´ÏµÍ³Â©¶´£¬±£»¤Messenger°²È«£¡
http://im.live.cn/safe/
-------------- next part --------------
An HTML attachment was scrubbed…
URL:

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/a8631a67/attachment.html

std::vector<float> t (&taps[i][0],

gr_complex r = filters[imu]->filter
interpolation done and values returned using “filter”?

URL:

http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/9f0450fb/attachment.html


#2

On Wed, Jun 03, 2009 at 06:01:25PM -0400, removed_email_address@domain.invalid wrote:

I am doing some experiment using benchmark_tx. The purpose is to let the
gnuradio to send small packages lasting for about 0.1 ms every 0.1 second.
However, even the payload is set to be " ", the burst time is still around 0.2
ms. Is there any method will allow to control or detect the transmission time
accurately? And is that possible to reduce this the minimal burst time?

benchmark_tx uses the GNU Radio framing/packaging module which does all
kinds of stuff. I recommend setting up your own flow graph if you want
precise control over the transmission time. 0.1 ms should not be a
problem.

However, if you’re sending an n second burst every n seconds, you get
something continuous, right :slight_smile:

MB