[Discuss-gnuradio] what is the minimal transmission time for gnuradio

[ywang06]

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 address@hidden:

> Send Discuss-gnuradio mailing list submissions to
>       address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
>       address@hidden
>
> You can reach the person managing the list at
>       address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>    1. [use of gr.vector_source_b] (Rita's pfc)
>    2. Re: GNU Radio 3.2 Release and Fedora 10 Boost   Library Issue
>       (Alberto Trentadue)
>    3. About the RFX 2400 daughterboard (Ankit Saf)
>    4. Question on fir filter  implementation(gr_fir_ccf_generic) (isulsz)
>    5. Re: [use of gr.vector_source_b] (Eric Blossom)
>    6. Re: Re: GNU Radio 3.2 Release and Fedora 10     Boost Library
>       Issue (Eric Blossom)
>    7. Re: About the RFX 2400 daughterboard (Eric Blossom)
>    8. Re: Question on fir filter      implementation(gr_fir_ccf_generic)
>       (Eric Blossom)
>    9. Re: analysis_filterbank question (Markus Feldmann)
>   10. Re: About the RFX 2400 daughterboard (Ankit S.)
>   11. About synchoronization of usrp2. (=?gb2312?B?1tzBwQ==?=)
>   12. Interpolation and filtering (Ravishankar. M)
>   13. Changes from 3.1 to 3.2? (Mikael Olofsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Jun 2009 11:15:35 -0700 (PDT)
> From: Rita's pfc <address@hidden>
> Subject: [Discuss-gnuradio] [use of gr.vector_source_b]
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hello!
> What I want to do is coding a string with trellis. This is the code I wrote.
> (..)
> f = trellis.fsm("rita.fsm")
> class my_top_block (gr.top_block):
>       def __init__ (self):
>               gr.top_block.__init__(self)
>               cadena= 'asdf'
>               src = gr.vector_source_b(cadena,False)
>               tre = trellis.encoder_bb(f,0)
>               sink_cod_vector = gr.vector_sink_b ()
>               self.connect(src,tre,sink_cod_vector)
> /*/*/*/*/*
> And this is what I get:
>  don't know why I got this message, because I think the use of the
> gr.vector_source is ok.
> Traceback (most recent call last):
>   File "./prueba2.py", line 21, in <module>
>     my_top_block().run()
>   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",
> line 9306, in vector_source_b
>     return _gnuradio_swig_py_gengen.vector_source_b(*args)
> NotImplementedError: Wrong number of arguments for overloaded function
> 'vector_source_b'.
>   Possible C/C++ prototypes are:
>     gr_make_vector_source_b(std::vector<unsigned
> char,std::allocator<unsigned char > > const &,bool,int)
>     gr_make_vector_source_b(std::vector<unsigned
> char,std::allocator<unsigned char > > const &,bool)
>     gr_make_vector_source_b(std::vector<unsigned
> char,std::allocator<unsigned char > > const &)
>
>
> I don't what I'm doing wrong. Can someone help me?
>
> Thanks
> --
> View this message in context:
> http://www.nabble.com/-use-of-gr.vector_source_b--tp23837912p23837912.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Jun 2009 20:26:55 +0200 (CEST)
> From: Alberto Trentadue <address@hidden>
> Subject: [Discuss-gnuradio] Re: GNU Radio 3.2 Release and Fedora 10
>       Boost   Library Issue
> To: address@hidden
> Cc: Discuss GNU Radio List <address@hidden>
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain;charset="UTF-8"
>
> On Tue, 2009-06-02 at 08:36 -0700, Mark J. Yusko wrote:
> I recently tried to compile 3.2 using updated Fedora 10 and ran
> into a "not using boost > 1.35" error during ./config.  With Fedora 11 to be
> released in a few days, I find it
> preferable to wait for this release and then upgrade my system to 11 (which
> includes boost 1.37) since there are a
> multitude of RPM dependencies to work out with 10.
> >
> > Boost 1.35 RPM and 1.37 RPM is available to download, but to
> upgrade other RPMs due to there dependency needs is too laborious at this
> time.
> >
> > Mark
>
> Hi
>
> I had the same issue
> when compiling GR 3.2svn on Fedora 9. Note that the requirement is boost >=
> 1.35.
> I managed to solve it by removing the
> RPM 1.34 and installing Boost 1.35.0 compiling it from source.
> btw, when I uninstalled Boost 1.34 rpm, no other rpm
> complained...
> But if you simply compile 1.35 and then update the pkgconfig information, it
> should work.
>
> You may
> consider this, if you don't want to wait Fed11.
>
> Alberto
>
>
> Promozione di Primavera ! Stampa le tue foto nei formati 13x17 e 13x19 a soli
> 0,11 euro.
>
> http://photo.tiscali.it
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Jun 2009 21:10:07 +0200
> From: Ankit Saf <address@hidden>
> Subject: [Discuss-gnuradio] About the RFX 2400 daughterboard
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> So I had a few questions about the RFX 2400 daughterboard, and this what
> Matt Ettus had to say in his email...
>
> >
> > 1.What is the maximum distance I can place two USRPs with the RFX 2400
> daughterboards, both communicating with an antenna, to ensure proper
> transmission, provided they have some line of sight available?
>
> That depends on many many factors, including modulation, antennas, data
> rate, environment, other interferers, how well you've written your code,
> etc.  It is impossible to give a proper answer to your question, but I
> can tell you that a few feet sounds like you are doing something worng.
>
> > 2. I've tried adjusting the gain in the receiver (the maximum gain I could
> use at the receiver for this was 89) and the amplitude in the transmitter
> (while using the benchmark_tx.py and benchmark_rx.py programs) to maximize
> this distance, but I can only go as far as a few feet apart. Is there any
> other way to adjust the gain? Also, the CRC32 was false for all packets
> received. Is there a way to fix that, or should that not be an issue?
>
> There is a lot of work involved in creating a proper AGC system for your
> individual application and system.  More gain is not always better.
>
> > Finally, I am trying to implement a simple direction finding algorithm
> using two antennas as receivers in one USRP. Are you aware of any other
> similar work that has already been done in the field?
>
> Yes, quite a bit of work has been done on this, and I believe at least
> one paper was published.
>
>
> To update on the first question...I was using the benchmark_tx.py to
> transmit and benchmark_rx.py on another USRP to receive, with pretty
> much default settings and carrier frequency of 2.45GHz.
> Any comments on that?
> --
> Posted via http://www.ruby-forum.com/.
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 2 Jun 2009 14:49:58 -0700 (PDT)
> From: isulsz <address@hidden>
> Subject: [Discuss-gnuradio] Question on fir filter
>       implementation(gr_fir_ccf_generic)
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> I have two questions regarding to the FIR filter implementation.
> I understand that the output of a FIR filter is the sum of the
> multiplications of filter taps and previous (and current) inputs, or simply
> speaking, a convolution, y[n] = \sum_{k from 0 to L-1}  h[k]  *  x[n-k].
>
> Take gr_fir_ccf_generic for example, the code introduce a parameter
> N_UNROLL(= 2 or 4) and seems to break the summation into N_UNROLL parts:
> acc0,acc1,acc2,acc3 (if U_UNROLL == 4). and then sum them together. What is
> the reason for doing this?
>
> Another confusion is that, the summation is like this:
> acc0 += d_taps[i+0] * input[i+0];
> acc1 += d_taps[i+1] * input[i+1];
> acc2 += d_taps[i+2] * input[i+2];
> acc3 += d_taps[i+3] * input[i+3];
>
> Why here is input[i PLUS SOMETHING]? I think these are FUTURE(but not
> PREVIOUS) values of the current input (the current input is input[0] if I
> understand the code correctly).
>
> Thank you very much!
> --
> View this message in context:
>
http://www.nabble.com/Question-on-fir-filter-implementation%28gr_fir_ccf_generic%29-tp23841646p23841646.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 2 Jun 2009 14:59:54 -0700
> From: Eric Blossom <address@hidden>
> Subject: Re: [Discuss-gnuradio] [use of gr.vector_source_b]
> To: Rita's pfc <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2009 at 11:15:35AM -0700, Rita's pfc wrote:
> >
> > Hello!
> > What I want to do is coding a string with trellis. This is the code I
> wrote.
> > (..)
> > f = trellis.fsm("rita.fsm")
> > class my_top_block (gr.top_block):
> >     def __init__ (self):
> >             gr.top_block.__init__(self)
> >             cadena= 'asdf'
>
> Use this instead:
>
>               cadena = map(ord, 'asdf')
>
> >             src = gr.vector_source_b(cadena,False)
> >             tre = trellis.encoder_bb(f,0)
> >             sink_cod_vector = gr.vector_sink_b ()
> >             self.connect(src,tre,sink_cod_vector)
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Jun 2009 15:01:36 -0700
> From: Eric Blossom <address@hidden>
> Subject: Re: [Discuss-gnuradio] Re: GNU Radio 3.2 Release and Fedora
>       10      Boost Library Issue
> To: Alberto Trentadue <address@hidden>
> Cc: Discuss GNU Radio List <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2009 at 08:26:55PM +0200, Alberto Trentadue wrote:
> > Hi
> >
> > I had the same issue
> > when compiling GR 3.2svn on Fedora 9. Note that the requirement is boost >=
> 1.35.
> > I managed to solve it by removing the
> > RPM 1.34 and installing Boost 1.35.0 compiling it from source.
> > btw, when I uninstalled Boost 1.34 rpm, no other rpm
> > complained...
> > But if you simply compile 1.35 and then update the pkgconfig information,
> it should work.
> >
> > You may
> > consider this, if you don't want to wait Fed11.
> >
> > Alberto
>
> You can build boost from source and it can coexist with the older
> system version.
>
> See http://gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost
>
> Eric
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 2 Jun 2009 15:03:53 -0700
> From: Eric Blossom <address@hidden>
> Subject: Re: [Discuss-gnuradio] About the RFX 2400 daughterboard
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2009 at 09:10:07PM +0200, Ankit Saf wrote:
> > So I had a few questions about the RFX 2400 daughterboard, and this what
> > Matt Ettus had to say in his email...
> >
> > >
> > > 1.What is the maximum distance I can place two USRPs with the RFX 2400
> daughterboards, both communicating with an antenna, to ensure proper
> transmission, provided they have some line of sight available?
> >
> > That depends on many many factors, including modulation, antennas, data
> > rate, environment, other interferers, how well you've written your code,
> > etc.  It is impossible to give a proper answer to your question, but I
> > can tell you that a few feet sounds like you are doing something worng.
> >
> > > 2. I've tried adjusting the gain in the receiver (the maximum gain I
> could use at the receiver for this was 89) and the amplitude in the
> transmitter (while using the benchmark_tx.py and benchmark_rx.py programs) to
> maximize this distance, but I can only go as far as a few feet apart. Is
> there any other way to adjust the gain? Also, the CRC32 was false for all
> packets received. Is there a way to fix that, or should that not be an issue?
> >
> > There is a lot of work involved in creating a proper AGC system for your
> > individual application and system.  More gain is not always better.
> >
> > > Finally, I am trying to implement a simple direction finding algorithm
> using two antennas as receivers in one USRP. Are you aware of any other
> similar work that has already been done in the field?
> >
> > Yes, quite a bit of work has been done on this, and I believe at least
> > one paper was published.
> >
> >
> > To update on the first question...I was using the benchmark_tx.py to
> > transmit and benchmark_rx.py on another USRP to receive, with pretty
> > much default settings and carrier frequency of 2.45GHz.
> > Any comments on that?
>
> What kind of antennas are you using?
>
> Eric
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 2 Jun 2009 15:15:44 -0700
> From: Eric Blossom <address@hidden>
> Subject: Re: [Discuss-gnuradio] Question on fir filter
>       implementation(gr_fir_ccf_generic)
> To: isulsz <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2009 at 02:49:58PM -0700, isulsz wrote:
> >
> > I have two questions regarding to the FIR filter implementation.
> > I understand that the output of a FIR filter is the sum of the
> > multiplications of filter taps and previous (and current) inputs, or simply
> > speaking, a convolution, y[n] = \sum_{k from 0 to L-1}  h[k]  *  x[n-k].
> >
> > Take gr_fir_ccf_generic for example, the code introduce a parameter
> > N_UNROLL(= 2 or 4) and seems to break the summation into N_UNROLL parts:
> > acc0,acc1,acc2,acc3 (if U_UNROLL == 4). and then sum them together. What is
> > the reason for doing this?
>
> Manual loop unrolling like this allows some compilers to generate
> better code.  The dependency chain is shorter.
>
> > Another confusion is that, the summation is like this:
> > acc0 += d_taps[i+0] * input[i+0];
> > acc1 += d_taps[i+1] * input[i+1];
> > acc2 += d_taps[i+2] * input[i+2];
> > acc3 += d_taps[i+3] * input[i+3];
> >
> > Why here is input[i PLUS SOMETHING]? I think these are FUTURE(but not
> > PREVIOUS) values of the current input (the current input is input[0] if I
> > understand the code correctly).
>
> The delay line is implicitly contained in the input.
>
> See the .h file:
>
>   /*!
>    * \brief compute a single output value.
>    *
>    * \p input must have ntaps() valid entries.
>    * input[0] .. input[ntaps() - 1] are referenced to compute the output
> value.
>    *
>    * \returns the filtered input value.
>    */
>   virtual gr_complex filter (const gr_complex input[]);
>
>
> FWIW, the code you're looking at is the guts of the generic C++
> implementation of the filter.  The GNU Radio block that corresponds is
> gr_fir_filter_ccf.{h,cc}
>
>
> Eric
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 03 Jun 2009 01:41:52 +0200
> From: Markus Feldmann <address@hidden>
> Subject: [Discuss-gnuradio] Re: analysis_filterbank question
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Eric Blossom schrieb:
> > On Sat, May 30, 2009 at 11:25:06AM +0000, feldmaus wrote:
> >> Eric Blossom <eb <at> comsec.com> writes:
> >>
> >>> On Mon, Jan 05, 2009 at 06:52:56PM +0200, Sebastiaan Heunis wrote:
> >>>
> >>> Unlike what the code would lead you to believe, you have to provide
> >>> the filter taps.  See gr-pager/src/usrp_flex_band.py for a working
> example.
> >>>
> >> I found some API Docu about the analysis filterbank, but still
> >> have some questions to it.
> >
> > You may want to consider just using 3 instances of
> gr.freq_xlating_fir_filter_ccf
> >
> thank you,
>
> only a gift to the community.
>
> i made some graphs of a analysis filterbank with different filters.
> I hope some developer can insert it to the documentation for the
> analysis filterbank. :-)
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: analysis-band1.eps
> Type: image/x-eps
> Size: 28121 bytes
> Desc: not available
> Url :
>
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
>
> ------------------------------
>
> Message: 10
> Date: Wed, 3 Jun 2009 04:16:08 +0200
> From: "Ankit S." <address@hidden>
> Subject: [Discuss-gnuradio] Re: About the RFX 2400 daughterboard
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> Eric Blossom wrote:
> > On Tue, Jun 02, 2009 at 09:10:07PM +0200, Ankit Saf wrote:
> >>
> >>
> >> To update on the first question...I was using the benchmark_tx.py to
> >> transmit and benchmark_rx.py on another USRP to receive, with pretty
> >> much default settings and carrier frequency of 2.45GHz.
> >> Any comments on that?
> >
> > What kind of antennas are you using?
> >
> > Eric
>
> Omnidirectional ones...the standard ones with a black plastic outside.
> Looks like this http://www.ciudadwireless.com/images/USR5481BCW.jpg
> --
> Posted via http://www.ruby-forum.com/.
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 3 Jun 2009 16:46:31 +0800
> From: =?gb2312?B?1tzBwQ==?= <address@hidden>
> Subject: [Discuss-gnuradio] About synchoronization of usrp2.
> To: <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="gb2312"
>
>
> Hi,
> anybody test the synchronization with reference clock of usrp2? Now with
> command
>
> clocks_enable_test_clk(true, 1);
>
> I still get drifting between J503 and reference clock,is there anybody make
> it works?
>
> Thanks for any given words!
>
> 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
>
> ------------------------------
>
> Message: 12
> Date: Wed, 3 Jun 2009 17:42:48 +0530
> From: "Ravishankar. M" <address@hidden>
> Subject: [Discuss-gnuradio] Interpolation and filtering
> To: <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello all,
>
>
>
>   I have two interpolation and filtering related queries in
> "gri_mmse_fir_interpolator_cc.cc".
>
>
>
> 1) In the code portion:
>
> gri_mmse_fir_interpolator_cc::gri_mmse_fir_interpolator_cc ()
>
> {
>
>   filters.resize (NSTEPS + 1);
>
>
>
>   for (int i = 0; i < NSTEPS + 1; i++){
>
>     std::vector<float> t (&taps[i][0],
> &taps[i][NTAPS]);----------------------------------------(1)
>
>     filters[i] = gr_fir_util::create_gr_fir_ccf
> (t);----------------------------------------------------(2)
>
>   }
>
> }
>
>
>
> Can you let me know what is performed in steps (1) and (2). In step (2),
> filter is designed but I don't understand the procedure behind the design.
> "Taps[][]" is a two dimensional array defined and provided values in
> "interpolator_taps.h". I don't understand the step (1) of how the 2D array
> is used. Can anyone please provide their explanation involved in this
> procedure?
>
>
>
>
>
> 2) In the code portion:
>
>
>
> gr_complex
>
> gri_mmse_fir_interpolator_cc::interpolate (const gr_complex input[], float
> mu)
>
> {
>
>   int       imu = (int) rint (mu * NSTEPS);
>
>
>
>   assert (imu >= 0);
>
>   assert (imu <= NSTEPS);
>
>
>
>   gr_complex r = filters[imu]->filter
> (input);------------------------------------------------------------------(1
> )
>
>   return r;
>
> }
>
>
>
> What "filter" function is called in step (1)? How exactly is the
> interpolation done and values returned using "filter"?
>
>
>
> Thanks in advance.
>
>
>
> Regards
>
> Ravi
>
>
>
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20090603/9f0450fb/attachment.html
>
> ------------------------------
>
> Message: 13
> Date: Wed, 03 Jun 2009 16:27:12 +0200
> From: Mikael Olofsson <address@hidden>
> Subject: [Discuss-gnuradio] Changes from 3.1 to 3.2?
> To: GNUradio discussion list <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Greetings,
>
> I have just upgraded from GNU Radio 3.1 to 3.2. At the same time I
> upgraded from Ubuntu 8.04 to Ubuntu 9.04. The hardware setup is a USRP1
> with an LFTX daughterboard.
>
> Under the previous setup (8.04+3.1), I could generate signals with an
> amplitude up to approx 1V. Above that the signal was severely distorted,
> which fits very well with what I've been able to read about the hardware.
>
> With the new setup (9.04+3.2), the same code generates signals with an
> amplitude of approx 0.28V, and above that the signal again is severely
> distorted.
>
> This bugs me. The hardware should definitely still be able to produce 1V
> amplitude. I have tried this with two different USRPs and two different
> daughterboards and also with two host computers.
>
> Before I do any more debugging and start producing a small enough
> example, let me ask: Has there been any changes from 3.1 to 3.2 that
> could explain this behaviour?
>
> Regards
> /Mikael Olofsson
> Universitetslektor (Associate Professor)
> Linköpings universitet
>
> -----------------------------------------------------------------------
> E-Mail:  address@hidden
> WWW:     http://www.commsys.isy.liu.se/en/staff/mikael
> Phone:   +46 - (0)13 - 28 1343
> Telefax: +46 - (0)13 - 28 1339
> -----------------------------------------------------------------------
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> End of Discuss-gnuradio Digest, Vol 79, Issue 3
> ***********************************************
>